Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT

From: "Jim Lyon" <[email-masked]>
Date: Mon, 19 Jul 2004 18:30:30 -0700

Terje Petersen wrote:
> ...  An MTA is a "message TRANSFER agent". Its job should not
necessitate reading the DATA content of email. 

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.

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. 

-- Jim Lyon

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Jul 2004 23:55:14 -0700

Jim,

JL> The mis-named "MAIL FROM:" doesn't tell you who sent the message, but
JL> who wants to receive the bounce if any.  Much confusion would have been
JL> avoided if the 2821 command were spelled "MAIL BOUNCETO:".  Many people,
JL> including me, have gone down the path of erroneously trying to use "MAIL
JL> FROM:" for authentication. 

given that the misnomer dates back to rfc 821, it's rather impressive
that it took more than 20 years for us to notice the error!

in an odd way, this highlights the difficulty of preventing scaling
problems.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 23 Jul 2004 00:22:40 -0400

----- Original Message -----
From: "Jim Lyon" <[email-masked]>
To: "Terje Petersen" <[email-masked]>; <[email-masked]>
Sent: Monday, July 19, 2004 9:30 PM
Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT

> body.  That's exactly why the PRA algorithm exists: to determine who

But you are not verifying the sender address, only the sender domain. What
about the full email address?

> 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

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 23 Jul 2004 00:32:43 -0400

Who cares what it means or what the original intent was!  It still must be
verifiable!

If the industry has Time Square neon flashing advertisements saying the
"60-80% of the MAIL FROM: address is BAD,"  it is completely  boggles the
mind as to why everyone is ignoring it in the name of what the darn user
will see!!!

Your proposal is based on a verifiable client domain name.   Why can't the
MAIL FROM be verifier?  Even it is a bounce address?  Why must one 1 of 2
inputs be valid and not the second?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 23 Jul 2004 18:20:48 -0700

> inputs be valid and not the second?

The RFC 2822 identities being checked are also often not seen by the
user.  As with with the expression of having two lawyers arriving at
three opinions, the definition of who actually sent the mail is not
concerned with the question who authored the message either.  The return
error path is unrelated to the author as is the sender in many cases. 
The advantage using the RFC 2821 MAIL FROM, is less confusion over what
is being checked and what piece of information adds to any assurances.

Another important aspect of the RFC 2821 MAIL FROM is that it is used to
sneak into the back door of sites that block with IP based accreditation
services using those sites that don't.  Blocking with name based
accreditation, this blocking figure could approach 100% as such could
become very aggressive in a safe manner.  This accreditation could also
declare the age of the domain.  To do this, authentication and
authorization of the MTA by the controlling domain is vital.  The Core
specification fails to provide that information.  The submitter
specification fails to provide that information.  These are filtering
inputs only.

What is important varies depending upon what is being accomplished.  If
to accredit the polices of the MTA, the HELO domain must be
authenticated and authorized.   If to close the back door on the bounce
traffic, then the RFC 2821 MAIL FROM should be checked.  I suspect the
BATV proposal could include an option to allow use of the CIDR notation
to specify legal Return paths in addition to a signature.

If you wish to filter the messages, then the RFC 2822 identities play a
role, but filtering is an inherently bad choice to control the problem. 
Filtering is a cause for the loss of mail integrity.  The goal should be
to put the burden upon the sender to keep their accreditation high to be
accepted, rather than expecting the receiver to filter junk that
continues to enter unabated.  Desirable mail gets discarded in the
filtering process only because it is impossible to recognize spam from
desirable mail in many case.

Dave Crocker's Bounce Address Tag Validation can solve this back door
problem. If done using public key encryption methods, it can be used to
block this traffic before being bounced.  It can also be used to exclude
traffic completely forged.  The down side, if you wish to call it that,
is that it can be susceptible to 'replay' attacks.  By using a time
stamp, any replay can be filtered and would only need to be stored in a
filter list for the duration of the key life of perhaps 10 days. 

Sender ID offers a means to continue phishing by playing games with the
PRA, which users are likely not to understand, and which there is likely
a means to find differences between interpretations of what is being
checked and presented, owing to the complexity of the task.  Such
differences alone will offer ample opportunity to phish.  As the user
will likely continue to focus on the RFC 2822 From, the ability to
confuse the user remains.  It is already amusing the SPF records are to
be used "as is" which are based upon the RFC 2821 return path.  Should
there be a desire not to agree to the contract offered by Microsoft, the
use of the RFC 2821 MAIL FROM over the same record set is still
possible.

What is being checked?  The error return path? The sender?  Does it make
a difference, as it is not the author that is being checked and that is
what people will likely be looking at.  Something like Identified
Internet Mail answers the question, is this the author and is this their
message?  Frankly, other than selling a filtering MUA, I can not see
much use for the RFC 2822 checking stuff.

-Doug