At 04:13 PM 6/11/2005 -0700, Matthew Elvey wrote:
On 6/10/05 5:06 PM, Matthew Elvey sent forth electrons to convey:
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:
...
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.
I noticed that you didn't respond to this at all, but rather snipped it,
saying:
< snip discussion of DoS attacks. This is an issue separate from DNS
hunting.>
It ties in. In any case, I'd still like a response; I think this is
misinformation about CSV that you're publishing. Please reply.
We started to discuss the possibility of DoS attacks involving CSV, but
didn't finish:
http://mipassoc.org/pipermail/ietf-clear/2005-April/000273.html
In the next message Dave Crocker asked that we end the discussion, and I
respect his wishes on this list. As I have said before, of the available
methods, CSV would be my current best choice. The statement in my
Comparison document was as non-controversial as I could make it, and still
convey my understanding of the truth.
Just to be clear: there is no hunting IF CSV provides actionable
information (e.g. information that triggers administrator-defined rules
stating that the message is safe to accept or refuse without further
study), just like there is no hunting if the connecting IP is in a
whitelist or blacklist that the administrator fully trusts/assumes is
always accurate (as opposed to ones used as part of a scoring system).
There is no hunting if CSV provides actionable information AND the receiver
knows to try CSV first. It is this second assumption that the CSV
advocates seem unable to grasp. There is a similar problem with SPF
advocates being unable to grasp the concept that not all receivers will try
SPF first. These seem to be fundamental beliefs that no amount of
discussion will resolve. So I will leave the objection on my list for
later resolution by neutral referrees.
Actually, there is one variant on this objection that I think may be
reasonable. From http://purl.net/macquigg/email/ -
authent-declare-objections.htm:
"""
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.
"""
--
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 *
************************************************************ *