I see no benefit whatsoever in using DKIM for blacklists. But we need
to be careful to avoid automatically carrying the habits of blacklist
filtering into whitelist filtering.
This on its face seems like a very fair statement, and I agree with you that
we clearly have been living in a blacklist world. But I am not convinced
that there is a white list world out there at this time. There are too many
virii and too many vulnerabilities to flip a good guy to a bad guy extremely
quickly.
You're quite right that we're unlikely to have static whitelists any time
soon. But I was thinking more of simple questions like "is this message
whitelisted" versus "is this message blacklisted?"
Since bad guys are trying to disguise their identities to dodge
blacklists, blacklisting is necessarily fuzzy and heuristic, along the
lines of Spamassassin, and even yes/no blacklists like DNSBLs have
heuristics about how big an IP range to list if you see a cluster of
reports from a group of IPs.
But good guys want you to recognize them, so if we offer clear
instructions to make a message meet whitelisting rules, senders will
follow them. The more options they have, the less clear it is what to do,
and the more work everyone's going to have to do to sort out the results.
The reason that l= was a bad idea is that it changes the answer to the
question of whether a message is signed from "yes" to "sort of". The less
sort-of, the better.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html