In
<1106947728(_dot_)6505(_dot_)89(_dot_)camel(_at_)SJC-Office-DHCP-156(_dot_)mail-abuse(_dot_)org>
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
On Fri, 2005-01-28 at 13:20 -0600, wayne wrote:
On Fri, 2005-01-28 at 04:20 +0100, Frank Ellermann wrote:
This "new" draft is technically nearer to the last pre-MARID
"old" draft than draft-lentczner-spf-00 was. The latter was a
rather quick hack salvaging all syntax improvements found here
(= mxcomp) after MARID was killed and the old draft expired.
[big snip]
Here is a quote for the pre-MARID draft regarding the specified
processing algorithm limits.
6.2 Processing Limits
[stuff from, I'm pretty sure, spf-draft-200406 snipped]
This new draft is NOT a compatible change. It should also be noted this
pre-MARID process could entail orders of magnitude more lookups.
I disagree. In practice, at least, this is a very compatible change
because almost no one runs into the limits.
You should review which records would be used to evaluate the EHLO/HELO.
And yet another quote from Pre-MARID.
The <responsible-sender> comes from the domain name of the "MAIL
FROM" envelope sender. When the envelope sender has no domain, a
client MUST use the HELO domain instead. If the HELO argument does
not provide an FQDN, SPF processing terminates with "unknown".
Now the record applied against the EHLO/HELO identity could be found at
the zone apex AND at the EHLO/HELO. The results of this check have also
changed and is not consistent.
Yes, the zone cut stuff, while in spf-draft-200406, is certainly the
thing that I'm most willing to remove from
draft-schlitt-spf-classic-00. It has some nice properties, but it has
some problems also.
[another big snip]
This changes the pre-MARID, mid-MARID, and post-MARID algorithms!
I'm not sure what you mean by this. The zonecut stuff is in
spf-draft-200406.
[mx processing limit stuff snipped]
While this is, indeed, a change from the last pre-MARID SPF spec, this
limit has been in place in my libspf2 implemenation since long before
MARID existed, and hence is an existing practice. As discussed *many*
times on SPF-discuss, I can not find *any* legitimate emailers who
have come close to this limit. This change only effects abusers and
misconfigured systems.
I guess those that are affected are therefore illegitimate? To publish,
discover the limits in the code being used? Code that did not comply to
some or any draft? When are the next changes to the algorithm going to
be made? How can a disruption be avoided when there is NO MEANS to
introduce a new version without removal of the prior?
"A difference that makes no difference is no difference" -- spock
Yes, in theory, there are incompatible changes, in practice there
aren't.
[yet another big snip]
In essence, don't expect forwarding to function.
Yes, SPF and traditional alias/.forward type forwarding don't work
well together. The MAPS DUL list and all end users being able to have
their own MTA don't work well together. DomainKeys and mailing lists
don't work well together. NAT and many games/vpn/etc. don't work well
together. There are *lots* of changes that have happened that cause
other problems.
That section of the SPF-classic spec explains the situation. As an
email receiver, if you don't like it, you don't have to check SPF
records, check the MAPS DUL, check domain keys, or use NAT. Your box,
your rules.
I have not complained about a reduction in the limits, but rather a
change that imperils the publishers. I was complaining this draft still
does not allow a reasonable method to change processing algorithms
without potentially creating sizeable disruption. This is due, in no
small part, from a false expectation that a wildcard label provided some
utility and is the reason for usurping the use of the TXT RR. This was
wrong and remains wrong. Using a prefix on the record remains a viable
method to ensure SPF offers less disruption to users as well as other
protocols. If I was right once...
Lots of stuff here that I guess we will just have to agree to disagree
on. I don't agree with all the choices that were made with SPF, some
due to hind sight, some due to differening opinions. It still remains
far and away the most deployed designated sender system out there. It
doesn't appear that we make any fatal mistakes. IMHO, some of the
stuff you stuggest would be "better" would, actually, have been a
fatal mistake.
-wayne