[Top] [All Lists]

Re: Sender's Declaration of Identity

2005-05-28 08:52:31


I appreciate your comments, and I will do my best to include your objections in my summary at - 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

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?

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *