Douglas Otis wrote:
This back-scatter problem can be resolved by implementing
BATV at the cost of two additional wafer-thin packets.
Sorry, we just discussed "reputation", and that's completely
unrelated to SPF FAIL. You can publish SPF policies without
any FAIL-qualifier at all, for white listing up to reputation
only SPF PASS is relevant.
"Simplified SES" (or whatever BATV is) is _more_ restrictive
than SPF: In Keith's terminology it's a coordinated effort of
one MON (all MSAs) with its corresponding MRN (all MXs). With
SPF you can aggregate several unrelated MONs (all "mail-outs").
Further BATV works only for "obvious" backscatter, as you said
in another article here it's essentially only for MAIL FROM:<>
IIRC 3834 offers only a MAY for a MAIL FROM:<> in auto-replies.
Besides we're still far away from universal 3834 deployment.
BATV is a solution for a small part of the symptom of the real
problem, the fatal 1123 5.3.6(a) flaw. Hardcore "bounces-to"
fans won't use BATV, they already hate the more flexible SPF.
BATV doesn't address the real problem, the forged Return-Paths.
Blocking 100% of all identified bogus bounces is nice, if you
can arrange things this way go for it, use BATV. But it won't
help to block forged Return-Paths at the primary victim. Some
of those spams reach existing users, they are not all bounced
to their forged Return-Path.
With SPF FAIL this crap can be rejected a.s.a.p. and not later,
SPF _fixes_ the design flaw in 1123 5.3.6(a) for those who want
it. SPF is "back to the routes" (pun intended) as in the last
working SMTP model (STD 10).
Many RFCs, not only SMTP itself, also the DSN stuff and 3834,
depend on reliable Return-Paths. You'd be forced to forget all
these features if you don't fix the cause: 1123 5.3.6(a) does
not work as expected in its own post-821 "bounces-to" world.
There are only two choices, SMTP without bounces etc., or SPF:
Absolutely nothing I've heard about offers to save the "good
bounces" from any MTA at or behind the first MX, only SPF FAIL
does this (originally Hadmuth's RMX idea).
Unlike the (defunct) SPF scheme aimed at qualifying the
return-path, BATV does not wait for wide adoption before
benefits can be derived.
If you think that SPF is "defunct" you'll get SMTP without any
kind of auto-replies (not limited to bounces from MTAs outside
of your MON). The SpamCop FAQ and AUP are more relevant than
say 2821 for this issue.
Besides SPF does not wait for wide adoption, it's good enough
if the professional spammers figure it out and avoid to abuse
SPF FAIL protected addresses. That worked from my POV in 2004.
With BATV they might also get the idea, IFF their tests cover
a MAIL FROM:<> RCPT
TO:<address(_dot_)under(_dot_)test(_at_)BATV(_dot_)user(_dot_)example>,
and IFF that's the way how "call-back-verification" is supposed
to catch forged "BATV-protected" Return-Paths (?)
Compared with SPF "call-back verification" isn't cheap, and for
BATV the local parts of the Return-Paths would be different for
each mail (?). You can't cache results, you can't integrate it
behind a simple SIQ interface. Please correct me if that's
wrong, but MTAMARK + BLs + CSV + SPF should all work with SIQ.
Bye, Frank
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf