[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 <dotis(_at_)mail-abuse(_dot_)org> 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 <gconnor(_at_)nekodojo(_dot_)org>