Michael Kaplan wrote:
[bounced back to the sender == technically impossible]
Your argument is not unique to my proposal but it is directed
against all bounces, vacation messages,
Yes, almost all auto-replies covered by RFC 3864, unsolicited
DSNs, the works.
It is certainly not technically impossible, but I assume you
mean undesirable.
No, I meant "impossible", because you don't know who the sender
is. If you got an SPF PASS (or any equivalent indication that
the Return-Path is no nonsense) that person might consider your
procedure as "undesirable", but that's nobody else's business.
For your case "unknown stranger" the default is that you just
have no clue who the sender is. At that point you've already
filtered your inbox, all "known good guys" either made it, or
you reject it as trivial forgery. Let's say 80% of your ham.
All "more than intermediate spam likelihood" is also out, that
is 50% of your spam. So if your inbound is 5% ham, 84% spam,
and 11% misdirected bounces, then your filtered inbound is:
1) 4% "identified ham" (80% of "5"), already in your inbox
2) 42% "identified spam" (50% of "84"), dropped or rejected
3) 11% "misdirected bounces", let's say you drop this unread
4) 42% "unidentified spam" (rest of 84) gets a challenge
5) 1% "unidentified ham" (rest of 5) also gets a challenge
Therefore about 42 of 43 challenges hit innocent bystanders.
Smart spammers probably abuse "plausible" Return-Paths, with
"plausible" = survives call-back-verification (tests arriving
as apparently empty spam), and they might also avoid SPF FAIL
paths.
If they're not so smart they probably ended up in your first
42% of "identified spam", because you could as well test this.
If the ratio is 42 of 43, or only 40 of 43, whatever, you end
up with huge amounts of spam (unsolicited challenges are spam)
sent by you.
The typical plan B for those who think that SPF is not really
necessary would be a separate IP used to send your backscatter.
If that IP is blocked your challenges will be rejected on their
way (maybe including the one you're really interested in), and
the problem is solved.
I don't see a working system here, same problem as in RFC 2821.
Existing methods such as BATV can easily protect mail systems
from this problem.
BATV works if a Return-Path is bound to mailouts and MXs in the
same mail originating / receiving network. The relevant MXs
have to know which Return-Paths were created by corresponding
mailouts. BATV is a kind of hardcore SPF, the senders enforce
their own policy wrt bounces. Or rather the MDA has to know
which Return-Paths were actually sent, anything else can be
dropped. Reject at the MX might be better, but not required.
If your system is "BATV-ready" it MUST use an empty Return-Path
in its challenges, the other methods mentioned by RFC 3864 work
only after DATA in SMTP (or after HEAD if that draft makes it).
A system only working if the whole world deploys BATV or SPF
(if you take the latter into account in your filtering) is IMHO
premature. You'd have to wait until you get a ratio "1 of 43"
instead of "42 of 43", and then the "1" is still an unsolicited
challenge.
It is highly unlikely that email with an SPF PASS would get
bounced.
That's no real problem, after all an SPF PASS is a guarantee
that bounces won't hit innocent bystanders. If the sender does
not like your challenge (s)he can "just hit del" and be done
with it.
The receipt of erroneous bounces would annoy some (mostly
victims of Joe jobs)
Let's reserve the term "Joe Job" for something more serious
than "84% of mail are spam with plausible forged Return-Paths",
that's the reason for "11% of mails are misdirected bounces".
I'd wish I could remember where I read this 84+11+5 = 100, it
was this year, and not a too obscure source (e.g. not nanae).
but, ironically, it would accelerate the adoption of BATV
I doubt it. Folks thinking that SPF is too restrictive won't
like the more restrictive BATV. If you can identify BATV or
SPF PASS, and limit your bounces to these cases, you won't run
into trouble.
Maybe SPF should offer a BATV flag: "All Return-Paths with
this domain are BATV-protected (and anything else is forged)".
But actually the BATV-sender knows which local parts are okay,
a sender policy "v=spf1 exists:%l.%d -all" or similar allows
receivers to get a clear PASS or FAIL (without any forwarding
issues). Anybody supporting BATV could also support this kind
of sender policy (IIRC that was the or a part of the SES idea).
But that's not yet the case, and it could take a decade until
deployment allows you to ignore "the rest of the world". With
a good chance that it will never happen.
1st - If implemented will it actually stop spam?
"Works after worldwide deployment" - one of the FUSSP points.
2nd - Is it practical to implement?
If that boils down to "can receivers identify BATV local parts
with sufficient certainity" I can't tell. Identifying an SPF
PASS is a solved problem.
3rd - Is it unacceptably burdensome to the sender/recipient?
Some don't like BATV and/or SPF. In your original article you
mentioned other schemes (SenderID PASS + DKIM PASS) where you
never send a bounce (?). Maybe it's acceptable that senders
pick one or more of these schemes as it pleases them.
4th - Is it unacceptably burdensome to third parties?
"42 of 43 challenges are unsolicited" wouldn't be good enough.
Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg