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
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
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
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
Agreed. MX should clearly indicate the domain's support of SMTP.
SMTP receivers are best able to make exceptions in special and perhaps
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]
||[Next in Thread>|
- Re: Queued Mail or Unreturnable Mail?, (continued)