ietf-smtp
[Top] [All Lists]

Re: Queued Mail or Unreturnable Mail?

2008-05-05 13:33:52

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.

I'm still curious how minimal such uses are, and if they
could be simply deprecated as nice try.  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.

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.

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.

NEUTRAL represents the same status "as if" no SPF 
records exist.

RFC 4408 says, yes.  And receivers do what they like with
it, as they could accept a FAIL instead of rejecting it,
no matter how bad that can be, or discard SOFTFAIL, or
treat a PASS from unknown strangers as spam on Tuesdays.

They have some additional info to "get it right" in some
cases like PASS or FAIL, but they are free to use this
info or its NEUTRAL absence in other ways.  If they are
confused they could evaluate v=spf1 against Message-IDs
or a PRA, and claim that the spam recognition rate is
better than a random generator.

They can't claim that they found this recipe in RFC 4408,
like folks adopting a "discard them all" strategy cannot
say that this is what 2821bis wants them to do.

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.

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.

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.

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.

 Frank

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