On Mon, 23 May 2005, David MacQuigg wrote:
You must not have read the summary in the 7 minutes since I posted. This
is not a new identity, just a way to declare an existing identity. It is
no more a new identity than SUBMITTER or SRS.
Obj: The new ID will require a new method to authenticate it.
Resp: No new method is needed. Authentication will be done by whatever
method the ID owner specifies. For example, if the DNS records provided
under <ID> specify SPF as the authentication method, then a receiver should
run an SPF check, just as if the ID had been provided in the MAIL FROM
command. The possibility of forgery is the same whether the ID is provided
by the new command or by the MAIL FROM command.
If the new ID is identical to MAIL FROM, it is redundant. If it is
not identical, IT IS A NEW IDENTITY. I don't know why that doesn't register,
I feel like I'm insisting that water is wet. The fact that you
propose to reuse SPF records at the domain owners discretion doesn't change the
fact that you are defining a new identity. Your proposal is MUCH
better than Microsofts because at least the SPF record reuse is specified by
the domain owner and is opt-in. But it is still yet another new identity.
SUBMITTER declares an rfc2822 identity (PRA) in the rfc2821 phase to
avoid having to read the entire message before validating it.
The MAIL FROM identity does not need SUBMITTER, because it is already in the
2821 protocol! SUBMITTER is only needed to optimize checking
the PRA identity which is an rfc2822 identity.
I believe I understand the motivation for your proposal - you hate the way the
MAIL FROM identity is overloaded to do things like SRS, SES, Verp, etc. So you
want to declare a nice clean identity that is free from all that crap. That is
great. I understand. But it is still a new identity. It is not MAIL FROM,
PRA, HELO, or any existing identity. I sincerely wish you luck, and will
gladly implement any validation method for your new ID when you get around to
defining one. But it is unrelated to SPF.
Perhaps your intent is for the ID identity to be the "originally
intended MAIL FROM identity". That is a laudable goal, but is not
something that currently exists. It is a new identity. It is
not the MAIL FROM identity that SPFv1 validates.
When we get to SPFv2, with support for scopes, then we should
perhaps support your ID scope along with PRA, MAILFROM, HELO, etc.
I believe the SPFv2 proposals do exactly what you intend. They
declare multiple identity scopes, and validation methods for each.
I understand the frustration with a chicken and egg problem.
It *is* really nasty the way MAILFROM is overloaded. But SPFv1
uses MAILFROM because it is always available, and can be reliably
checked at administrative borders, not because it is ideal.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.