On Fri, 24 Jun 2011, Dave Crocker wrote:
Let's simplify this discussion:
Spammers do a variety of techniques to trick filters and users.
We should have the DKIM signing specification normatively require
checking for every known technique, since we cannot be sure that any other
part of the system will perform the necessary checks.
Leaving aside the fact that Dave is kidding above, for those who think
that is a good idea on it's face, I'd like to reiterate my suggestion for
this problem:
* Put it in its own RFC *
I think there's room for a "Minimum Quality of Forgery Supression" BCP.
Such an RFC would outline a number of faults a message can have, and
declare that any of those faults mean the message MUST NOT be delivered
to the nominal recipient.
ISPs would then promise to follow this RFC, and in return
phishing-sensitive institutions may reward users who give contact
addresses at a compliant ISP, such as an exemption from a "phishing
insurance" fee.
To be actually useful, such a standard would need to reach beyond DKIM
and ADSP. For example, some sort of means to prevent full-name abuse
(Paypal <badguy(_at_)example(_dot_)net>) or mispellings
(<paypal(_at_)info(_dot_)paypa1(_dot_)ca>)
would be vital. Those are hard problems, the DKIM people should not have
to be weighed down working on them.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html