On Feb 17, 2010, at 8:35 PM, Stephen J. Turnbull wrote: >> SPF and DKIM solve 2 different parts of the problem of forged emails. >> Neither provides complete coverage, together they work well. > > Please explain. AFAICR, neither works very well with mailing lists > because they're both designed on the assumption that the endpoints are > directly connected (in the sense that intermediaries like Mailman must > be pure relays and not add anything to header or payload).
SPF works at the envelope level, but without modification it breaks things like forwarding, is vulnerable to DNS cache pollution/poisoning attacks, etc.... DKIM works at the content level and cryptographically signs the headers, but is vulnerable to MTAs and mail gateways that may transform the content or the representation of the content in ways that would normally appear to be transparent, but in fact wind up breaking the cryptographic signature. Both have their uses, and both have their own set of limitations. There are proposals on the table to try to help fix various known issues with these two tools, as well as to help fill in some of the other gaps. We'll see if these proposals get anywhere. > You can say that Mailman lists with value-added should re-sign, but > that doesn't play very well because mailing lists are somewhat like > common carriers. Making the Mailman list responsible for spam etc > (which is what re-signing does) is going to kill a lot of discussion > lists. IMO, Mailman should not re-sign. If there was anything that would sign the outgoing messages, that would be the MTA and not Mailman. Or, if Mailman is going to re-sign, then it should rename all but the minimum set of headers and then sign only the minimal set, in effect saying "I scanned the message on inbound and it didn't look like spam to me, and the users requested that these messages be sent on to them, so here's the minimal stuff I trust about this message". At that point, if some downstream site marks the message as spam and this hurts the reputation of the site running Mailman, then the site running Mailman should ban the downstream site that inappropriately blamed it for sending the content that their recipient(s) asked to receive. -- Brad Knowles <bradknow...@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu> ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
