In
<DLyNWND8yzdAFd/CvGJfKA(_dot_)md5(_at_)melkebalanse(_dot_)gulbrandsen(_dot_)priv(_dot_)no>
Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> writes:
Harry Katz writes:
Splitting off another further different topic.
If I understand section 6.1 of the SPF spec correctly, an SPF
receiver must abort evaluation if any unrecognized mechanisms are
encountered.
As others have mentioned, SPF treats unknown mechanisms different from
unknown modifiers. It is my opinion that modifiers are far more
useful for extending SPF.
In effect sending domains have to wait until substantially all
receiving domains have upgraded their software to support the new
mechanism -- and how would they know this? -- until they add the new
mechanism to their SPF record.
The same would seem to be true for infrequently used/supported
features. If, say, exchange or sendmail ships an incomplete spf
implementation that lacks macro support, wouldn't that prevent most
SPF sites from using macros, and permit more implementations from
shipping without macros, in turn encouraging more sites to do without
macros, etc, etc?
Yes, *IF* a significant number of sites checking SPF records don't
support certain SPF features, then this would make it unlikely that
these features will be widely used.
However, in practice, all SPF implementations that I know of try to
support the full SPF spec. There are some weak spots, such as support
for IPv6. There are also a bunch of areas where different
implementations give different answers but again, in practice, the
vast majority of SPF records work the same everywhere.
Anyone who tries implementing a partial SPF spec will find that they
can't process a significant number of SPF records. Therefore I doubt
that any major player will choose a partial implementation. This is
especially true since there are so many different SPF implementations
alreayd available for many different languages and under very liberal
licenses.
There is work being done to bring the different implementations of SPF
into convergence. From the very beginning there was test suite for the
first SPF implementation (the perl Mail::SPF package). This test suite
has been expanded by several people and is now used in various forms
by quite a few of the SPF implementations. More work needs to be
done.
Work is also being done to tighten up the SPF spec.
Pragmatically speaking, this means that no new SPF mechanisms will
be successfully introduced ever. I'm curious why this approach was
taken.
AOL.
As others have mentioned new SPF mechanisms will likely be supported
with a new SPF version number (e.g. v=spf2 instead of v=spf1). The
SPF spec says that domain owners can publish SPF records with
different versions and the implementation must check the highest
version number that it supports.
New SPF modifiers can be supported today.
In practice, there seems to be very little demand for new mechanisms.
There is only so much you can do with the IP address, HELO string and
MAIL FROM email address and, in practice, SPF seems to have most of
them covered. Extensions that have been discussed can all be done
with modifiers (rather than mechanisms), and even then, there seems to
be a fairly short list of things people can even see being done.
The area of RFC2821 validation just doesn't seem to be something that
will have continual change and expansion. While SPF provides for this
growth and change in several ways, I suspect that it is overkill. If,
a couple of years down the road, the SPF version 1 syntax proves far
too limiting, the SPF version 2 syntax could be XML, but I highly
doubt it.
-wayne