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(_at_)ietf(_dot_) 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf