Re: SPF instead of MX? was:Queued Mail or Unreturnable Mail?

On May 5, 2008, at 1:18 PM, Frank Ellermann wrote:
> Douglas Otis wrote:
>
> > Local-part expansion and the "exists" macros seem of minimal  
> > utility for legitimate purposes.
> The possible purposes are obvious, "per user" policies treating the  
> local part as labels, and "exists" be a a way to get around the  
> "check at the border" limitation for MAIL FROM, by definition HELO  
> checks work everywhere.
To inhibit simple spoofing, separately labeled resource records would  
be required for each user and for each outbound server.  A Per User  
strategy also exposes valid recipients by way of DNS.  Per User  
controls should occur opaquely and before a message is sent to prevent  
harvesting abuse.  Per User unique records also place inordinate  
resource burdens upon already heavily taxed receiving MTAs.
> I'm still curious how minimal such uses are, and if they could be  
> simply deprecated as nice try.
A few domains use "exists" to selectively issue negative responses.   
The complexity, burden, and security hazard imposed by the exists and  
local-part macro mechanisms hardly justify their limited utility.   
These mechanisms should be dropped due to security concerns.  The fact  
that few domains use these mechanisms should make this decision easier.
> On the border of legitimate is using "exists" for logging, receivers  
> are likely not interested in this job.  OTOH "exists" is not the  
> only way to arrange logging.
A way to log "This receiving MTA executes dangerous scripts."

> > What handling occurs for messages resulting in NEUTRAL?
> Specified with not less than a MUST is "like NONE".  But what  
> receivers in practise do is "receiver policy", they could decide  
> that a Gmail NEUTRAL or a Paypal SOFTFAIL is bad.  When they decide  
> this it is their decision, no part of the protocol as specified.   
> The same goes for a "best guess" approach for domains without  
> published policy.
A receiver's questionable behaviour justifies a domain publishing an  
address list followed by '+all' since proper handling of NEUTRAL is in  
doubt.  Otherwise, white-listing using this mechanism would place  
forwarded messages at risk.
> Your MX idea, roughly "v=spf1 mx -all", is near to a best guess  
> "v=spf1 a/24 mx/24 -all", but nobody would dare put this into a RFC  
> for various good reasons.
The purpose of publishing MX records is not to support typical SPF  
default "best guess" strategies.  The MX record would clearly indicate  
whether the domain supports SMTP.  This mandate protects domains not  
publishing an MX record, and greatly simplifies the means to determine  
whether a domain is being spoofed within an email address.  Such  
determination can be used to bypass other resource intensive checks,  
such as wildcarded SPF record sets, ADSP, etc.
> > Impediments inhibiting new resource record types weigh heavily  
> > against promoting ubiquitous publication for yet another optional  
> > SMTP feature.
> The spammers recruit new SPF publishers, anybody finding his inbox  
> flooded with misdirected bounces is motivated to learn this within  
> hours, not days.  Fortunately the esoteric macro and "exists"  
> features are unnecessary for ordinary my.domain.example users.
The esoteric SPF macros nevertheless represent a potential for harm.   
Make this process safer.  SPF plug-ins should exclude processing  
exists mechanisms and local-part macros.
> > 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.
> Then I misunderstood your goal, are you "only" talking about "v=spf1  
> -all" for domains never sending any mail ? Some folks here  
> volunteered to address this issue in an I-D after the debate to  
> limit the A-fallback to IPv4 in 2821bis ended inconclusive.
It is not clear where this might lead.  It is absurd to suggest all  
other domains should publish bogus MX records targeting the root  
domain or SPF records declaring no mail is sent, to avoid having a few  
remaining percent of the domains who _are_ using SMTP bother to  
publish MX records.  To say the least, bogus MX records or negative  
SPF records will not scale, and would be most unfair to the Internet  
in general.
> Solving it generally is anyway better, and hopefully a solution does  
> not need "v=spf1 -all" or null-MX opt-out hacks, opt-in is so much  
> better.
Agreed.  MX should clearly indicate the domain's support of SMTP.   
SMTP receivers are best able to make exceptions in special and perhaps  
critical cases.
> > DKIM provides a means to identify sources
> Simplified DKIM is a "signed timestamp line" indicating some kind of  
> responsibility.  It's not about backscatter and not about delivery  
> reports "to the originator of the undeliverable mail (as indicated  
> by the reverse-path)" -that's what I thought this thread is about.

Actually, DKIM is a bit more robust than some realize.  The body hash  
is included within the signature, which allows signature verification  
in many cases for NDNs as well.  A DKIM NDN rescue strategy when  
dealing with back-scatter.
Placing and checking a simple authentication hash within the Message- 
Id by MUAs would be another method to thwart backscatter techniques.   
Perhaps someone should write a draft similar to the PRVS strategy  
found in BATV for use by MUAs in the message id.  Each user could add  
their own pass-phrase.  With this type of checking, users would never  
be fooled by spoofed NDNs.  Broad deployment and standardization of  
MUA checking by the industry should greatly discourage spoofing of the  
return-path without further burdening SMTP.
-Doug