LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Parts/Attachments: text/plain (1661 bytes) , application/pgp-signature (291 bytes)
Print Reply
Mime-Version:
1.0
Sender:
LISTSERV give-and-take forum <[log in to unmask]>
Date:
Thu, 8 May 1997 12:34:20 -0400
Reply-To:
LISTSERV give-and-take forum <[log in to unmask]>
Subject:
From:
Content-Transfer-Encoding:
7bit
In-Reply-To:
Your message of "Thu, 08 May 1997 11:28:14 EST." <[log in to unmask]>
Content-Type:
multipart/signed; boundary="==_Exmh_-1975136936P"; micalg=pgp-md5; protocol="application/pgp-signature"
Comments:
To: IBM TCP/IP List <[log in to unmask]>, [log in to unmask] cc: Karl Mulder <[log in to unmask]>, Brad Knowles <[log in to unmask]>
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




ATOM RSS1 RSS2