ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-03 Issue 25: Re: Recap Issues 0b/21/25

2007-04-30 17:01:27

John Leslie wrote:

There's actually some rather good work towards that, called BATV:
http://www.mipassoc.org/batv/

which enables the use of a MailFrom which cannot be delivered to
the "sender" unless it passes some checks by the "originating"
mailserver.

BATV is rather tricky if you intend to send via unrelated routes
(different MONs in Keith's terminology) directing error reports
to one "originating" MRN.  If that's no issue BATV should reject
most unsolicited auto-responses (anything mentioned in RFC 3834 +
DSNs + MDNs) at the alleged originator.

For that point I'd say SPF can aggregate unrelated MONs on demand,
but it's difficult with BATV.  On the other hand BATV works for
almost all unsolicited auto-responses no matter what the bad guys
or the receivers do, while SPF depends on at least some receivers
supporting it, and that the bad guys not being sure who checks SPF
stay away from FAIL-protected addresses.

Both techniques can be combined as desired.  One disadvantage of
BATV is that it doesn't catch all forged Return-Paths (as SPF
FAIL does it when used), it only eliminates backscatter arriving
at the alleged sender in the form of bounces and auto-responses.

Before the spammers decided to stay away from my FAIL-protected
addresses (that took them some months in 2004, maybe the release
of SA 3 convinced them) most bounces I got where "user unknown"
and similar crap, rarely "over quota", a few hundreds of those
"spamarrest challenges", a wannabe-antispam pyramid scheme, and
a few hundreds other C/R-systems (earthlink etc.)

These "user unknown" bounces tell me that many spams forging my
address did make it to mailboxes of "known" primary victims.  The
backscatter is only a part of what really happened, in several
cases I could reconstruct the patterns of dictionary attacks.

BATV doesn't help with this aspect of the problem, forged mails
to existing users will end up in their mailbox (or spamfilter).
BATV also doesn't identify "good bounces welcome" like SPF PASS.

Its biggest advantage, complete independence of the good will of
receivers, let alone spammers, is also its biggest disadvantage.

Apart from that I recommend to combine BATV with SPF for users
who can limit their outbound routes (per domain) to one MON/MRN.

In a certain sense BATV is a hardcore version of SPF, it's more
restrictive wrt "where can I use which Return-Path".  OTOH it
has obviously no problem with alias-forwarding to third parties,
SPF insists on "check mails at your border or better forget it".

we can set the stage for solutions of that ilk -- by allowing
delivery servers to refuse to send NDNs without "satisfactory"
assurance that the MailFrom address is useful to reach the
sender.

+1

That would _not_ be a fundamental change from RFC821 -- the
"satisfactory" assurance was a given when 821 was written.

And implied by RFC 2821 if you care to read it until "originator
as indicated by the reverse path" finally reveals its secret
"if this indication is wrong you already did screw up" nature.

And we're only fooling ourselves if we pretend that MUSTard in
2821bis will keep NDNs from being dropped in practice.

+1  Both alleged senders and receivers have to contribute to the
solution(s), and of course all affected parties try to say "it's
not our problem" following the 2821 lead.

Frank
-- 
Compare <http://www.openspf.org/Frank_Ellermann/Auto-responders>