On Dec 31, 2005, at 10:31 PM, Frank Ellermann wrote:
Douglas Otis wrote:
The BATV draft seems to be a good start. Perhaps it can be
further simplified. Could this satisfy both camps?
Which both camps, SES vs. BATV, STD 10 + SPF vs. STD 3 + 2821, or
something else ? For the former I'm lost, I read the now expired
BATV draft, and for SES all I know is that they can optionally use
the SPF "exists"-mechanism somehow resulting in 1123 5.3.6(a)
compatibility. I wasn't very interested because IIRC it worked
only for domains with their own name server (?)
With authorization misuse, the desire would be to avoid an
authorization approach. Finding a syntax compatible with the scheme
defined in BATV and that of SES was simply to find consensus for the
syntax to move forward. The "exists" scheme does not seem to make
any sense either, but BATV does.
BATV does not depend upon any third-party adoption.
You can't use "your" Return-Path on any route you like if the
returned messages are rejected by BATV. That's the same issue as
for SPF, only more restrictive: SPF allows to aggregate unrelated
sending routes per domain. BATV works for one and only one MON
(all its MSAs plus the corresponding MRN). And I don't see how a
"bounces-to" fan could accept this.
Just as domains are aggregated in SPF records, BATV signatures (with
mutual arrangements), can be applied to allow a diversity of SMTP
senders. Receiving domains can also make exceptions for individuals
that wish to "opt-out". Coverage does not need to be 100% to be an
effective deterrent for DSN or auto-response exploits.
Alternatively, SPF would need a "per-user" lookup. Yet SPF still
allows any miscreant to exploit open-ended records needed for the
same reasons someone would want to opt-out, in addition to the alias
address issues that will not affect BATV. Depending upon use of call-
back, a message without a valid BATV tag would be more likely
delivered with a comparable loss of DSNs to that of SPF with today's
tactics. BATV allows a per-user opt-out strategy without any "per-
user" lookup at the receiving MTA. The effort is completely
contained within the domain implementing the BATV strategy.
As part of the BATV draft, when the message is delivered, removing
the tag or obfuscating the BATV <glob> section in that is normally
prefixed as "Return-Path:" would also be a helpful practice.
IMHO that would break vacation-like 3834-applications, their auto-
responses would be rejected by the originator's BATV-MRN.
Those applications would need to be ahead of the obfuscation or sent
to the From instead. The message has been delivered, and having a
means to reduce the potential for replay would be helpful.
It's not that I don't like BATV, but it can't substitute SPF FAIL.
For those who can do both they should certainly try it.
For those domains in commerce, BATV does not risk as many delivery
issues, whereas SPF will when delivering to those using their Alma
Mater email address, for example. Nevertheless, BATV can effectively
deter the "side-stepping" exploit which is where spam is really abated.
You're not talking about creating BATV local parts in the MUA, or
are you ? That would be another FUSSP trap. IIRC the BATV idea is
to replace the local-part of the MAIL FROM at the MSAs (or mail-
outs behind an MSA), and undo that modification later for the local
part of the RCPT TO at the MXs (or MDA) in the case of "returned"
mails, invisible from the sending MUA's POV.
Agreed, BATV would not be implemented at the MUA.
On the contrary, BATV eliminates the forged return-path as a
delivery strategy.
Sorry, I fail to see how, not without "call-back-verification" at
the side of the primary spam victims. Or an equivalent pre-abuse-
address-quality-control-test by the spammer. The latter strategy
worked for SPF FAIL because professional spammers use SA for their
QoS-tests (1). Without knowing SA I doubt that it supports "call-
back-verification", that's rather expensive, or isn't it ?
BATV would depend upon a different paradigm. Rather than receivers
checking for closed-ended records that _may_ have been published by
senders to curtail forged return-paths, the forged return-path is
curtailed without such records being exchanged, simply because the
receiver implemented BATV. The overall overhead is less, the effect
more complete, and the impact upon email practices less.
Well, the "SPF-opposition" is apparently determined to let SMTP die
while preserving 1123-5.3.6(a) "251"-forwarding, and a dead SMTP
won't feel the pain.
Most SPF FAIL policies are a "die, spammer, die" voice against 1123
5.3.6(a). Excluding a few who publish -all without RTFM.
Avoiding the DSN and auto-response exploit curtails abuse, so perhaps
better defining the problem would help. SPF records can be published
by anyone, and there remains many records open to exploitation.
Rather than compiling lists of addresses for outbound servers for
a set of domains by issuing dozens of DNS lookups,
NAK, still two lookups in my case before you have either PASS or
FAIL. In theory one query would do, but I won't bother my ISP with
this minor improvement before SPF is at least a PS.
SPF requires as many as 111 DNS lookups. As these are published by
anyone and with broad distribution, the number of records is
unknown. With BATV, the number of DNS lookups is zero.
1123 5.3.6(a) does not work as expected in its own post-821
"bounces-to" world.
This is a problem only when a third-party attempts to verify the
return-path.
What they actually do is use it as specified for their crappy
"accept-then-bounce" setup. That was "state of the art" until 2001
as documented in 2821. Won't make it into any 2821bis.
It would be difficult to imagine a store and forward scheme where an
exploit does not remain possible. This expects the recipient to
fully vet all messages, perhaps even achieving delivery before
accepting the message. There are many cases where better strategies
should be implemented. There is a cost associated with this vetting
however, such as holding sessions open. Being able to ensure forged
return-paths are not effective when returned would better realize the
efficiencies of a store and forward system.
Prevent the bounce delivery strategy from being successful, and
soon it will not be used. BATV prevents this strategy from being
successful without changing email practices.
IMO it's in most cases no "delivery strategy". 2821-DDoS and Joe
Jobs excluded I think the spammers just abuse any address surviving
"call-back-verification". They really try to reach their primary
RCPT TO victims, not the secondary MAIL FROM.
There are those that do better vetting of the remote IP addresses,
where this delivery strategy side-steps this vetting.
And BATV does nothing for the existing primary victims, it only
blocks most "user not found" + "user over quota" bounces at the MX
of the secondary victim.
BATV depends upon the primary vetting of the source identifiers to
abate abuse. As a result, BATV can be more effective at preventing
abuse, but just with a different paradigm. SPF only changes the
tactics without long term benefits. There is also a downside where
SPF records will be used to unfairly accrue reputations. At that
point, email would remain viable for mega-domains or those domains
that run their own servers.
BATV has none of the SPF FAIL advantages for primary victims, it
only blocks some of the backscatter.
SPF can be published by anyone. SPF does not afford any real
protection without the application of reputation. When SPF
authorization is used in conjunction with reputation, disaster.
BATV does nothing wrt obscure C/R systems. Behind an SPF PASS C/R
systems might actually work as expected for the first time. Behind
an SPF PASS the complete SMTP up to 3834 works again.
BATV doesn't have this feature. BATV catches 100% of all bogus
bounces, and that's a feature you won't get with SPF FAIL. For
"all" read "the obvious bounces" as discussed above, not all the
other backscatter (vacation + C/R + AV-"feedback" + ...)
The list of where BATV is expected can be modified as needed, when a
legitimate domain has been exploited. Those of individuals on
vacation bouncing with the initial RCPT TO address, then any problem
will be evident immediately when the auto-responses are refused.
This would be an indication that this "feature" is being exploited.
With BATV, this blunder is self healing.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf