------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1294
Summary: SPF TYPE99 deprecation
Product: Exim
Version: N/A
Platform: Other
OS/Version: All
Status: NEW
Severity: wishlist
Priority: low
Component: Lookups
AssignedTo: pdp@???
ReportedBy: pdp@???
CC: exim-dev@???
[ Tracking bug for feedback and noting anything that comes up. ]
The current draft for the formal standard for SPF (not the current Experimental
RFC) gets rid of TYPE99 SPF record usage and just uses TXT for everything.
http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/?include_text=1
(is draft 07 at time of writing)
In practice, few use SPF now, and those that do are likely using TXT too, which
is the _only_ rrtype some huge percentage of folks have deployed for their
domains' SPF records.
We should not remove the _ability_ to use SPF/99 records from Exim, but we
should make sure that we can optimise for the new acceptance of reality instead
of past protocol descriptions.
At present, we:
* ensure that we know T_SPF is 99 for platforms lacking that type; harmless,
should stay (rrtype number recycling will be a long process, we can get rid of
this in a couple of decades if needed, but will probably still be a harmless
historical alias even then)
* have a different default for string joining dnsdb lookups of type SPF;
that's fine, perhaps we only need to make sure that the TXT lookup types in
docs always have clear examples for how to use the correct string joining rules
for SPF records in TXT rrtypes.
* use libspf2 for lookups/spf.c and whatever functionality that library
chooses to use; similarly for spf.c in main src dir, which is used by the "spf
= ..." ACL condition.
As such, I don't currently see any action we need to take, except perhaps some
documentation bits should SPF support move out of experimental.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
