Douglas Otis wrote:
The DKIM/ADSP DDoS concern is analogous to that of Sender-ID.
ADSP needs at most one DNS query for an existing domain, there
is no "analogy" to spf2.0/pra. If you are worried about a From
header field with hundreds of addresses below a victim domain
we write "don't do this" in the ADSP security considerations.
Sender-ID allows an override by version 2
As always your hermetic terminology beats me. spf2.0/pra is
one of five existing tags (or subtypes) for SPF records, and
three of them are in practice pointless:
v=spf1 RFC 4408, about SMTP HELO + MAIL FROM
spf2.0/mfrom RFC 4406, theoretical construct, normative
reference to 4408, i.e. the classic v=spf1
spf2.0/mfrom,pra RFC 4406, same as spf2.0/pra,mfrom
spf2.0/pra,mfrom RFC 4406, same as spf2.0/pra + v=spf1
spf2.0/pra RFC 4406, about RFC 4407 PRA
Together with the stillborn v=spf1 op=pra in an expired I-D
that's in practice two relevant subtypes, PRA or classic SPF.
There is no such thing as an "override by version 2" for PRA,
and the four subtypes in Sender-ID all start with "spf2.0",
if you consider that as "version 2".
The relevant concern is whether a bad actor can influence
the PRA
Bad actors pick whatever PRA, 2822-From, HELO, or MAIL FROM
suits them. It's the job of v=spf1, spf2.0/pra, or ADSP to
defeat that.
And because spf2.0/pra works only at border MTAs, with the
known limitation of v=spf1 for SMTP forwarding, *plus* new
requirements for any forwarder and mailing list to update
the PRA (i.e. manipulate the message proper, not only the
envelope), *minus* the advantages of v=spf1 for a PASS, it
might turn out that sp2.0/pra is "less sexy" than ADSP for
receivers. Or maybe not, we'll know that in some years...
Of course, bad actors would also have their messages
receive a Sender-ID and/or MAILFROM PASS authorization.
Or an ADSP signature. Bad actors do with their addresses
what they like, the idea of v=spf1, spf2.0/pra, or ADSP is
that they can't do this with FAIL-protected addresses (for
FAIL read "suspicious", "locked", "discardable", or the
term du jour used in ADSP).
BTW, a MAIL FROM PASS is no "authorization", it only means
that a bounce will hit a party responsible for publishing
a PASS-policy for the relevant domain.
Receivers can use a PASS or "good signature" to mean more
in conjunction with a white list or reputation system, but
that is entirely under their control. A PRA PASS from an
unknown stranger means nothing, let alone "authorization".
Ditto "good signature" from unknown stranger.
A customer's message determines the PRA in various ways
where macros, rather than DNS records directly, might do
the bulk of the damage.
There is exactly one way to determine the PRA, and it is
specified in RFC 4407, for folks who don't find the very
simple idea in 2822upd. The evaluation of spf2.0/pra has
exactly the same processing limits as v=spf1 in RFC 4408,
by a normative reference in RFC 4406.
RFC 4406 boils down to "maybe using the RFC 4407 PRA would
be cute, instead of a 2821bis MAIL FROM". This "hack" is
so lousy that it does not even bother to specify what to
do with a 2821bis HELO and %{h} macros - an integral part
of RFC 4408, but an oddity in the context of PRA. Ignore
spf2.0/pra, like most folks not forced to care about it.
That ADSP fails miserably for Resent-From scenarios, and
arguably in violation of the 2822upd e-mail architecture,
that is interesting for this WG. IMHO anybody trying to
outsmart RFC 4407 so far dropped the ball, including ADSP,
but "you" want to try it anyway, let's see what happens...
Freedoms are lost due to Sender-ID exploits.
...even if that would be the case, what has it to do with
ADSP or DKIM ? ADSP "eliminates the Resent-From freedom"
and violates 282upd. So what, there is already an appeal
against a similar issue in PRA on public record. And in
comparison PRA was harmless, ADSP is a frontal assault on
2822upd Resent-*.
We know this. Repeating it for the 1001st time is boring,
let's keep our ammo for the IETF Last Call + appeal(s).
Some people in the WG seem to have difficulty accepting
that DKIM/ADSP is not about making strong assertions of
the author identities.
IMO it's more like "some people consider DKIM as pointless
without strong assertions", because they don't send the
volume of mails to make their DKIM signatures interesting
for white listing by important receivers (including cases
such as ironport).
Without the chance to reject mails checking signatures of
unknown strangers is not very interesting for receivers.
RFC3834 allows content of the message to be eliminated
in most cases.
That's not the case. If some POP3 users dig through the
backscatter with TOP they'd still have to deal with the
header. Let's say that worldwide adoption of RFC 3834
Auto-Submit is "not yet ready", and besides folks want
also the body of good (= no backscatter) auto replies.
Had this problem been dealt with by the IETF instead
of closing the WG, what remained would likely have
meet most of your expectations safely.
Maybe, or as Wayne said, a huge mistake. I let the AD
talk me out of an appeal, because I had no idea for a
"remedy" (hours after I figured out that there is an
appeal procedure, as expected, and an RFC specifying
the proper procedure to terminate an IETF WG). That's
now ancient history, R.I.P.
of course this might not be the same for someone who
expected forwarding to still function as it had. : )
For values of "had" between 1123 and 440x, not older.
Some may consider a DSN that does not adhere to
RFC3834 and that includes the original spam to be
treated as if the client originated the message
Just in case: RFC 3834 is a PS about auto-replies,
not about DSNs (3461..3464, DS), and not about MDNs.
All use the envelope sender address of the alleged
sender, typically with an empty return address in
their various "auto" activities. For DSNs replace
typically by MUST, loops are bad.
There are several schools and large organizations
that have had their valid recipients lists
discovered and heavily exploited, where even SPF
and filtering fails to offer a level of relief
they had hope to obtain with respect to DSNs.
Spammers are lazy like everybody else, they don't
remove SPF FAIL protected addresses from their list
of "plausible + unprotected" addresses daily. "My"
spammer (back in 2004) needed four months to get
the idea (assuming that is what happened) of FAIL.
In 2005 "he" (or somebody else) tested again for a
week to abuse @xyzzy addresses, after that I had no
backscatter issues. Since November 2007 the @xyzzy
catch-all is closed (due to spam masses, not due to
backscatter), and on my other addresses I have no
backscatter issues (one is FAIL-protected, Gmail has
only PASS, a third has nothing - that's the somewhat
clueless provider I talked about, who accepts fake
bounces. Nobody needs SPF FAIL to avoid this, but
it would work - HELO freenet, fix this).
Sure, if backscatter victims want immediate effects
(on their side) and have all outgoing routes under
their control, they can combine FAIL with BATV, or
try pure BATV without FAIL (bad for primary victims,
good for forwarding obstacles).
But without FAIL the spammers have no incentive to
remove the unprotected address from their list, so
I wouldn't recommend pure BATV for these reasons.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html