We sent 200 eMails last night (Via our web site) and this morning got 17 of them back all for the same reason. The headers from one are below the others are substantially the same: Can you provide and guidance on this problem and what we might advise our useres of aol.com eMail? Thanks, Bill --------------------------------------------------- Could not deliver message to the following recipient(s): Failed Recipient: *******@aol.com Reason: Remote host said: 421 mtain-dh06.r1000.mx.aol.com Service unavailable - try again later -- The header and top 20 lines of the message follows -- Received: from web801.dotnetplayground.com (web801.dotnetplayground.com [192.168.100.211]) by postino2.discountasp.net with SMTP; Wed, 10 Oct 2012 13:23:07 -0700 Received: from Web801 ([127.0.0.1]) by web801.dotnetplayground.com with Microsoft SMTPSVC(8.0.9200.16384); Wed, 10 Oct 2012 13:23:06 -0700 x-MBR: *******@ MIME-Version: 1.0 From: "Nauset Newcomers Web Site" <[email protected]> To: "*******@" <*******@aol.com> Reply-To: *******@comcast.net Date: 10 Oct 2012 13:23:06 -0700 Subject: Welcome to: Chillingsworth on: Wednesday, Oct 17 2012 6:00PM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Return-Path: [email protected] Message-ID: <[email protected] nd.com> X-OriginalArrivalTime: 10 Oct 2012 20:23:06.0932 (UTC) FILETIME=[0EE7E740:01CDA725]
Bill, AOL is probably greylisting (forcing the sending server to send twice as a spam prevention measure) and that's why they return 421. 421 can also come back if the server is busy, which is also possible with an operation the size of AOL. For whatever reason though, that response is telling the sending server to try to send the message a second time. That's not a problem for a normal mail server, since most mail servers will automatically retry when they receive a 421 (or a number of other failures), but for your application it's more problematic, since I'm assuming you don't have any way to retry those. Unfortunately, our mail servers that relay mail from applications on the web servers will not retry the message like our normal email server gateways do, so I'm afraid you're going to have to come up with some way to deal with those. I don't recall anyone posting any code or workaround/solution for that here (I don't see anything in a quick search anyway), but you may be able to find some info elsewhere.
What is interesting is that the original messages were sent as much as 15 - 20 hours earlier than the rejects, so I presume that the servers that handle these are making several attents to deliver in that time frame? Also we have only had this problem with AOL.COM I would hope that the "normal" retry methods would apply for some limited period.
That is interesting. It means AOL had them for all that time and then, for whatever reason, sent the failures out. The best thing to do would be to (try to) ask them why that would happen. The failure and error messages related to email are standard, but that doesn't mean everyone applies them the same way. Only the rejecting server can tell you exactly why the messages were rejected. Mail sent from the web servers is never retried. There are two reasons for that. First, we assume some degree of bounce management on the part of the sending application, second, not retrying prevents a lot of spam from being received from our network (see the greylisting definition). Spammers typically use web applications rather than email clients to do their dirty work. We have a lot of fraud detection measures in place, but some spammer accounts still sneak through, and we also get spam coming from legitimate sites that have been compromised. So the mail relays from the web servers have to behave differently than the "normal" email servers (that accept mail from desktop or web email clients).
