Great Circle Associates List-Managers
(May 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: rejected mail - RFC822 conflict ???
From: Brad Knowles <BKnowles @ aol . net>
Organization: America Online, Inc.
Date: Wed, 07 May 1997 16:14:03 -0400
To: Eric Thomas <ERIC @ VM . SE . LSOFT . COM>
Cc: LSTOWN-L @ PEACH . EASE . LSOFT . COM, LSTSRV-L @ PEACH . EASE . LSOFT . COM, Valdis Kletnieks <Valdis . Kletnieks @ VT . EDU>, Michael Ramundo <sysmrr @ CNSIBM . ALBANY . EDU>, Jeff Kell <jeff-kell @ UTC . EDU>, Pete Weiss <Pete-Weiss @ PSU . EDU>, list-managers @ GreatCircle . COM
In-reply-to: Your message of "Wed, 07 May 1997 19:54:40 +0200." <199705071932 . PAA22699 @ postman . ops . aol . com>
Reply-to: KnowlesB @ aol . net

Your message dated: Wed, 07 May 1997 19:54:40 +0200

> All you have to  do then is ignore the source route,  which is allowed by
> RFC1123. I cannot think of any reason why ignoring the source route would
> not address  your concerns.

    See my previous response.  I don't feel I have anything more
to say on that subject than I've already said.

>                              Incidentally, if a  spammer doesn't  want to
> deal  with bounces,  there  is  MAIL FROM:<>...  Or  did  AOL also  start
> rejecting  such messages?  This would  make  AOL useless  for managing  a
> mailing list, among other things.

    We continue to be compliant with RFC 1123, section 5.2.9.
That will not change.

    In fact, I recently pointed out the necessity to comply with
this particular part of RFC 1123 to a security expert who is in the
process of making enhancements to "smap", to allow it to make more
intelligent decisions about what kind of messages to accept or refuse
(dealing with all the same issues I've already solved here at AOL
with various sendmail rewrite rules, but instead dealing with them
in another product).


    Source routes in the domain portion are inherently evil beyond
reproach, and there's nothing you can do to convince me that they
should not be rejected out of hand.  Any system that actively
propagates this kind of behaviour is likewise inherently evil.
Any system that passively allows this kind of behaviour needs to
be fixed.

> >    Essentially  as much  has  been observed  by  various Internet  mail
> >experts, many of whom are working on drafting the upcoming standards.
> 
> Brad, maybe I'm not reading this in  the light in which it was meant, but
> there are  probably more Internet mail  experts among the people  you are
> sending this message to than in the  group you mentioned, and as you know
> technical people tend to be independent  thinkers.

    There are "Internet mail experts" the world over, and as you
observe elsewhere in your own message, some of them have some pretty
bizarre ideas of what should and should not be done.  In fact, I'm
certain that many feel this way about me.  So be it.


    However, this is a particular behaviour that has been deprecated
for at least six years (RFC 1123, section 5.2.6, as clearly pointed
out by Valdis), and it's time that it went completely away.

    I can't think of too many Internet mail experts that would argue
that point, although they may argue that I'm being too vehement or
otherwise jumping the gun.

>                                                                   It also
> doesn't make much sense  to ask people to submit to the  wisdom of a task
> force working on new Internet drafts which may or may not become Internet
> standards in  a couple years, let  alone industry standards, when  at the
> same  time you  refuse  to  submit to  the  wisdom  of existing  Internet
> standards with their existing user base.

    The principle specifically laid out in section 7.5 of
draft-ietf-drums-smtpupd-04.txt is one that has been around far
longer than that, in fact far longer than the Internet itself.

    It's been around as long as there have been personal and
group property laws, and is based on the concept of "trespass"
(specifically, "trespass of chattels") and the right for me (or my
company) to do with my own property what I choose (or my company
chooses).


    In this particular case, it is an operational issue that
threatens the very existance of the AOL mail system, and we *cannot*
afford to allow it to continue unabated in this fashion.

    Although I recommended this course of action, I am certainly
by no means alone here in my desire to implement these kinds of
protections.  Management pushed for it about as hard as I have.

> LISTSERV does not generate source routes, nor has it ever done that. Even
> back in 1986, LISTSERV had  a strong no-source-routes stance. However, if
> presented with a source route it  does ignore it gracefully, as you would
> expect.  The source  routes come  from  LMail, a  MTA for  VM (also  from
> L-Soft) which can be configured  to implement the original RFC821 reverse
> path behaviour where  you insert source routes in the  MAIL FROM: address
> (at no point is a source route  added to the RFC822 header).

    I'm sorry if I mistakenly pointed the finger at Listserv,
instead of LMail.

    Whatever the L-Soft system is that can potentially generate
source-routed envelope addresses, I would like to make sure that
current and future versions have that feature default to "off"
(which appears to already be the case, given your other comments).

    As far as I'm concerned, this one particular concern of mine
is moot.

> Even setting aside the fact that the standards require AOL to accept this
> syntax, it just  does not make any  technical sense to reject  it, and it
> leads to the loss of legitimate mail for AOL's customers.

    There is nothing in any law that requires me (or my company)
to pay to accept messages that are in a format (and/or quantity)
such that they threaten the very existance of my property (or the
property of my company).  There is no protocol on the planet that
can legitimately likewise claim to make that kind of stipulation.

    In fact, there is a law *against* compelling me to pay to
accept a message from someone else, and is the basis for much of
the current anti-junkmail lawsuits that are pending.


    However, this isn't a junkmail issue per se, it's an operational
systems issue regarding our right to protect the very existance of
our private property (the same private property that our customers
depend on).

-- 
Brad Knowles                                MIME/PGP: KnowlesB @
 aol .
 net
    Senior Unix Administrator              <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>




Indexed By Date Previous: Re: rejected mail - RFC822 conflict ???
From: Eric Thomas <ERIC @ VM . SE . LSOFT . COM>
Next: Re: rejected mail - RFC822 conflict ???
From: Eric Thomas <ERIC @ VM . SE . LSOFT . COM>
Indexed By Thread Previous: Re: rejected mail - RFC822 conflict ???
From: Eric Thomas <ERIC @ VM . SE . LSOFT . COM>
Next: Re: rejected mail - RFC822 conflict ???
From: Eric Thomas <ERIC @ VM . SE . LSOFT . COM>

Google
 
Search Internet Search www.greatcircle.com