At 01:24 PM 5/11/2005 -0400, Terry Fielder wrote:
David MacQuigg wrote:
At 02:07 PM 5/11/2005 +0200, Julian Mehnle wrote:
William Leibzon wrote:
> Having read Mr Hardie's response, I believe he may have misunderstanding
> regarding concerns of the people involved in SPF Community and has
> incorrectly assumed that we're trying to interfere with somebody else's
> experiment and trying to prevent it from running.
Actually, we _do_. We _do_ want to prevent an experiment where plain
v=spf1 records are used for checking non-HELO/MAILFROM identities.
IMHO SPF should focus efforts not on preventing the experiment, but on
making sure the blame for bad results does not go to SPF. A proper
standard authentication header should indicate exactly what method was
used. e.g.
Authent: <IP Address> <Senders-ID> SPF1 PASS
If the domain that added this header actually used any method *other*
than SPF1, that is a clear violation, and the domain owner should bear
full responsibility.
I would just state the obvious. Results of using other methods with SPF1
records are unknown. I would put the prohibition in section 7.
The Received-SPF header MUST NOT be used by any other method. You may
want to change name of this header to allow for different versions of SPF.
The important question is if that exact experiment is what certain parties
want to happen. I very much doubt that the IESG or just the AD want it,
but obviously Microsoft's interests are different.
The folks at Microsoft are not dummies. If their published spec implies
a problem that will make SenderID less effective, they will fix their
implementation, maybe not their spec. They probably already have.
You are entitled to your opinion.
But you are assuming that the problem is solvable.
Specifically you are assuming that the problem is not inherent in trying
to use IP based authentication against RFC2822 names. I think that it may
be, or at least within the bounds of what sender id works with.
I'm not assuming the problem is not inherent, or that somehow you can check
the RFC2822 name against an SPF1 record. When I say "fix their
implementation", I have in mind actually doing an SPF1 check. They might
not fix their spec, or they might fix it later if it is necessary to help
others with implementation problems. I believe they are going for a
de-facto standard.
--
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 *
************************************************************ *