In the security considerations section, there were two paragraphs
below DNS Attack added. This was intended to be within a section
called Bot-net Attack.
Why this section is important might be illustrated by with the
following data.
A well respected email provider has a slight problem. They send
approximately ten billion emails a day, or about one hundred thousand
each second from 2 million cached daily inquires from customers
assumed to represent about 1/5000th of overall traffic. It is clear
that they understand there is a problem from their arrangement of
outbound servers. They have three tiers earning significantly
different, but uniform ratings. The first class tier sends little if
any spam, the second class sends a small percentage of spam mixed
together with about 2 billion messages, and the third class sends
about 350 million a day with a high percentage being spam. This
provider publishes SPF records, and, in the past, asked why this space
had not been white-listed.
It should not be difficult to understand the danger this provider's
behaviour might represent. As it would be for DKIM signatures and
From headers, the PRA is not restricted. In the case of Sender-ID, a
recipient of their message might be convinced to process perhaps nine
macro expanded SPF records evaluating a PRA targeting some victim, and
yet the message could still be authorized when the bad-actor finally
includes the provider's highly respected SPF record. What a concept!
I was prevented by several MAAWG members from making a presentation
pointing out the dangers associated with Sender-ID then being touted
by a new board member and soon highly promoted as an industry
solution. After all, this was a feature promised to enrich those
supporting it. There were even direct payments made to implementers.
(The problem that SPF sans Sender-ID hoped to solve is more safely
handled by adoption of RFC3834. A reputation service could help make
that happen.)
DKIM is intended to help solve the phishing problem. IMHO, it can.
However, the DKIM WG must not ignore DDoS issues. It does not matter
how many major email providers insist their mail does not represent a
concern. If ADSP were to limit how the i= parameter within the DKIM
signature can be used, or insist that the "on-behalf-of" feature can
be obtained by using multiple signatures, or by having the identity
introduced through some undefined method, then clearly this WG has
failed to appreciate the the danger as well. Although admitting there
is a problem may draw the interest regulators, where little good ever
comes, by ensuring DKIM is able to help mitigate the bot-net issue, it
can better head off the dangers associated with any eventual regulation.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html