At 05:06 PM 6/10/2005 -0700, Matthew Elvey wrote:
On 6/9/05 11:21 AM, David MacQuigg sent forth electrons to convey:
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.
< snip discussion of DoS attacks. This is an issue separate from DNS hunting.>
There is often no 'hunting', because CSV will often provide actionable
information. A receiver will therefore often NOT try all possible methods.
You are assuming the sender offers CSV, and the receiver knows that.
Please see http://purl.net/macquigg/email/ - draft-macquigg-authent-declare
(.htm, .pdf, .txt, .rtf)
From the introduction:
"A receiver must try all possible methods, by "hunting" for DNS records at
various locations. The most costly DNS hunts will be for the typical
randomly-generated spammer name that offers no authentication."
And a more complete answer at:
http://purl.net/macquigg/email/ - authent-declare-objections
"We can't count on any of the current methods to become the one and only
method in use. As long as there is no standard way for a sender to declare
its ID, we have to search every possible identity, including subdomains,
and every method-dependent location, like _client._smtp.<ID>, and every
possible record type, like SRV, SPF, TXT, ... just to find out if any
authentication is offered."
I think we just need to agree to disagree.
I was hoping we could dispose of at least the simple factual
misunderstandings. I will leave it in. The issue is easily resolved if
the proposal ever gets to the stage where someone is actually considering
it for a standard.
Your scheme doesn't require network traffic, but it does require SMTP
server software be upgraded.
All authentication methods will require upgrades at each MTA that checks
authentication. Maybe some MTAs that are send-only could get away with no
upgrade. ( Those would be clients, not servers.) Our strategy should be
to make the upgrades free and easy, and to provide *incentive* for senders
to do the right thing. In my crystal ball, I see non-compliant senders
suffering from increasing levels of spam filtering as receivers tighten the
screws. That will give them the incentive.
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.
Hey, we are making progress!! Now if I can just convince D.C. that it
won't destroy the SMTP state machine and threaten the fundamental
infrastructure of the Internet ... :>)
<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?
Somewhere between your last post and the text above, the link got
altered. Try the link I just posted. Be careful not to merge text that is
separated by spaces or line breaks.
There were discussions on spf-discuss, ietf-smtp, and now this list. On
page 2, below the table of contents I have:
"The current working copy of this draft and a summary of mailing-list
discussions can be found at http://purl.net/macquigg/email";
In the summary are references to the specific threads where I found the
listed objections.
--
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 *
************************************************************ *