I'm about to submit an I-D proposing a neutral syntax that all email
senders can use to declare the Identity responsible for an SMTP
transfer. I've had some discussion already on the ietf-smtp and
spf-discuss lists, and I would like to get some feedback from the
ietf-clear list.
Before hitting the reply button, please note, this is not an alternative
authentication method. It does not attempt to resolve the question of
*which* identity to authenticate. It merely provides a *neutral syntax*
that any receiver can use to find out what methods the sender offers. The
intent is to avoid method-specific syntax, like SUBMITTER and SRS, and to
take a small step away from a de-facto standard that might use such syntax
as part of a "lock in" strategy.
The proposal is at
http://purl.net/macquigg/email/ draft-macquigg-authent-declare in various
formats. The htm and rtf formats show recent changes highlighted in yellow.
Objections raised so far are summarized at
http://purl.net/macquigg/email/IETF/authent-declare-objections.htm Please
read these before raising the same points. I'm interested in anything we
might add, or any better statement of the listed objections. Also, if you
feel the responses are incorrect, we can modify the response, or add a
rebuttal. The intent of this document is to avoid having the IESG spend
hours wading through long discussions on the lists. I've included
references to those discussions, but the summary needs to be short.
I assume CSV would use the ID field to just repeat what is in the EHLO
identity. There are some interesting possibilities, however, should you
chose to use a parent domain of the EHLO identity. In that case you could
continue to do your checks on the EHLO identity, but keep reputation scores
and possibly some authentication parameters at a higher level. This is
entirely up to the designers of the CSV method.
I think CSV could be the ultimate winner if given a chance to deploy
alongside the other methods, with no disadvantage from marketing and PR
factors. A neutral standard will help provide that chance.
--
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 *
************************************************************ *