--On 12 October 2009 10:04:17 -0400 Wietse Venema
<wietse(_at_)porcupine(_dot_)org>
wrote:
Michael Deutschmann:
If this is indeed the official semantics of the protocol, then I would
petition to add a "dkim=except-mlist" policy. Which means "I sign
everything that leaves my bailiwick, but may post to signature-breaking
MLs."
Are you going to announce all your users mailing list subscriptions
in the policy record? If you do, that could be a privacy problem.
If you don't, then the spammer can add any mailing list header to
the message, and they can drive their truck through this hole.
Wietse
Surely that's OK, if that's the policy. The point is that the recipient
must assign reputation to the list, not the original sender. If the list
proves trustworthy (presumably it applies its own DKIM sig, or has an SPF
pass, and also has a good reputation with the recipient), then the
recipient might go on to assess the reputation of the author - on the basis
that a trusted list is likely to be making a DKIM assessment of inbound
mail.
I've come a bit late to this conversation, but it seems to me that the
problems under discussion are really all about how a recipient should treat
inbound messages. If list managers were routinely testing inbound DKIM
and/or SPF, then a list with a good reputation should be able to deliver
mail by re-signing and applying SPF.
It also seems to me that there must be a difference between "dkim=all" and
"dkim=discard". Publishing "discard" should mean that there's no
expectation that the sending domain will be sending mail to discussion
lists. These domains ought to be reserved for purposes like sending
personal banking notifications. I don't think I have any such domains, but
I guess I could think of some use cases for a University.
Domains publishing "all" ought to be able to get mail through a mailing
list. Recipients of such mail that has been corrupted by a list should
accept it only on the basis that the list itself has a good reputation,
combined with a verifiable DKIM signature, or SPF pass. Simply inserting
list-id headers shouldn't be enough.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html