On Fri, 2004-10-08 at 23:34, Greg Connor wrote:
[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]
These were earnest comments aimed at providing a fully comparable result
with few risks and changes to SMTP and with stronger identifications.
| 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.
Such assurance should not be considered the responsibility of the
mailbox domain owner when the mail channel description is open-ended.
In this case, there is no means to make assurances with respect to these
local parts. This should not be overlooked, as this open-ended approach
is very much needed to ensure delivery of much of the mail. Where the
mail channel description has been declared the exclusive source of a
mailbox domain, still this would assume each SMTP client is making mail
channel checks and that each is able to constrain the use of the local
part on behalf the specific domain. This seems to forgo the nature of
mail being relayed where the mailbox domain owner does not always
control all of these agents.
In the case where the mail channel has been declared the exclusive
source for the mailbox domain and where all the agents are controlled by
the mailbox domain owner, there may be an expectation of the local part
of the RFC2821 MailFrom being protected. This would be a special case
that should not be assumed by the recipient. Although the marid-mpr
draft makes the state of mail channel explicit and can also include the
RFC2822 From, SPF does not provide this information, such that no
presumptive expectations of even the mailbox domain itself being
protected is possible.
(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.
The goal of establishing the mail channel by way of submitters can be
equally achieved using a list of authenticated HELO root names
referenced by the RFC2822 From or even the RFC2821 MailFrom as the
message source. I don't want to lecture why it is bad to use the mail
channel description to serve the dual role of authenticating the SMTP
client. : )
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.
This statement was aimed at the ease of mapping the mail channel in many
cases. Yes, the HELO domain could change dependent upon the mailbox
domain being relayed, but the reason for doing so would be to properly
establish accountability. I contend accountability can not be shifted
to a mailbox domain in any other manner. This name can also be directly
authenticated whereas this is not possible with any other domain within
the mail channel without making assumptions of the mail channel
integrity.
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.
I had requested previously that William state the broader goals of this
proposal. This was not to elicit attacks on possible motives, but
rather a discussion of possible alternatives. What problem does this
suite of proposals solve? Finding a means to the same end without a
significant impact upon SMTP does not seem like commandeering for
questionable purposes. I could say the contrary may more aptly apply.
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)
The means to the same end was what I considered important in that this
is stating a means to the same goal and my comments are directed to what
I see as serious defects that can be mended. You seem to have
abstracted something sinister in these comments. I think being stubborn
would be a way of describing both views it would seem. Ignoring the
problems does not make them disappear however.
| 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"...
Care to comment as to why this role would not be stronger with HELO than
other derived names?
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.
I am not a salesman making a pitch that could compare to those I have
already heard. I find it unfortunate this is the typical depth of
consideration given to potential downsides or their possible solutions.
This is of shared goals but perhaps more focused upon ensuring
accountability is reasonably strong for there to be the possibility of
safely making assessments.
-Doug