At 06:34 PM 4/12/2005 -0400, Mark Shewmaker wrote:
On Tue, Apr 12, 2005 at 10:45:46AM -0700, David MacQuigg wrote:
>
> My sense of the spirit behind this objection is that the IETF wants to
> maintain neutrality between the competing methods. Clearly that can't be
> done for every item in a spec on SPF, but I think it can for this
> item.
SPFv1 records beginning with "v=spf1 " can't be reliably used for
non-(mailfrom, helo) testing for all domains, and thus recipients
doing so must not be considered to be compliant with the spec.
That spec must reflect that in one way or another.
No problem. If the sender provides SPF1 records, then the authentication
must follow SPF1 rules.
I see no way to be neutral here.
The neutrality has to do with how the sender declares its ID, not how that
ID is authenticated. I think you are reading too much into what I
proposed. This is a trivial matter technically, but one that might make a
big difference politically.
> What if we added words like:
>
> A sender must flag an identity in one of the existing email commands,
or it
> may add a new one. To flag an identity, put the string *ID* after the
> declared name.
"Officer, here are my ten separate passports for this country alone, and
here is the single one that I want you to examine for authenticity."
To make this analogy a little closer to the current email authentication
system, the officer has no power, most citizens have no passport at all,
and the industry association that hired the officer is trying to get
voluntary compliance with passport authentication. There are at least four
different types of passports. We have no control over that.
To make things even more difficult, the differences between the four types
of passport cannot be seen by the officer. He has to make multiple queries
just to find out what type of passport he needs to check. The process is
so inefficient that most citizens just ignore it and go through without any
passport check.
The SMTP model we're working under doesn't have us using or designing an
authentication-method negotiation system between the sender and
recipient.
I don't see much negotiation here. The sender will say "Here is my ID.
Take it or leave it."
If we were free to alter SMTP, we could add some sort of
authentication and authentication-method negotiation, (maybe even doing
some type of really cool zero-knowledge proof stuff), but we don't have
the freedom to do that at the moment.
So since we're using the existing SMTP protocol, the sender is going to
be presenting all their potential credentials anyway, which means that
there's no advantage to the recipient in listening to any preferences the
sender tries to say about which credentials he'd prefer the recipient
examine, and which ones he'd prefer the recipient didn't examine.
So what do you do if your sender is using CSV, and you are expecting SPF?
The sender should have no input whatsoever in how the recipient decides
to authenticate the credentials that the sender can't help supplying.
You seem to be assuming that the sender will provide DNS records for any
method that the receiver might prefer. I think it is more likely the other
way around. The sender will chose its preferred method, and the receiver
must comply.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf 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 *
************************************************************ *