Re: [Fwd: [Asrg] Re: Documents for LMAP BOF]

Hadmut Danisch wrote:

> However, there is a point of view from which it doesn't make any
> difference whether to use HELO, FROM, or any header line:
> 
> If we just require that any domain is taking responsibility
> for the message transfer and we just require that this domain 
> name is mentioned just *anywhere* within the transfer process, 
> no matter whether where (reply-to, sender,...), then these
> different approaches all melt into one.
> 
> 
> We just force the sender to print it's domain name *anywhere* in the 
> transmission process. All those proposals about envelope senders, 
> HELO names, headers are just dancing around the little question, 
> where RFC821/822 leave place to print a domain name in without further
> meaning.
> 
> That's it. Very simple story. Just force the sender to reveal who he is 
> (=print the name of the domain he's belonging to).
> 

The problem is that according to the RFC 2821 as it is defined right 
now, you cannot accomplish these goals without changing it. The HELO 
parameter identifies only the originating MTA, the envelope sender only 
identifies the address for errors, not the responsible sender.

RFC 2821 (section 4.1.1.1) defines HELO as follows:

"These commands are used to identify the SMTP client to the SMTP
  server.
"

This identifies the MTA only, and not the sender. In the discussion 
document this difference is made explicitly in order to distinguish 
between authentication of the incoming MTA, and the sender. The DRIP 
proposal (and DMP) state explicitly that this only addresses the 
authetication of the MTA and not the sender.

HOWEVER, according to RMX (section 4.3) and SPF (section 2.2.1), the 
domain name used in the HELO/EHLO parameter is being used to determine 
the sender, NOT the client MTA. Changing this to mean that the sender is 
being identified is essentially redefining RFC 2821, and is also 
forbidding the MTA from sending multiple messages in one transaction.

Regarding the envelope sender, RFC 2821 section 3.3 defines it as an 
address to which error reporting messages are sent, not the originating 
sender. All of the LMAP proposals change the semantics of that command 
to imply that the mailbox in MAIL FROM is the responsible party of the 
message. While the distinction may seem to be trivial, it needs to be 
mentioned explicitly which is what the discussion document does.

-----------------------------------------------------------------

Let me play a little devil's advocate here:

If the entire purpose of these proposals is to make sure that the sender 
is who he claims to be according to DNS information, than what we could 
do is create an ESMTP extension to pass sender's information to the 
server MTA which will be verified via DNS. Since we need to change MTA 
software to support sender rewriting schemes, we might as well add a new 
extension instead, to pass that information explicitly.

For example, SMTP AUTH (RFC 2554) defines an AUTH parameter for the MAIL 
FROM command that can be used to indicate the original sender. Something 
similar can be made here as well. Lets say that you have somekind of 
HELO scheme in place which lets you verify the HELO parameter. Combine 
that with a reputation system for domains, and you have established some 
form of trust. Now add something like the AUTH extension to MAIL FROM 
which we can use to pass the information explicitly about the sender of 
the message and verify it against DNS. You get to keep the error bounce 
functionality and the LMAP functionality as well.

Of course this is just devil's advocate speaking :)

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Be liberal in what you accept, and conservative in what you send" (Jon 
Postel)
-------