On Tue, 2005-07-05 at 13:01 +0200, Frank Ellermann wrote:
Tony Finch wrote:
BATV is just a variant of SRS: it requires MTAs to rewrite
the envelope sender.
No, BATV envelope rewriting occurs at the MSA and nowhere
else.
You could also do it at all mailouts, in Keith's terminology
"somewhere" (once) in the MON (Mail Originating Network).
And of course it only works if you undo it later at the MX,
reject any forged bounces, accept good bounces decodig BATV.
The point is that it only needs to be done within one mail cluster and
the users of that system will benefit from it. It doesn't depend on
flawed assumptions about the way the world operates, and no co-operation
from third parties is required to make its assumptions come true.
Hence the term 'unilateral'.
It is much less problematic than SRS.
That's not at all clear. The "bounces to" fraction can't use
it easily. They want to use "their" MAIL FROM whereever they
submit mail.
That's their choice. They can choose to opt out of the BATV protection
if they so desire, or they can generate BATV addresses for themselves at
submission time.
At least one of my systems does just that -- it's not really part of the
mail cluster, but it generates its own BATV addresses using the same
key.
Then identifying backscatter isn't trivial, empty Return-Path
and Auto-Submitted are clear, what else ? I have a rather
impressive list of rules to catch this crap, because it was
not allowed to report it as spam with SpamCop in 2004.
Mostly it has an empty reverse-path as mandated by RFC2821 and common
sense. Having implemented BATV for about 18 months now, I have a fairly
clear idea of how much of the backscatter had an empty reverse-path (and
now gets blocked), and how much of it does not (and does not). On the
rare occasion that I receive a 'bounce' with non-empty reverse-path, I
report that as serious mail abuse to the upstream network provider.
Last but not least it only protects the forged address at the
MX of this address, it has no effect for receivers accepting
and later maybe bouncing this crap.
With an SPF FAIL the complete "accept and later maybe bounce"
part can be avoided. Dito delivery / forward, an SPF FAIL
blocks the crap a.s.a.p. at the first MX.
BATV can only block (some) bounces hitting the forged sender.
Not correct. Try sending forged MAIL FROM:<dwmw2(_at_)infradead(_dot_)org> to a
sourceforge.net mail host, for example. Note that the admins of
sourceforge.net did nothing in particular to achieve this, and their
system started rejecting that faked mail from the moment I implemented
BATV for myself.
There's plenty of other domains which will be rejecting it, but I use
sf.net as an example because it's a high-profile one and you'll
definitely be able to find an example address at that domain to use in
RCPT.
Nevertheless it's as you said unrelated to SRS. With BATV MXs
+ corresponding mailouts have to change what they do today if
they want to protect their users - minus notorious "bounces to"
fans. The "bounces to" fans are a PITA in any STD 10 scheme.
Right. With BATV they _could_ be accommodated, but certainly it would be
a PITA as you say.
While SRS affects only some "551-alias-forwarders", and only if
they want to stay in business using this particular trick: SRS
is not the only game in town.
SRS only really affects the forwarders _if_ they want to pander to the
bizarre assumptions of SPF users. But SPF isn't the only game in town.
And SRS is still fairly rare, and not even documented in any RFC or even
internet-draft.
--
dwmw2