Hey Guys, Does anyone know the meaning of this error "Yahoo error-550 Action not taken" and how to fix it? I am getting this error recently and creating a problem. Thanks.
It would appear that AOL is still messing with the secret sauce. Morning drops went fine with the normal 90-99% deliver-ability across all ranges. Then this afternoon I have seen a lot of 421 mtain-mh06.r1000.mx.aol.com Service unavailable - try again later errors. By "a lot" I mean literally a wall of them. While I am used to seeing the middle of the day madness and uphill battle, I typically try and avoid it. But today I tested the waters a bit, and this is what came back. Leading me to believe they are still messing with the filters. As for your O.P., that 550 typically means bad address if memory serves. But you can check their postmaster error codes. I think that one is listed. Keep in mind, AOL had made an announcement some time back about any inactive AOL account/email address and that they would be disabling them after a period of time versus leaving them open. I want to say it was 30 days, but I do not recall without looking it up. What that would mean is, unless they are logging in at least once per month, the address goes honeypot. Or whatever they do with them.
What Those SMTP Error Codes Mean and Why You Should Care Category: Mailing List Hygiene / Other Practices / Sending Practices / Technical System Stuff 23 Summary: Anybody who sends email has seen them, in one form or another - those SMTP error codes, often returned in bounced email, such as "550 Requested action not taken: mailbox unavailable" or "550 5 2 1 mail from refused spam site." These are often in response to SMTP commands that have 'gone wrong' between your email server that sent the email, and the receiving email server that is unable to deliver it (or refuses to deliver it) for some reason. But what exactly do they mean? And why should you care? ('SMTP' stands for Simple Mail Transfer Protocol.) First, here is a list of SMTP messages and error messages, and what each message is supposed to say and mean Anybody who sends email has seen them, in one form or another - those SMTP error codes, often returned in bounced email, such as ***8220;550 Requested action not taken: mailbox unavailable***8221; or ***8220;550 5 2 1 mail from refused spam site.***8221; These are often in response to SMTP commands that have ***8216;gone wrong***8217; between your email server that sent the email, and the receiving email server that is unable to deliver it (or refuses to deliver it) for some reason. But what exactly do they mean? And why should you care? (***8217;SMTP***8217; stands for Simple Mail Transfer Protocol.) First, here is a list of SMTP codes and error codes, and what each message is supposed to say and mean: 211 - A system status message. 214 - A help message for a human reader follows. 220 - SMTP Service ready. 221 - Service closing. 250 - Requested action taken and completed. 251 - The recipient is not local to the server, but the server will accept and forward the message. 252 - The recipient cannot be VRFYed, but the server accepts the message and attempts delivery. 354 - Start message input and end with .. This indicates that the server is ready to accept the message itself 421 - The service is not available and the connection will be closed. 450 - The requested command failed because the user***8217;s mailbox was unavailable (such as being full). Try again later. 451 - The command has been aborted due to a server error. (on their side) 452 - The command has been aborted because the server has insufficient system storage. 500 - The server could not recognize the command due to a syntax error. 501 - A syntax error was encountered in command arguments. 502 - This command is not implemented. 503 - The server has encountered a bad sequence of commands. 504 - A command parameter is not implemented. 550 - The requested command failed because the user***8217;s mailbox was unavailable (such as not found) 551 - The recipient is not local to the server. 552 - The action was aborted due to exceeded storage allocation. 553 - The command was aborted because the mailbox name is invalid. 554 - The transaction failed for some unstated reason. Unfortunately, many receiving systems seem to mix and match these error messages, rather than adhering to the prescribed code messages. The good news is that the SMTP error messages you need to worry about as an email sender are really primarily limited to just a few - those in the 5XX range - and of those, the ones that you really need to worry about are the ones in the 55X range - i.e. 550-559. Of these, by far the most common one - the one that as a sender you will see most often and to which you must pay immediate attention - is the 550 SMTP error code, which can range from ***8220;user not found***8221; to ***8220;mailbox unavailable***8221; to any number of other similar variations, but which for you, dear mail sender, should almost always be read to mean ***8220;remove this email address from your mailing list immediately.***8221; (On the other hand, your mail server administrator should care deeply about many more of these codes, however we assume that if they are administoring your outbound mail server, they are already familiar with them.) So, back to that 550 error code. Almost always, when you get an email bounced back (or inserted in your mail log!) with a 550 error code, it means that the receiving system could not deliver your email to the user to whom it was addressed because the mailbox is unavailable. Almost always, this means that the inbox either no longer exists, or that it never existed! Why would you have an email address on your mailing list that has never existed? There could be a lot of reasons, including that someone entered it wrong, or that someone intentionally entered a fake email address into your system (such as when you require a user to divulge an email address in order to receive a download, etc.). Regardless of how it ended up on your mailing list, if you send a mailing to it, it tells the receiving system one sure thing: that you don***8217;t confirm email addresses before adding them to your mailing lists. And, if you send email to that same non-existent email address after receiving the 550 message that the mailbox doesn***8217;t exist, it tells that receiving system that not only don***8217;t you confirm email addresses, but that you don***8217;t care very much about list hygiene - i.e. that you don***8217;t maintain your mailing lists according to best practices, either. And, having determined this, very soon those receiving systems, including ISPs, will simply stop delivering your email to the inbox - first diverting it to the junk folder, then not delivering it at all, and then perhaps even blacklisting all of your email. Now, it***8217;s possible that a mailbox will be unavailable because a user has let their inbox get full. And we often get asked whether, because of that possibility, it***8217;s ok to not remove an email address which has returned a 550 error? Think about this: in this day and age of nearly unlimited email storage (nearly all ISPs now offer multiple Gigs of email storage), just how inactive does a user have to be in order for their inbox to fill up? And, even if they are going to come back some day and clear out their inbox, do you think that they are really going to stop to read your email? Or will they delete it unopened and unread, creating even more problems for you? The bottom line is: why hang on to an email address that belongs to a user who will never be a positive asset for you, and can only cause you trouble? So the next time an email that you send bounces back, take a good look at the information in the bounce message, and take the appropriate action based on that message. And don***8217;t forget to check your mail logs for bounce messages too! P.S. If you are actually receiving bounce messages that include ***8220;mail from refused spam site***8221; or a similar message, the odds are good that your mail already has been blacklisted, and you***8217;ll need to deal with that immediately. http://www.gettingemaildelivered.com/what-those-smtp-error-codes-mean-and-why-you-should-care
BTW guys, the problem is if I use another ip to the same list of names, I don't get that error message. This is the problem that I am having with yahoo recently. Are you guys experiencing this issue?
I have been seeing a lot of the same errors the hatter is seeing. It appears to build gradually until the IP just shuts down. It seems as though if you open a ticket with AOL they accelerate the process, although I could just be superstitious. Complaints on all IPs are very low, at around .01% with a good level of activity. Makes no sense to me.
Interesting feedback in that regard..... IP's crapping out, and low complaints. From what I am seeing.... 1 day it's a wall of con blocks, the next a wall of 421's, the next drop some other error message. Every day is a new adventure. :aargh4:
I am seeing the exact same thing. RLY:B1's are popping up on low volume, no complaint IPs too. I know the data is good and the stats don't indicate any particular issue. I'd say it is random, but it seems almost too focused to be random.
And I have tried backing off, slowing down, dropping volume, and it doesn't seem to make a difference. Wish I could offer a fix here, but I can at least save others from trying the aforementioned tactics. Just a waste of time.
With that said, so you're saying that you're simply burning up the AOL IP's like a bad habit? Or you can still get mail out?
Not churning and burning. I've lost a few and any new ones seem to burn out pretty quickly in the warmup stage. Gotta hope, I guess.
Are you pre-testing them before purchase? Or are they? Many ISPs do not know how to hard test allocations to make sure clean for whatever you want. If you can get an allocation in advance, you can always check by hand at AOL worse case scenerio. Are you setting up FBLs?
