Hi Stuart, I appreciate the one positive suggestion in this entire discussion.
At 11:48 AM 5/20/2005 -0400, Stuart D. Gathman wrote:
On Thu, 19 May 2005, David MacQuigg wrote:
> OK, let's nail this down. Here is the example incoming email, with the
> proposed ID command. Assume you have no prior relationship with the
> sender, so you don't know what authentication method he uses.
>
> EHLO mailserver7.bigforwarder.com
> ID bigforwarder.com
> MAIL
FROM:<<mailto:bob(_at_)sales(_dot_)some-company(_dot_)com>bob(_at_)sales(_dot_)some-company(_dot_)com>
The ID command offers zero information. If gives us yet another name,
as if we didn't have enough already. So now, in addition to
HELO, MAIL FROM, Header From, PRA, etc identities, we now have the ID
identity.
All the other identities have been assigned meanings already. The new
identity can be used for the sole purpose of authentication, without
"overloading" any other field.
There are currently zero, zip, nada, protocols even proposed for
authenticating the new ID identity.
And I don't intend to add any. We have enough authentication methods already.
Worse, no MTAs currently have
an "ID" identity. Only RFC compliant MTAs (a rare breed) have
a HELO identity (most MTAs put invalid garbage there). Spam email often lacks
a "Header From" identity (by not including a From header). The PRA identity
is defined in such a way that every email has one, but you need a patent
license to use it. However, every single single email from every MTA on the
planet has a MAIL FROM identity, and no one has patented using MAIL FROM
as an identity (yet). And you don't need to read the entire message before
checking the MAIL FROM id. That is why MAIL FROM protocols like SPF and SES
are the obvious basic identity check before messing with anything else.
It's a good argument, and I wish the rest of the world would agree, but I
don't think that will happen. So I'm trying to come up with a way to allow
everyone to keep the existing identities as is, and still indicate their
choice for authentication.
It might actually be useful if the "ID" command mentioned what
authentication protocols were supported for existing identities rather
that introducing yet another identity.
E.g.:
EHLO mailserver7.bigforwarder.com
ID SPFv1,SenderID
MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>
OK. This will work. It's not as useful as what I have proposed, but it's
a step in the right direction, and I can support it.
Does everyone agree this would be useful?
It has already been pointed out that SPF records could list addition
identity checks supported as a modifier (useful if you always check
SPF first).
A sender not using SPF will not have any SPF record, even one telling us
what other identities to check.
--
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 *
************************************************************ *