I’m getting mighty ticked off with Yahoo! Mail lately. I have industry contacts, family, and friends that use yahoo.com email accounts and I’ve been getting this “defer” messages lately. Yahoo is using an anti-spam tactic where they “defer” the message from your SMTP server. It’s also known as “greylisting″.
Yahoo mail denies the first delivery attempt of an email (421 Message temporarily deferred). Yahoo assumes that spammers don’t try sending the same email twice, so they put the IP address of that email server in a list and then if the delivery is retried within a short amount of time, they assume that it is a good email and “accept” the SMTP connection for mail delivery. It’s too resource intensive for spammers to retry emails, which is why spammers mass blast programs give up after one try.
The SMTP protocol, configured on valid email servers, was designed such that it will retry to send an email several times before failing. Unfortunately, Yahoo’s greylisting has gotten super aggressive, often deferring tmcnet.com emails to yahoo.com email addresses so many times that eventually our email server gives up.
Even worse, often times 24 hours goes by before I get an email undeliverable message! I had an important email that I assumed was delivered and I didn’t know until a day later that it bounced!
Here′s an example:
This message could not be delivered. The TMC I.C.E. Box will not make any further attempts to deliver the message.
A record of the delivery attempts made follows:
We were unable to connect to the destination server(s):
On Thu Nov 13 at 14:51 EST, Message exceeded queue lifetime. Bouncing.
On Thu Nov 13 at 14:51 EST, Connected to 216.39.53.2 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Thu Nov 13 at 11:38 EST, 68.142.202.247 failed after I sent the message. Remote host said: 451 Message temporarily deferred - [70] On Thu Nov 13 at 08:38 EST, Connected to 66.196.82.7 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Thu Nov 13 at 05:51 EST, Connected to 206.190.53.191 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Thu Nov 13 at 03:18 EST, 209.191.88.247 failed after I sent the message. Remote host said: 451 Message temporarily deferred - [70] On Thu Nov 13 at 00:58 EST, Connected to 209.191.118.103 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 22:51 EST, Connected to 216.39.53.1 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 20:58 EST, Connected to 66.196.97.250 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 19:18 EST, Connected to 216.39.53.3 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 17:51 EST, Connected to 66.196.97.250 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 16:38 EST, Connected to 67.195.168.31 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 15:38 EST, Connected to 209.191.118.103 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 14:51 EST, 66.196.82.7 failed after I sent the message. Remote host said: 421 Message temporarily deferred - 4.16.51. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 14:18 EST, Connected to 209.191.118.103 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 13:58 EST, Connected to 209.191.88.247 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
On Wed Nov 12 at 13:51 EST, Connected to 209.191.118.103 but greeting failed. Remote host said: 421 Message from (206.252.203.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
You′ll notice that the IP addresses are all different, since Yahoo has tons of email servers. TMC uses a similar greylisting feature from Sendio’s anti-spam appliance, but I have it set to “permissive” and not “aggressive”. Were I to set it to “aggresive”, then if an email came in from a different IP address, our Sendio appliance would defer the message again even if the email was previously deferred from a different IP address. By setting it to “permissive” it allows the same domain email to come in via different IP addresses.
My guess is Yahoo has their email servers set to “aggresive” and they don’t have a centralized “defer” database. So when I send an email to a Yahoo address, it’s going to be pure luck if I hit the same server again after being deferred. Thus, this will result in bouncebacks after being deferred ad infinitum.
Check out Yahoo’s own Q&A, which essentially puts the onus on the “sender” and places no blame on themselves for failed email delivery 
:
421 Message temporarily deferred - [numeric code]
If you are seeing the error “421 Message temporarily deferred - [numeric code]”, where “[numeric code]” shows a specific diagnostic code (e.g., “4.16.51″, “4.16.52″) in your SMTP logs, this indicates that:
- the message you attempted to send exhibited characteristics indicative of spam,and/or
- emails from your network have been generating complaints from Yahoo! Mail users.
This is a temporary error and your mail server may automatically re-try sending emails at a later time. However, we do encourage you to examine your outbound queues to ensure that spammers are not abusing your mail server.
Are you seeing the same error consistently over an extended period of time? If so, we encourage you to provide us with detailed information, including the error and diagnostic code(s) you see in your logs, so that we can help diagnose your problem.
For bulk mailers, please visit this page to review our best practice recommendations and request assistance.
If your mail server does not primarily send bulk mailings (e.g., you run a personal, corporate, educational, or ISP mail server), please fill out this form instead.
If you’re not the administrator of the mail server in question, please contact the administrator directly with the error message you’re receiving.
This question/answer wasn’t very helpful either:
Q: As a sender, how can I ensure uninterrupted SMTP access and prioritized delivery?
A: Yahoo! Mail has become more aggressive in its acceptance of SMTP connections and denies connections by IP address when these connections do not conform to Internet standard practices. To continue uninterrupted access and prioritized delivery, you should ensure that your email address lists are well maintained. If you are conforming to these standards, then these policies should only affect you positively. We anticipate improvements in delivery times and in available connections.
If you consistently see 451 SMTP error codes you should review your email practices and policies, especially the following:
- Remove email addresses that bounce. Bounces are an indication that the mail could not be delivered because the user does not exist, no longer exists, or is unable to accept your email. List managers should remove addresses that generate bounces. A particularly popular technique for managing bounces is to use VERP to identify the recipient address that has failed.
- Examine your retry policies. Messages that receive permanent errors, such as emails sent to accounts that do not exist or are over quota, should not be retried. Permanent errors that are retried increase the likelihood that delivery will not receive the priority it deserves.
- Pay attention to the responses from our SMTP servers.The SMTP protocol defines response codes that tell your server what to do next. In particular, our server will send “500″ SMTP response codes to indicate problems that you need to investigate. For example, if an email is sent to an invalid recipient, our servers will respond with a “500″ range SMTP code, indicating a permanent error. Large numbers of emails sent to non-existant accounts may be indicative of a systemic problem. Many companies following best email list practices treat email addresses that have received a “500″ range SMTP codes specially. For instance, many companies place these addresses into a special queue that tests for continued bounces after longer and longer periods of time. This helps them maximize delivery to email addresses that exist and minimize wasted bandwidth costs.
- Don’t send unsolicited email. Make sure that all email addresses are confirmed with an opt-in process that ensures the recipient wants to receive your mail. Obtaining permission from a third party to send an email does not ensure the email is solicited. Probably the best way to confirm an email addresses before adding them to a mailing list is by using closed-loop confirmation (sometimes referred to as “full confirmation,” “full verification,” “confirmed voluntary subscription,” or “double opt-in”). In this process, after you receive a subscription request, you send a confirmation email to that address which requires some affirmative action before that email address is added to the mailing list. Since only the true owner of that email address can respond, you will know that the true owner has truly intended to subscribe and that the address is valid.
- Provide a method of unsubscribing from your list in each mail you send.
- Ensure that your mail servers are not open relays, and that your servers attempt to detect and deny connections to open proxies. At a minimum, your SMTP servers should identify the originating IP addresses that of the email and indicate this in the email headers to help you diagnose spam problems. There are a variety of open relay testers available.
If you conform to the above practices and are still seeing delivery problems, please fill out this form so that we can help you diagnose your problem. Please do not use this form to report spam
Tags: 421 defer, defer, greylisting, Sendio, spam, Yahoo, Yahoo Mail
Related Entries
- Sendio I.C.E. Box anti-spam appliance review -
Jan 16, 2008
- Yahoo! Integrates Messenger with Mail -
Feb 12, 2007
- Notice Less Spam Today? -
Nov 12, 2008
- OctroTalk adds Video Conferencing and Live Streaming to Windows Mobile -
Oct 15, 2008
- friends of fring -
Sep 02, 2008
- Enabled Comments from AOL/AIM, Yahoo, Movable Type, WordPress, LiveJournal, OpenID, or Vox users -
Jun 27, 2008
- Skype and other VoIP Apps on Mobile Phones -
Apr 01, 2008
- OctroTalk Launches -
Mar 31, 2008
- Yahoo Messenger for Vista Adds VoIP -
Mar 07, 2008
- Yahoo Overture Keyword Selector Tool Outage -
Feb 01, 2008
TrackBacks
| Comments | Tag with del.icio.us | VoIP & Gadgets Blog Home | Permalink: Yahoo Mail - Defer this! %#$^@$
Copyright VoIP & Gadgets Blog
![]()
Original post by nafiz
At the 
What in the bloody hell kind of half-ass crippling of VoIP is that? Apparently, Steve Jobs aims to protect their cell network buddy AT&T from having VoIP calls be "minute stealers" from the regular cell network. Of course, AT&T and Apple have some sort of revenue sharing deal from what I understand, so Mr. Jobs doesn’t want Apple’s purse strings affected by VoIP bypassing the usage of cell minutes either.
