[Top] [All Lists]

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

2008-05-06 11:02:14

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.


<Prev in Thread] Current Thread [Next in Thread>