Douglas Otis wrote:
accept and throw away, that's madness, nobody would do this.
When the forwarded message is refused due to SPF, this message
MUST be bounced.
Yes, MUA to MSA, MSA (or separate box) to MX (forwarder), MX or
separate box to 3rd party, 3rd party rejects, forwarder bounces,
"MON" (= mail originating network of the MSA) puts the bounce
in the mailbox of the user, ready, user can make another plan.
A perfect "551 user not local" emulation. The receiver is free
to pick a better solution, e.g. change MAIL FROM as soon as the
RCPT TO is modified to go to a 3rd party. Or white list the
forwarder. Or collect mails sent to old addresses with POP3
instead of forwarding them. Incomplete list, in practice I'm
still at one perfect 551-emulation in more than 30 months with
a no nonsense PASS / FAIL policy directly enumerating IPs.
Provider could protect themselves by:
1) Not publishing or inspecting SPF records.
I was more worried about the 1,000 misdirected bounces per day
than the one pseudo-551 caused by a FAIL in 30 months. YMMV.
2) Publishing SPF records with neutral or positive defaults.
But then why bother?
An SPF PASS is no waste of time, receivers can couple it with
their white lists or other "reputation" schemes. And they can
delay more expensive checks to a post-SMTP stage, based on an
SPF PASS they're free to accept and bounce messages later.
Without a PASS they MUST get their decision reject vs. accept
right at the border, later is too late: Either they'd "throw
away mails" incl. false positives, or more likely they'd send
spam to forged envelope sender addresses.
Of course I prefer PASS / FAIL over PASS / NEUTRAL, but other
folks have other preferences. Some even promote NEUTRAL over
PASS in certain cases, but I digress.
3) Modify Return-Paths on all messages.
The next problem of modifying Return-Paths might become replay
of messages.
It's no problem of the first S in SSP or SPF or SIDF, receivers
aren't forced to pick that solution. 1123 5.3.6(b) is clearly
better than 5.3.6(a), that doesnt mean that it's perfect. For
some receivers a real or emulated 551 can be better. <shrug />
SPF FAIL and SPF PASS both have a clear meaning wrt SMTP.
^^^^ ^^^^
Not as clear as all would want. A neutral result might lead
^^^^^^^
to message acceptance, but then cause a subsequent bounce to
then be dropped.
NEUTRAL has no effect, same idea as "no signature" in DKIM. The
SSP-discussion is IMO about adding some kind of "FAIL" to DKIM.
Never advocate strict conformance in the case of SPF however,
because the SPF scripts themselves represent a serious threat.
There's no such thing as "SPF scripts". SPF policies are just
enumerations of permitted IPs, as precise as publishers wish.
A policy permitting all minus one failing IP can make sense, e.g.
if there's a problem with this IP sending tons of spam resulting
in tons of misdirected bounces.
Make sense for all parties, alleged sender, receivers checking
SPF, and if the rogue IP has an "admin" (= spammer) it's time
for them to forge another address, or to pick a permitted IP, if
they find one. Probably they're forced to pick a neutral IP.
SMTP is still store-and-forward in many places.
Most mail needs one critical hop, where the "MON" had to look up
the MX of the MRN, and unknown strangers meet. Anything before
that hop is the local business of the sender, anything behind is
the business of the receiver (or list-admin).
Store-an-forward, avian carrier, or floppy by snail mail doesn't
enter the picture. Almost all mail goes through one (virtual)
point, the q=mx singularity. Local mail won't touch that point.
Mailing lists might touch it twice, but with different MAIL FROM,
no problem. Old RFC 821 mail always modified the MAIL FROM for
a proper reverse path. That leaves 1123 5.3.6(a) touching the
q=mx singularity more than once with the same MAIL FROM. This
case is broken by design. You're not forced to believe this, as
sender or receiver. But publishers of SPF FAIL policies and the
MXs rejecting FAIL obviously believe it.
adopt the T10's object (content) addressable storage concept
and combine that with BURL. A double hash of the object and a
time stamp creates a very long token that acts as a type of
password.
[...]
Get an RFC number for something with the same effect as SPF FAIL
and SPF PASS, only better, and I'll try to convince my ISPs that
they add it or switch to it. Until then SPF is the only game in
town roughly doing what RMX promised to do. Skipping some BATV-
considerations, IMO BATV is a kind of standalone hardcore RMX,
but doesn't actually prevent forgeries, it "only" filters most
of the misdirected bounces. Adopt it if you can.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html