[Top] [All Lists]

Re: Queued Mail or Unreturnable Mail?

2008-05-05 11:22:54

On May 5, 2008, at 4:38 AM, Frank Ellermann wrote:
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.

Macro expansions of email-address components may induce recipients into generating DNS transactions from cached SPF records. This feature dramatically reduces resources expended for staging DDoS attacks. Indeed, expansion of local-parts permits the greatest amplifications. Local-part expansion and the "exists" macros seem of minimal utility for legitimate purposes.

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...

Some recognize no SPF authorization can be complete. What handling occurs for messages resulting in NEUTRAL?

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.

SPF reduces delivery integrity? NEUTRAL represents the same status "as if" no SPF records exist.

Abusing SOFTFAIL cannot work, it is already tricky to use it in any meaningful way.

SPF records must be evaluated?

It's in the direction 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.

Impediments inhibiting new resource record types weigh heavily against promoting ubiquitous publication for yet another optional SMTP feature. At least mandating publication of MX records permits discovery consolidations.

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.

A mandate to publish MX records will not impact where messages might originate as this does. However, the mandate will impact where policy records such as SPF or ADSP are to be found.

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.

DKIM provides a means to identify sources without reliance upon IP address path registration that is unlikely to scale. Especially while the IP address space increases in complexity.