The barrier to implementing CSV's CSA is trivial, or at least as trivial
as implementing this syntax. Given 3 options:
1. Do CSV and this neutral syntax.
2. Do this neutral syntax, but not CSV
3. Do CSV, but not this neutral syntax. (If CSV doesn't yield any
actionable information, proceed with other Identity establishing
shemes: Check for valid Domain Keys, then useful SPF records, etc.)
I see no reason not to go with 3. (Other than politics - i.e. I see no
technical reason...)
On 5/23/05 2:51 PM, David MacQuigg sent forth electrons to convey:
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.
This URL still does not work. Google helped. A discussion forum should
be specified in the I-D. Current draft and discussions are where?
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 *
************************************************************ *
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear