Douglas Otis wrote: > Mention of SPF should be accompanied with security > admonishments not to expand evaluation macros.
The fine print is a bit more convoluted, most macros are simply shorthands for "this domain", "space", or similar harmless cases. What you are talking about is the "this local part" macro, and some esoteric contructs to extract labels from "this local part". I'd love to know if anybody actually uses these baroque features. In one case I'm aware of the policy hit the RFC 4408 processing limits, "PermError", tilt, game over. > these lists are often incomplete and allow NEUTRAL > or SOFT-FAIL results. For the "accept and bounce later" question a PASS is good enough. It's also a start for white listing and reputation schemes. I also like either PASS or FAIL better, but sometimes that's no option... > Such results are easily exploited. ...exploiting NEUTRAL makes no sense, it is just what you have without XYZ (not limited to SPF), you won't get a bonus for trying in vain. Quite the contrary, after receivers wasted their time and bandwidth for nothing (NEUTRAL) they could treat it slightly worse than only NEUTRAL. Abusing SOFTFAIL cannot work, it is already tricky to use it in any meaningful way. It's in the drirection of DKIM-ADSP "all", it lets receivers do "something" with it, anything from "ignore" to "discard them all". > SPF's use of generic TXT records at base domains is > unlikely to completely transition to the service > specific resource record, and will conflict with > future protocols and revisions. For wildcard uses that is already the case, sooner or later folks hopefully decide that using SPF records is better. If there is ever a v=spf3 it will build on the new SPF RR alone, and not abuse TXT. > expecting MX for acceptance eliminates publishing > or retrieving other SMTP related records within > sub-domains lacking MX records. A decree that everybody should have "v=spf1 mx -all" implicitly (without saying so) for all addresses, and similarly "v=spf1 a -all" for HELOs, is a nice idea in the spirit of RFC 821, but I fear it comes decades too late. Assume for a moment that a "v=spf1 mx -all" could be mandatory. Then publishing SPF policies stating this fact would be unnecessary, and we could get away with a variant of BATV. But obviously that's not the case, folks use other IPs to send, not only the MX IPs, and some policies aggregate more than one sending ISP. Frank -- <http://www.openspf.org/Frank_Ellermann/OAQ>
