on Jabber this afternoon,
Ted Hardie <hardie(_at_)qualcomm(_dot_)com> wrote:
why is the intermediate MTA setting the Mail from to a new
address not forgery or to use a more neutral term "impersonation"?
NB: The log is at
http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-03-22.html
To put this in context:
<jlcjohn> Dave: isn't mailfrom RFC 2821?
<dcrocker> yeah, but what is the actual _use_ of the string: directing
bounces. who cares about that? the folks responsible for
the original posting.
<jlcjohn> Is there some reason the sending MTA shouldn't SET bounces-to?
<dcrocker> the SMTP client in a relaying sequence will not have a basis
for knowing anything about where bounces should go, except
what it has been told by the upstream entity.
<jlcjohn> there's no reason a relaying SMTP sender shouldn't know it's
relaying, and set bounces-to to something known good.
<dcrocker> sorry, no. random mtas in a sequence of mtas must no go around
arbitrarily setting bounces addresses.
<jlcjohn> why not?
<hardie> yeah, the "known good" address could get bounce storms from
that pretty fast
<jlcjohn> why "bounce storms"?
<dcrocker> if delivery fails, who needs to know, to take corrective
action? certainly not a stray mta in the middle of a transfer
sequence.
<hardie> setting to a "known good" address that isn't specific to the
message means that address gets all the bounces, which it
may not be able to address. A bad hat in the middle could use
that to send bounces to a "known good" address, dos'ing that
account. Dave's main point is more important though--MTAs
should not be arbitrarily resetting these.
<jlcjohn> yes, DOS is possible -- but if the MAIL-From can't be verified,
aren't bounces to forged addresses worse?
<hardie> why is the intermediate MTA setting the Mail from to a new
address not forgery or to use a more neutral term
"impersonation"?
(For the record: I did suggest to Ted that Jabber logs shouldn't be
considered the "public record". He disagreed. I'll take my chances on
Dave Crocker getting mad at me...)
It is _really_ unfortunate that RFC821 MAIL-From has that name. It
has led to untold confusion over the years. It is more correctly
called "Envelope-From", and I believe we've come to agreement here that
it really is a Bounces-To address.
I'd like to suggest that there's absolutely nothing wrong with
bounces that must use the RFC821 Bounces-To address traveling back the
same path of relaying MTAs that was followed to reach the process which
generates the bounce. (This is not to say there's necessarily a benefit.)
Every MTA along that path has had access to the full text; so there's
no _new_ privacy issue in relaying the text back. If one of the MTAs
along the path turns out to be under the control of a spammer, we're no
worse off by returning the bounce through him. (And, of course, there's
nothing _now_ preventing him from inserting himself in the bounces path.)
So, while, rewriting the Bounces-To may _sound_ like forgery when we
call it "Mail From", it really is nothing of the kind. The equivalent
in postal mail is forwarding a letter by enclosing it in an envelope on
which you put new postage. People habitually put their own return
address on the outer envelope, and it's certainly not forgery _or_
impersonation.
As for the reasons I think this would _sometimes_ be a good thing to
do, I'll save that for another email...
--
John Leslie <john(_at_)jlc(_dot_)net>