In
<Pine(_dot_)LNX(_dot_)4(_dot_)60(_dot_)0505261710370(_dot_)635(_at_)hermes-1(_dot_)csi(_dot_)cam(_dot_)ac(_dot_)uk>
Tony Finch <dot(_at_)dotat(_dot_)at> writes:
On Thu, 26 May 2005, Carl Hutzler wrote:
I wish there was a way to utilize the relatively large number of SPF records
in a technology like CSV.
It seemed to me at one point that there was some promise that it would be
possible to write an SPF record which applied only to HELO or only to PRA
or only to the return path.
Yes, at one point there was the ability to limit SPF version 1 records
to only certain scopes, but the scope= modifier was removed in the
fall of 2003. At the time, we really couldn't think of a reliable way
of applying SPF records to the 2822.From: header, and it was thought
that distinguishing between the 2821.MAILFROM and 2821.HELO identities
was not needed.
After widespread experimentation with SPF started in Dec of 2003, it
made changes to the SPF specification very hard.
However divergent SPF/SenderID implementations
and specifications have horribly muddied the waters and I'm not sure it's
possible to do this now and expect any kind of reliable interoperability.
Disaster.
The goal of the latest SPF-classic (e.g original SPF) I-D is to
document what exists, not to try and create a new SPF protocol. We
have worked very hard to try and keep as much of the semantics of the
draft-mengwong-spf-0[01] documents as practical.
It is true that the MARID I-Ds[*] define a newer protocol with updated
semantics that include things like the return of scopes to SPF. These
I-Ds also call for a new version number to be used, which is good, but
then these I-Ds say that the new semantics should be applied to SPFv1
records, which is REALLY bad. I have asked the IESG to block the
publication of the MARID I-Ds due to the harm that will cause to the
existing SPFv1 deployment. So far, the IESG has not agreed with this
and the incompatible MARID I-Ds are going forward.
-wayne
[*] At one time, Andy asked the PTB whether the existing SenderID
trademark would cause legal problems for the IETF/ISOC if we
published I-Ds using that trademark. Andy came back and said the
risk is too high and that SenderID shouldn't be used in IETF RFCs.
Until such time that I hear that the PTB of the IETF have changed
their mind, I am trying to avoid the use of "SenderID" when
referencing the MARID I-Ds.