|
Re: Sender's Declaration of Identity
2005-05-28 08:52:31
Dave,
I appreciate your comments, and I will do my best to include your
objections in my summary at http://purl.net/macquigg/email -
authent-declare-objections.htm. I think I have most of these already, but
I will use your wording where it is better. See my responses below, and
please correct me if I'm wrong on anything. Some of the objections are not
resolvable, as they involve assumptions about the future, but others are
just a matter of finding the facts. It would be nice if we could resolve
the factual misunderstandings before presenting this to the IESG.
You may have read only the initial revision of the draft. I have added
many clarifications as a result of the discussions. These are highlighted
in yellow in all but the txt format. See the link above.
At 09:13 AM 5/28/2005 +0200, Dave Crocker wrote:
1. Your proposal presumes that there is a single, universal reference to be
used, among protocols that have widely different semantics. There isn't.
Response: The ID declaration does not favor one authentication method over
another. It does not expect the methods to use the common identity. It
simply facilitates access to whatever methods the sending MTA provides. It
is the methods themselves that decide which identity to check. CSV can
continue to use the EHLO identity. SPF may decide to let the declared ID
override the MAIL FROM identity. Each method can chose what is best.
This objection is very similar to one from this group I have listed already:
Obj: Inter-operability and trust cannot involve different independent
identities. We must choose one identity, and that is what MARID tried to
do already. There is no point to having a common ID without an agreement
as to which identity we mean.
Resp: Inter-operability requires that each sender-receiver pair have at
least one method in common. It does not require one method or choice of
identity for the entire Internet or even for all the MTA's along the path
from originator to final destination. MARID tried to reach agreement on
some difficult questions, including the choice of identity. The proposal
is for a standard form to declare an identity, not a limitation on which
identity that must be. Agreement on this simple standard will help
overcome the paralysis we have seen after the MARID failure.
Also this from [spf-discuss]:
Obj: The ID method cannot authenticate all the permissions that various
identities have granted the sending MTA. These permissions may be
important to a receiver.
Resp: The ID declaration is just that - a declaration. It is not an
authentication method. It does not take sides in the battle over
authentication methods. It simply facilitates access to whatever methods
the sending MTA provides. It does not prevent a receiver from trying other
methods. It does not prevent a receiver from rejecting a sender that
doesn't provide a receiver's favorite method.
Also these paragraphs added to section 2:
The ID command provides a domain name independent of other names in the
envelope and headers. It should be a short, memorable name to enhance its
value as a Public Mail Server identity. There are three semantics
associated with this new name.
1) It may be used for accreditation and reputation.
2) It may be used to specify the location for authentication records.
3) It may be used, after authentication, as a bounce address for complaints
and challenges relating to spam.
2. Your proposal presumes that exactly one mechanism will be used. That's
not a
safe assumption.
Response: The owner of the ID can provide any methods that it
chooses. The receiver can use any or all of these methods.
3. Your proposal seeks to modify the SMTP protocol exchange state diagram.
That's rather a major change to the Internet infrastructure. It is something
that has been avoided throughout many, many changes since the creation of
smtp.
I don't understand. The response to EHLO is a list of extensions. We are
adding one more extension. If the ID extension is offered in the EHLO
response, the sender may send an ID command, but it is not required to do so.
Somewhat related from [spf-discuss]:
Obj: Getting an SMTP extension will take many years, and by that time
everyone will be using <my method>, so no DNS hunting will be necessary.
Resp: Getting an SMTP extension should not be that difficult if we follow
the standard IANA procedure for registering keywords and their
parameters. Other keywords relating to spam, such as NO-SOLICITING, have
been registered already. See http://www.iana.org/assignments/mail-parameters.
4. Your proposal adds a round-trip cost to the SMTP session. That is
something
that has been very, very forcefully avoided since the creation of
SMTP. Please
review the nature of EHLO as a means of adding options to SMTP and note
that it
does not add a round-trip.
Using the ID command adds one round-trip (command - response) per SMTP
session, and only for those sessions that wish to use authentication. This
is an insignificant cost compared to the DNS hunting that will be required
otherwise. It is not necessary to use the ID command, even if it is
offered. Older systems will not have any added round trip.
I am assuming the use of a normal EHLO extension. Originally, I thought I
could just add an extra string at the end of the EHLO command, but it
appears that the RFC-2821 EHLO syntax did not anticipate any
extensions. Please explain what you mean by using EHLO to avoid adding a
round trip.
5. As others have quite forcefully noted, your proposal does not make a
case for
it's solving a significant problem.
Are you saying that avoiding a DNS hunt is not solving a significant
problem? I understand others have noted quite forcefully, but usually this
"forcefulness" only lowers the signal-to-noise ratio. Unless we accept
"hate it" as a valid objection, we need to tone down these discussions, and
focus on getting at the facts and underlying assumptions.
One of the less forceful folks was able to explain his assumptions. It was
a plausible assumption, but one that I don't share. This is one of the few
issues that really will require wisdom and foresight to decide what is
right, and one of the few that should be presented to the IESG. Here is
what I distilled from the earlier discussion:
Obj: DNS hunts will not be necessary. Receivers will use whatever method
they prefer, and senders will have to offer all methods.
Resp: This assumes a future in which receivers call the shots and senders
have to offer every method receivers may want. A more likely future is an
extension of the current situation with receivers wanting to use any and
all methods that will work, and senders wanting to do the minimum necessary
to avoid losing reputation.
Whatever the future, DNS hunts or not, there are still advantages to having
a universal ID declaration, and no disadvantages.
Email IDs can be a powerful motivator in changing our email culture. A
reputable ID will become a "broadcast license" to be treated with
respect. Anyone wanting to operate a Public Mail Server should have no
objection to offering an ID. Owners of reputable IDs will not tolerate
abuse of those IDs. Receivers will quickly learn which IDs they can
trust. The rest will be easily ignored, even if spammers own 99% of the
Internet.
Having a neutral syntax for an ID declaration is one of the few things that
all methods could agree on. This is a small step away from a de-facto
standard with a "lock in" for whatever method wins the marketing and PR
battles ahead.
---
I think that last paragraph should be of special interest to CSV. In spite
of its technical advantages, CSV is losing the marketing and PR
battles. Wouldn't it be nice if you could deploy CSV without facing the
"chicken-and-egg" problem?
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *
|
|