spf-discuss
[Top] [All Lists]

Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd)

2004-10-07 20:37:47

On Thu, 2004-10-07 at 18:15, william(at)elan.net wrote:

Subject: I-D ACTION:draft-leibzon-responsible-submitter-00.txt

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-leibzon-responsible-submitter-00.txt

Here are some excerpts from this recent Submitter proposal.

| The purpose of the SUBMITTER parameter is to allow the SMTP client to 
| indicate to the server the address of the entity most recently
| responsible for injecting a message into the e-mail transport stream.

One possible view, assuming it is authenticated, would be the HELO
domain is the entity most recently accountable for injecting the
message.  This provides a clear and strong definition.  It also does not
require a modification to SMTP for this information to be obtained early
within the SMTP transaction and steers clear of many complexities.

...
| This document provides means to authenticate the DOMAIN of the 
| appropriate email address; it is not directed at the local-part.

That is good, as the HELO domain does not have a local part.
 
| A domain owner gets to determine which SMTP clients speak on behalf
| of addresses within the domain; a responsible domain owner should not
| authorize SMTP clients that will lie about local parts.

If this were done using a list of root HELO names, the mailbox domain
owner could easily describe which SMTP clients speak on behalf of this
mailbox domain, always within a single DNS lookup.  I don't understand
what is meant by lying about local parts.  It would make more sense had
this said to limit the authorization of SMTP clients to those shared by
other responsible mailbox domains.  But as these mailbox domains must
not be held accountable for this sharing, it would make even more sense
to say only the HELO domain is to be held accountable for any abuses.  
  
| In case of email submission by end-user this address can be found in
| "Sender:" header since RFC2822 specifies that Sender header represents
| "agent responsible for actual transmission of the message" and if
| Sender is not present then responsible party is email author listed
| in "From:" header.

Would it not be equivalent to saying the authenticated HELO domain plays
the role of sender?  In which case, the HELO root name list referenced
by the RFC2822 From mailbox domain can then indicate when the message is
"outside" the nominal mail channel.  Mail policy asserted by the mailbox
domain owner could also indicate whether messages "outside" the nominal
channel are to be rejected.  This prevents the problem of invited
exploits where SMTP client authentication is also attempted using this
description of this nominal mail channel with a long list of addresses. 
This long address list provides many other serious risks as well.  

| In case of email list, the responsible party is mail list and the
| address should be that of email list itself. 

Again, an authenticated HELO domain can play this role with much less
chance of spoofing.  In many cases, the HELO domain will be the same
domain as the RFC2822 sending domain. 

| In case of forwarding service, the address should be that of the
| forwarding agent or that of a user of that forwarding agent, whose
| settings caused email retransmission.

Here again, an authenticated HELO domain can play this role with much
less chance of spoofing.  The use of the HELO domain does not require a
modification to SMTP and provides a stronger and more secure named
identity.  The mailbox domain can be protected by describing the nominal
mail channel through the use of root name lists of these HELO domains.

The admonishments regarding the mailbox domain authorization of SMTP
clients is entirely misplaced, as the administrator of the SMTP client
must be held accountable, and this administrator is positively
identified by the HELO domain.  Any other domain reference would be
based upon an unverifiable assumption of the mail channel integrity.

For more details see:
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

-Doug