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: [log in to unmask]
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
|
