----- Original Message -----
From: "Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com>
To: "Terje Petersen" <terje(_at_)excelan(_dot_)com(_dot_)au>;
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, July 19, 2004 9:30 PM
Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT
However, MARID's job is to verify the identity of the sender of a
message, and the sender isn't expressed anywhere except in the message
body. That's exactly why the PRA algorithm exists: to determine who
sent the message.
But you are not verifying the sender address, only the sender domain. What
about the full email address?
The mis-named "MAIL FROM:" doesn't tell you who sent the message, but
who wants to receive the bounce if any. Much confusion would have been
avoided if the 2821 command were spelled "MAIL BOUNCETO:". Many people,
including me, have gone down the path of erroneously trying to use "MAIL
FROM:" for authentication.
Are you saying the BOUNCE ADDRESS is not verifiable?
That is completely illogical. The problem is the "change of identity." Not
that it is "erroneous" for authentication.
Look, you can guarantee the SMTP elements will be there:
IP
HELO
MAIL FROM
RCPT TO
You can NOT GUARANTEE what the PAYLOAD will look like!
Regardless of WHO creates the mail, what the PAYLOAD will look like, WHO
sends it, it MUST comply with SMTP! Period!
You logic is conflictive because the basic reasoning of the PRA in the first
place is based on the idea that the user "wants to see who sent" the
message.
Well, if you are talking about "users" then the 2821 MAIL FROM will
typically be user's address and hence where the bounce goes to. The problem
is with "change of identity" which your documented illustrates.
Nonetheless, the BOUNCE address regardless of who it is, the Author or the
Messenger (sender) it *MUST* be valid . Before the USER can get the
message, the BOUNCE address must be valid!
I truly hope you don't see this as a "bash." No, not at all. But I must
say I am extremely disappointing with where this is headed. In my strong
assessment, it is an illogical design that will guarantee us more security
and performance problems than you care to believe or acknowledge.
Microsoft has ignores "ethical programming" in the past by allowing storage
and execution of remote code on a local machine in the name of "integration"
and look what that got us - major security problems.
I see this going down the same path and once the main stream begin seeing
this in practice, the booboo will hit the fan.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com