On 6/9/05 11:21 AM, David MacQuigg sent forth electrons to convey:
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?
It's new. There are few working implementations, and little evangelism yet.
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.
So?
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.
I told you, I already read the draft, at least the one that was posted
at the time. I found the following quote on your site:
"The large number of authentication records [of CSV] might make this
method vulnerable to a DoS attack."
This statement is unsubstantiated. Because far fewer domains need to
have ANY records in the CSV scheme, this may mean that CSV requires
fewer DNS records than, say SPF. Said differently: Ok, with SPF or QR,
one DNS record can authorize all the servers for an entire domain. With
CSV, one DNS record can a server for many domains. E.g. a webhost that
hosts 1 million domains, and runs 10 SMTP servers to service those
million domains. That's a million or so SPF records, vs. 10 or so CSV
records.
There is often no 'hunting', because CSV will often provide actionable
information. A receiver will therefore often NOT try all possible methods.
I think we just need to agree to disagree. Your scheme doesn't require
network traffic, but it does require SMTP server software be upgraded.
Unlike SPF or SID it doesen't have severe negative consequences that I
can see. Because your scheme doesn't require ANY network traffic, I can
see why option 1 above is reasonable.
<line breaks moved>
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.
The error I get is: The requested URL
/~edatools/home/email/draft-macquigg-authent-declare was not found on
this server after some redirect.
The problem is on your end (no file type suffix).