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

[I removed spf-discuss from the cc: list, since Doug is not a member there 
and his message therefore didn't appear on that list.]

--Douglas Otis <[email protected]> wrote:

>| 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.


Doug's reply seems to indicate either a misunderstanding of the main point 
behind SUBMITTER, or else he is trying to commandeer the discussion and 
steer it back to his favorite topic of HELO verification.

I consider it rude to take someone else's hard work and criticize it 
because it doesn't match your own "pet" issue.  But since I don't have 
direct knowledge of Doug's motives here, perhaps it's appropriate to be 
charitable here and assume a misunderstanding rather than intentional 
insult and provocation.  [for now]


>| 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.


Continued discussion of HELO in this context gets us further from the topic 
of the draft itself.  HELO was not mentioned in the draft (other than the 
response to EHLO should contain SUBMITTER in the capability list.)  So, I 
will try to respond to this without mentioning HELO.

I have a pretty fair idea of what "clients that lie about local parts" 
really means.  It means that the domain owner should make sure that any 
SMTP clients he chooses to authorize should check the local part against 
the known/verifiable information for the user (such as SMTP AUTH, static 
IP, pop-before-smtp, etc.)  This prevents one customer of the service 
provider from impersonating other users at the same service provider.

(My previous message describes methods that ISPs might use to verify that 
the localpart being claimed really is owned by the user being 
authenticated.  This is not new -- RFC 2476 says that the submit server 
should verify if the user is really authorized to use that particular 
return path -- William's draft is just applying something similar to the 
submitter address.)


>| 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?


No, it clearly would not.  A message should only have one sender, but may 
have multiple submitters on its way to destination, just as it may have 
multiple hops for each submitter.


>In which case, the HELO root name list referenced

Remainder of this paragraph ignored.


>| 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.


I disagree with both statements.  The HELO domain clearly cannot play the 
role of SUBMITTER, because SUBMITTER is a mailbox, not a domain name. 
Also, the same mail server may send messages on behalf of multiple 
SUBMITTERS, but would require a RSET to change its HELO name.  Also it is 
pretty clearly not true that the HELO domain will be the same as the 
sending domain, unless we are considering changing the meaning of HELO.

Furthermore, I would point out that Doug's tone has changed here from 
questioning (such as "One possible view" or "Would it not be equivalent") 
to lecturing William and the other listmembers as to why *his* way works 
better.  This makes me believe that this is NOT all just a big 
misunderstanding, and that the behavior of taking someone else's message 
and commandeering it for his own purposes is indeed intentional.

If it is in fact intentional, I would like to point out that it is quite 
rude, and I would go so far as to say that this sort of behavior was one of 
the main stumbling blocks that made MARID fail.  Stubbornly insisting that 
one way is right, even if it doesn't have anything to do with the current 
thread, and even if the idea you are describing is specifically excluded 
from the current discussion, is not valid behavior for a collaborative 
working group.  (I know the WG chairs had a lot on their minds, but perhaps 
they should have been more strict about not allowing such selfish behavior)


>| 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.


Further indication that we have moved from "not quite understanding" to 
"disagreeing and lecturing"...


> 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


Looks like this is the essence of the sales pitch... Doug would prefer us 
not to read William's draft and instead to pay more attention to his own. 
No thanks.


--
Greg Connor <[email protected]>