In <FBFCEBBC-5953-4FC4-9F5F-F27854769165(_at_)mail-abuse(_dot_)org> Douglas
Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
On Aug 26, 2005, at 12:56 PM, wayne wrote:
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, [...]
There isn't a "pristine" version of SPF, there are several different
draft specifications and a whole bunch of implementation. There are,
unfortunately, conflicts between these. The SPF-classic I-D attempts
to document the most coherent intersection of these.
The reduction in processing limitations seemed substantial with
understandable reasons.
The reduced process limits has existed dating back to Feb 23, 2004 in
the libspf-alt implementation. It was picked up later (still
pre-MARID) by at least one other SPF implementation.
There was a change that including HELO in
parallel with the MAIL FROM rather than when the MAIL FROM was NULL.
Independent HELO checking was argued for since the summer of 2003.
The Spamassassin development version was doing HELO checking in the
Dec 2003 or Jan 2004, I'm not sure which. The change in the spec
dates back to May 16 2004. While MARID was going on at that point, it
was still before the MARID WG had adopted any drafts.
In reality, this is an incredibly minor change because almost all
MTAs send email with a null MAIL FROM every once and a while, so the
HELO domain would be checked at least some of the time. Having it be
checked all the time makes very little practical difference.
A number of other changes have since been struck.
Yes, there were a HUGE number of incompatible changes made during the
MARID process and, in hind sight, starting with the MARID drafts and
trying to make it compatible was probably a mistake. However, we did
try to eliminate as many changes as we could find.
Problems created
when modifying record processing or what identifies are applied could
be ameliorated through use of record versioning.
Maybe, but the implementations that did the processing limits were
deployed in early 2004, so unless you have a time machine, we are
pretty much stuck with them now.
While I agree with the view that PRA semantics may create problems
s/may/will/
when applied against the initial record version, the Sender-ID draft
permits the use of a scoped version of the record which makes it
clear what semantics are expected.
Our goal in writing the spf-classic draft was to document what is and
was, not to create something new. The job of creating something new
was given by Ted Hardie to the MARID authors.
Accommodating this identical
provision within SPF would have resolved the potential Sender-ID
conflict and also would have been a means to acknowledge adherence to
newer processing limits and HELO checking, for example.
The SenderID drafts have never contained the HELO identity. This
makes it not fully backwards compatible with SPF-classic. The
SenderID drafts are not under our control, so we can't fix it.
-wayne
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf