The following objections were raised in mailing list discussions. This is a brief summary. Full text of the discussions can be found at the dates cited.
Summary by David MacQuigg 6/13/05 updates will be kept at:
http://purl.net/macquigg/email/IETF/authent-declare-objections.htm
5/15/05 Sender's Declaration of Identity
Obj: Authentication will never stop spam. It can't be enforced. This ID proposal therefore has no value.
Resp: Many believe authentication will help recipients do the enforcement. The proposed ID will facilitate interoperation of different authentication methods, and therefore has sufficient value to be listed as an SMTP extension. The alternative is to allow each method to use its own ID syntax (e.g. SUBMITTER, SRS). This will result in a de-facto standard and possible "lock-in" of an inferior method.
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.
Obj: This ID will not work with method <xxx>. Using method <xxx> with any identity other than the <x-identity> will fail.
Resp: The only thing we must use the new ID for is locating the first authentication record. After that, the authentication record itself determines what methods may be used, and those methods determine what identity to use. For example, a method may specify that the only identity to be checked is the HELO identity, regardless of what the ID command says. Or it may use the ID command to over-ride a default identity. See section 4 for more discussion of these options.
Obj: The 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.
Resp: There is no change in the Internet infrastructure, and only a small change in the SMTP protocol – an extension, following the Extension Model described in section 2.2 of RFC-2821. While adding a unique "Sender's Identity" may seem radical to some, to others it is just one more service extension, and certainly no criticism of the original design of SMTP. To quote RFC-2821: "The Internet community now considers some services to be important that were not anticipated when the protocol was first designed. If support for those services is to be added, it must be done in a way that permits older implementations to continue working acceptably." That is exactly what we are doing, adding support for a service (email authentication) that was not anticipated when SMTP was designed.
Obj: The 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. See the archive of discussions that led to creating EHLO, rather than an extra query in SMTP.
Resp: There seems to be some confusion here over the use of the EHLO extension syntax. The RFC-2821 Extension Model says the server should advertise what extensions are available, and avoid the extra round trips for the client to try each extension and get a reject. That is exactly the way the ID command will operate. If the server doesn't advertise the ID extension, the client won't send it.
The Extension Model does not avoid the extra round trips necessary to *exercise* an advertised option. The AUTH command takes several round trips, depending on the authentication protocol. The ID command will take one round trip. Is this really a problem for a typical session with several thousand round trips?
Using the ID command adds one round-trip (command - response) per SMTP session. See the example in section 5 of the draft. This is an insignificant cost compared to the DNS hunting that will be required otherwise.
Obj: This scheme will require SMTP client software be upgraded. CSV requires only adding a few DNS records and making sure the EHLO identity complies with RFC-2821.
Resp: We could assume
a Default Identity (in the absence of an explicit Declared Identity). A good choice might be the second-level domain
name from the EHLO command. I'm hesitant
to include this in the standard, however, as it might
look like we are favoring CSV.
The requirements for a Default Identity are a) It must be
easy to determine from existing pre-DATA information in the SMTP session, b) It
must impose minimum burden on SMTP senders needing to change their setup, and
c) It must provide a compromise between aggregation and segregation of sender's
identities. Aggregation is necessary to
reduce the number of records we need to keep in our databases and DNS caches.
The second-level EHLO name might be too much aggregation for some large domains, e.g. rr.com might prefer to have separate identities for austin.rr.com, etc. The complete EHLO name is too little aggregation. The lack of perfection in picking a Default Identity is only an interim problem that will go away when a sender provides a Declared Identity.
5/19/05 Declaring an Identity
5/20/05 Avoiding the DNS Hunt
5/21/05 Alternative Neutral IDs
5/22/05 Email ID Declaration - Summary of Objections
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 off the path we are now following toward a de-facto standard with a "lock in" for whatever method wins the marketing and PR battles ahead.
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: We can't count on any of the current methods to become the one and only method in use. As long as there is no standard way for a sender to declare its ID, we have to search every possible identity, including subdomains, and every method-dependent location, like _client._smtp.<ID>, and every possible record type, like SRV, SPF, TXT, ... just to find out if any authentication is offered.
The most costly DNS hunts will be those that check every possibility and find no authentication records at all. A spammer could even maximize the load by making sure every identity had the maximum number of subdomain levels to search.
We can continue doing DNS hunts until the extension is available. However, by getting a neutral standard syntax now, while much of the authentication software is still in development, we will avoid having to do special upgrades later, just to add an ID command. Also, an early standard will avoid a lot of unnecessary development, deployment, and training using more limited alternatives like SUBMITTER and SRS.
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.
Obj: The new ID will require a new method to authenticate it.
Resp: No new method is needed. Authentication will be done by whatever method the ID owner specifies. For example, if the DNS records provided under <ID> specify SPF as the authentication method, then a receiver should run an SPF check, just as if the ID had been provided in the MAIL FROM command. The possibility of forgery is the same whether the ID is provided by the new command or by the MAIL FROM command.
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 sender 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.
Obj: Why should I care what the ID owner (who is trying to claim responsibility of some sort) wants or expects with respect to authentication tests?
Resp: When an email arrives with an ID declaration, the sending MTA is making a claim. It is saying - "Hello, this is <IP> sending to you on behalf of <ID>." If you check the authentication records for <ID> you will find what methods <ID> offers for you to authenticate that claim. No other identity in the mail transfer can be expected to offer authentication. There are legitimate reasons, or at least plausible excuses, for the other identities not authenticating.