Re: Queued Mail or Unreturnable Mail?

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