|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Fwd: Re: Are AOL's MXs mass rejecting anyone else's emails?
This message was sent to me offline after my post to the list. This apparently solved our problems. Just sending back to the list so anyone else searching for this issue can find an answer. Thanks NANOG! -Andrew > ----- Begin Forwarded Message ----- > > To: [email protected] > From: [email protected] > Subject: Re: Are AOL's MXs mass rejecting anyone else's emails? > Date: Wed, 11 Aug 2004 11:41:24 -0700 > > Andrew, > > I lurk on the NANOG list for interesting topics (can't currently post thru). I > started having this exact same problem in June with AOL. Spent an hour on the > phone with "Michael W" ([email protected]) and another couple hours doing > debuging via telnet to their servers before figuring it out. > > The problem in my case is that they seem to have put in place an email header > order filter (which gives back the 554 RLY:FA error if failed). Of course, the > web/mail masters didn;t seem to have any idea the mail admins did this. > > In my case, the problem is caused by the position of the "From:", "Mime:", and > "Content:" headers. The "From:" header MUST come before the other 2 in the > message flow, otherwise it is rejected. I don't know of any RFC which dictates > email header order... but apparently AOL is filtering on it... I forwarded this > info to them long ago and Michael said he would "add it to their notes". > > Below is the message I sent them with the details: > --- > >Date: Thu, 10 Jun 2004 12:22:35 -0700 > >From: [email protected] > >Subject: Bouncing email - believe to have found the problem > >To: [email protected] > > > > I think I have found the problem with the 554 RLY:FA error message. > > According > > to > > my logs, I have been able to successfully send you a few messages. > > > > The problem appears to lie in the processing of mail header order within the > > email message itself, not the SMTP "MAIL FROM" or "RCPT TO" commands. > > Previously when I sent out email, the headers of the email would look > > something > > like: > > > > Received from: <blah blah blah> > > To: <[email protected]> > > Subject: <subject> > > MIME-Version: 1.0 > > Content-type: text/html; charset=iso-8859-1 > > From: <[email protected]> > > Message-Id: <[email protected]> > > Date: <date string> > > > > <Message>... > > > > This was done through a PHP script using the "mail()" function, based on > > the > > example 4 in the PHP manual (http://www.php.net/manual/en/function.mail.php) > > (NOTE: in the example they have To/From/CC: and Bcc: headers following > > MIME/Content headers). This method still works fine through several other > > mail > > servers (cox.net, arizona.edu, af.mil) and had worked fine for the past year > > with aol.com. As of approximately Jun 9th, 4pm MST (or earlier, was working > > at > > 10am according to my logs), this no longer works with AOL servers. > > > > After some manipulation I have found that for the AOL servers, the From: > > header > > (regardless of the SMTP "MAIL FROM" command) MUST come before the MIME > > and/or > > Content headers within the email message. It appears that reordering the > > To/From/CC: headers does not affect the outcome, so long as the From: header > > precedes the MIME: and Content: headers of the message. > > > > Therefore, for a message to get through to an AOL user, the message must be > > formatted in the manner of: > > > > Received from: <blah blah blah> > > To: <[email protected]> > > Subject: <subject> > > From: <[email protected]> > > MIME-Version: 1.0 > > Content-type: text/html; charset=iso-8859-1 > > Message-Id: <[email protected]> > > Date: <date string> > > > > <Message>... > > > > > Adrian Jensen > [email protected] > Systems Administrator > National Traffic Safety Institute > Tucson, Az > > ---------------------------------------------------------------- > This mail was sent through webmail services for the > National Traffic Safety Institute and may contain > privileged and confidential information. Use or > interception by any intermediate agency or > individual is prohibited. > > > > ----- End Forwarded Message -----
|