On Fri, 2005-12-30 at 09:35 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > > > This back-scatter problem can be resolved by implementing > > BATV at the cost of two additional wafer-thin packets. > "Simplified SES" (or whatever BATV is) is _more_ restrictive > than SPF: With effort, a compatible syntax could be defined that would satisfy everyone, hopefully with a draft that only includes essential syntax and nothing more. The BATV draft seems to be a good start. Perhaps it can be further simplified. Could this satisfy both camps? <mode>=<glob>=<local-part>@<domain> I am not an author for either of these drafts, but this technique should be formalized, with the use of the syntax promoted. > 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. There is no question that better conventions are needed when dealing with auto-responses. Conventions that limit the alternative to MAILER- DAEMON@, instead of a null address could be helpful. However, in dealing with a legitimate provider where an auto-response is being exploited, per RFC3834 3.3, these auto-response local-parts should be specific to this purpose. These addresses will also be evident by the inclusion of the BATV tag in the RCPT TO, and could be introduced into a BATV expectation list, when needed. Anyone auto-responding with an address used for other purposes would be taking risks in other ways. > 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. This is not an issue for BATV. BATV does not depend upon any third- party adoption. The domain implementing BATV benefits. As part of the BATV draft, when the message is delivered, removing the tag or obfuscating the BATV <glob> section in what is normally prefixed as "Return-Path:" would also be a helpful practice. > BATV doesn't address the real problem, the forged Return-Paths. On the contrary, BATV eliminates the forged return-path as a delivery strategy. Preventing this ploy is key, as the return-path should serve no other purpose. > 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. Source identifiers should be used to exclude spam, rather than attempts to verify the return-path, as this represents far less overhead and does not alter existing practices. Forged return-paths are often attempts to side-step source filtering. When either a DSN or auto-response is expected, then BATV would be effective at eliminating illegitimate messages and the "side-step" strategy. > 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). "As Soon As Possible" is not better than "As Painless As Possible." : ) Rather than compiling lists of addresses for outbound servers for a set of domains by issuing dozens of DNS lookups, BATV can thwart this strategy with 2 extra TCP packets within a 6 packet exchange. Just one DNS lookup on average will exceed this overhead. Being able to rely upon source identifiers and BATV represents better protection with much less overhead. BATV, the painless "zero-lookup" protective strategy. : ) > 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. This is a problem only when a third-party attempts to verify the return- path. BATV changes this paradigm. BATV allows the third-party to concentrate on source identifier filtering rather than issuing call- backs or other expensive techniques. > 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). 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. SPF adds overhead and expects changes to email practices before being fully effective. What is worse, when SPF is seen as "weak" authentication as with Sender-ID, then a new problem arises. Those who publish SPF records are at risk of being block-listed when these records have been exploited. : ( > > 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. When AV filtering produces a fair amount of bounce traffic, advocating deletion of DSNs for domains without either an SPF record or a DomainKey signature is an unfortunate reaction. Even assuming this were good advice, SPF records are open-ended and Domain-Key signatures are not required to be within the same domain as the return-path. These are holes waiting to exploited when this stop-gap approach becomes more predominate. BATV can be a long term solution that better insures the integrity of email delivery. SPF qualifying the return-path is defunct as there are no records defined for this purpose, with this record usurped by Sender-ID. The opt-out strategy still risks wholly unfair treatment. > 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. This explains the hostility to RFC1123 5.3.6(a). > With BATV they might also get the idea, IFF their tests cover > a MAIL FROM:<> RCPT TO:<address.under.test@xxxxxxxxxxxxxxxxx>, > 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 (?). With an adopted convention for BATV, the consistent local-part can still be determined. Call-back is not a good practice, but BATV can even improve upon the security obtained by that use as well. -Doug _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf