------- 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: [email protected] ReportedBy: [email protected] CC: [email protected] [ 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
