At 01:38 PM 5/23/2005 -0400, Stuart D. Gathman wrote:
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.
Sorry for the confusion. It is a new identity *semantically*, but in
practice, the same literal identity as one or another of the existing
identities. It *could* also be a new literal identity, but it would be
rather strange for sender to provide a declared identity different than all
of the identities he has already provided. My original proposal did have a
"flag" syntax to simply flag one of the other identities, but I changed
that when I found out I couldn't flag the EHLO identity without incurring
the wrath of the SMTP gods. :>)
I guess the big exception to this would be an independent forwarder,
neither whitelisted by the receiver, nor authorized by the sender. That
forwarder, to be compliant, must authenticate its sender, and offer its own
ID to the next receiver.
The big issue we have been discussing, and which I listed as an objection,
is the alleged need for a new authentication method. My focus on that
debate is what made me say "no 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.
When I read the abstract of the SUBMITTER proposal, I thought - Great. We
can use that as our universal ID. Then I read a little further and found
all these frivolous restrictions to PRA only!! If Microsoft is smart, they
will drop those restrictions on this proposal, get a standard, and find
some less transparent way to get their lock-in.
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.
The problem with using MAIL FROM as the universal ID is more than just
crappy syntax. The Return-Path semantics will be a problem for CSV. You
could munge in a second ID field, as done in SRS, but you still have the
Return-Path semantics, albeit a different Return-Path.
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.
My intent is to satisfy the two fundamental requirements in the draft. If
we should change those requirements, or if there is a better way to meet
those requirements, I would sure like to hear it.
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'll be watching with great interest.
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.
"Chicken-and-egg" is an analogy I've always thought a little strange for
this situation. I think of it as a logjam. We have a deadlock between the
different groups. Pressure is building from outside forces. Kicking loose
one piece could get the whole mess moving. We just need a little
leadership from the IETF.
If there are no additional objections to the proposal, I'll submit what I
have, including the currently 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 *
************************************************************ *