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 (?) > 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. In 2004 SC still did not allow to report backscatter as abuse, my "rule collection" to extract this crap from all other spam was constantly growing until "my" spammer figured out SPF FAIL. One of these rules was MAILER-DAIMON@ (sic ;-) Yes, it could be helpful for applications behind a smart host or non-2476bis-MSA not supporting MAIL FROM:<> But that's a potential FUSSP-trap. Additionally you'd have to s/MAY/SHOULD/ in 3834 section 3.3. The latter might be possible without much ado, and I'd like a 3834bis as DS. Two implementation reports, anybody ? > could be introduced into a BATV expectation list, when needed 3834 lists owner-* and *-request in addition to MAILER-DAEMON. >> 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. 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. > 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. IMHO that would break vacation-like 3834-applications, their auto-responses would be rejected by the originator's BATV-MRN. 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. 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. While the MXs reject all other identified bounces, that's the purpose of this coordinated MON + MRN effort known as BATV. >> doesn't address the real problem, the forged Return-Paths. > 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 ? [1: source = my crystal ball when "my" spammer stopped to abuse "my" addresses soon after SA 3.0 supported SPF, 2004-09-01] >> With SPF FAIL this crap can be rejected a.s.a.p. [...] > "As Soon As Possible" is not better than "As Painless As > Possible." : ) 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. > 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. For an SES-exists variant it might be also two DNS queries (?) No idea what the average is, but it would surprise me if it's more than six, let alone one dozen, or your "dozens". Some of the most complex sender policies are huge ISPs sending lots of mail, and then you'd get many answers from your cache. >> 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. Verification with SPF started 2004, only a minority does this. Fortunately the spammers can't determine who checks SPF without rejecting FAIL, and therefore they're forced to avoid SPF FAIL protected addresses. Besides we're not yet in the phase where spammers are forced to pick their Return-Path depending on the target. Except from the obvious idea to use a plausible ccTLD matching that of the recipient in localized spam. Or the stoneage From = To tricks, I consider that as incentive for SPF FAIL publishers to join the "SPF checking elite" (that doesn't include my ISP, maybe they'll see the light in 2006 ;-) > 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. 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. At this time the spam was already accepted by an MX of the primary victim, rejected by the MDA, and queued for a bounce message in a "mail out" of this primary victim. At this time all other spams abusing the same MAIL FROM domain of the secondary victim are _delivered_ to all existing primary victims (minus "over quota" cases). BATV has none of the SPF FAIL advantages for primary victims, it only blocks some of the backscatter. 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" + ...) > SPF adds overhead and expects changes to email practices > before being fully effective. No, SPF FAIL works already for those who want it. It's a pure voluntary system, nobody is forced to participate. As far as changing 1123 5.3.6(a) forwarding is concerned, that's the job of the receivers: Check SPF at the first border MTA, and white list all forwarding MTAs on the receiving side if you check it "again" later. How they arrange this isn't the business of the sender, there are many ways to get it right. Not limited to ignoring the issue, if a "251" results in a "pseudo-551" it is in the spirit of STD 10 and SPF's "back to the routes". In that case let the sender figure it out, "551" is no new idea. > Those who publish SPF records are at risk of being block- > listed when these records have been exploited. : ( Yes. If you can't risk PASS don't, use NEUTRAL. But before a decent 2476bis 6.1 MSA you can always use PASS. So far only two users were seriously interested in some kind of "HARDPASS", I've noted that as op=auth. Pointless at the moment, because it's irrelevant for receivers, it's only relevant in conjuction with future "reputation systems". Enjoying the IETF tools see: http://tools.ietf.org/html?url=http://purl.net/xyzzy/home/test/draft-spf-6-3-options-09.txt#section-3.4 > 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. Those unethical activities (we can rule out the mere "error" as proposed by Keith some months ago at this time) are no flaw in the SPF design. I've formally asked the SPF Council to support an appeal to the IAB: <http://article.gmane.org/gmane.mail.spam.spf.discuss/19909> IIRC you also reported your concerns to iesg@ietf. It's all on public record, everybody can draw his conclusions, and I won't participate in any IESG-sponsored opt-out schemes. A happy new year to all spam fighters _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf