If the intention is to prevent spamming I fully agree with AOL. IMHO, if an existing standard is broken it should not be used, but replaced with a better approach, even if it is not standardized. Guenter At 12:34 PM 5/8/97 -0400, [log in to unmask] wrote: >On Thu, 08 May 1997 11:28:14 EST, you said: >> We run the MUSIC operating system as a guest under VM. Today I received >> the following reply when trying to send email from MUSIC via VM SMTP to >> AOL. >> >> VM.NMU.EDU unable to deliver following mail to recipient(s): >> <[log in to unmask]> >> VM.NMU.EDU received negative reply: >> 553 <@VM.NMU.EDU:[log in to unmask]>... Source routed envelope sender >> rejected (See RFC 822, section 6.2.7) >> >> Has anyone else seen anything like this? It was working last week and >> its my "belief" that I didn't change anything... > >(Am CC'ing this reply to several places - apparently more people are >complaining now....) > >AOL has decided to unilaterally violate RFC1123, sections 5.2.19, >which requires accepting source routes, in favor of an >as-yet-still-draft future standard that permits rejecting these. We >have already contacted AOL, and they seem to feel that the language in >RFC1123, section 5.2.6 which permits simply ignoring the source route, >is insufficient. > >We have been informed by Brad Knowles of AOL that they consider >section 7.5 of draft-ietf-drums-smtpupd-04.txt (still in draft status) >to be more important than RFC1123, which is in full standard status. > >Quite frankly, this is no way to run an Internet. Once the DRUMS >document moves up to Proposed Standard status or so, I'll support >AOL's right to implement it. But disregarding the standards in favor >of a draft is no way to do business, even if you do have the most >market share. > >-- > Valdis Kletnieks > Computer Systems Senior Engineer > Virginia Tech > > > >Attachment Converted: C:\Data\Email\Attachments\Re AOL mail traffic >