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
