Matthew, I appreciate your response. I didn't think anyone on this list
was interested.
At 09:21 AM 6/9/2005 -0700, Matthew Elvey wrote:
The barrier to implementing CSV's CSA is trivial, or at least as trivial
as implementing this syntax.
Implementation barriers are not what is holding back authentication. The
problem is lack of a simple standard that will allow all methods to be
widely deployed.
I would like to see CSV more widely deployed. Why isn't it happening?
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.)
Given N methods, there are 2**N options for which methods a sender may install.
I see no reason not to go with 3. (Other than politics - i.e. I see no
technical reason...)
DNS hunting. If you don't know what I mean by that term, read the
introduction to the draft.
You MUST read at least the first four pages of the draft before we can have
a productive discussion. I would appreciate your reading also the summary
of objections that have been raised so far. You can find the draft and the
summary at http://purl.net/macquigg/email
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?
This is the first I have heard of any problems with the URL. Can you reach
any of the parent domains? Send me the details off list.
--
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 *
************************************************************ *
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 *