Does it require some new authentication method, or can we trust it to
really be the sending MTA's Declaration of Identity?
A discussion on the proposed ID command, and the possibilities of its abuse.
At 01:24 PM 5/20/2005 -0400, Stuart D. Gathman wrote:
On Fri, 20 May 2005, David MacQuigg wrote:
> We have enough authentication methods already.
Then what's to prevent me from saying:
ID BillGates.microsoft.com
Assuming this is a legitimate domain with an authorized Public Mail Server,
you will not have access to its authentication records. These records will
not authorize your mail server.
Assuming it is a spammer domain, with a complete set of DNS records
authorizing everything, it will quickly get a D rating (known spamming
domain), as soon as you send the first few phishing scams.
Any identity is hearsay until there is some protocol for verifying it.
The point of SPF is to move the MAIL FROM identity from hearsay to
something that can be verified (the HELO identity can already be
verified using the A record, but SPF offers some additional options).
Nothing in the ID command is hearsay. You didn't get the information from
someone else. You can't claim that using someone else's ID was an innocent
mistake. It isn't some Return-Path that blew in from China. It isn't some
HELO name that nobody has ever paid attention to. It is a name with a new
and specific purpose, a purpose so clear that even a dummy can't innocently
screw it up. When you put an ID command in your SMTP session, you are
saying - This is my Public Mail Serving ID, and I accept responsibility for
this mail transfer session.
I like the analogy someone brought up a while back. A stranger arrives at
the border with a bundle of IDs, friends, family, etc, maybe even a few
from another stranger who asked him to carry them across the border. The
guard has to check every one, and there is a legitimate excuse for every
failure.
With an ID command, the border guard says - Give me an ID that authorizes
you to cross this border!! Present a false ID, and you are in trouble.
Please give your next response some thought. I feel like we are very close
to a resolution of this question, and I don't want the discussion to
degenerate into noise. I'm not saying you would do that, but I have been
frustrated in similar discussions when people generate noise rather than
re-consider some firmly-held belief.
--
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 *
************************************************************ *