On Apr 29, 2010, at 9:06 PM, John Levine wrote: > I just don't see how you can simultaneously say "throw away unsigned > mail" and "don't throw away unsigned mail if a list says it used to be > signed" unless you have some way to identify trustworthy lists.
Precisely! The key phrase being "unless you have some way to identity trustworthy lists" > But > once you know that a list is trustworthy, why wouldn't you just accept > all its mail? We need to be precise about what we mean by "trustworthy". Even if I have "some way to identify trustworthy lists" as you put it above, I have to be very clear about what I'm actually trusting that list to do. Let's go back to the use case I drafted in response to Murray's report that introduced the MLM re-signing option. >> That's interesting. Let's make this concrete... I'll use myself as an >> example. >> >> X = me/PayPal.com >> Y = this list/ietf-dkim@mipassoc.org >> Z = Google's Gmail service [1] >> >> It is my assumption that someone subscribed to this list has a gmail.com >> account (or a Yahoo.com account [2]). Therefore, my use case is simple. I >> would hope that those of you reading this from your Gmail or Yahoo! accounts >> actually receive this message. If Z breaks the signature, you won't see >> this. >> >> So if it simply isn't practical to expect lists to maintain the signature, >> then offering the option for the list to validate the signature coming from >> X and send a new signature to Z that Z *can* (but doesn't have to) "trust", >> is something immediately useful. In that scenario, if the MLM re-signing solution has been deployed by Y, and DKIM+ADSP has been deployed by X & Z, and Z has chosen to take action on X's ADSP policies... the only thing Z is trusting Y to do is validate incoming DKIM signatures, re-sign the messages with its own DKIM signature, and pass it along with the A-R results that convey what was done. Z is not trusting everything and anything that might ever come through Y. I think that's a reasonable level of trust to expect mailbox providers to have in mail lists who assert that they do this. Rogue mail lists will stop being trusted but only after they have "lost" the trust that was granted to them via their standards-based assertion (we would probably need to spec out how a MLM advertises that they indeed conduct flows in this manner) that they perform these functions on incoming mail. Again, I'm not saying this is the best or most elegant way of handling the problem of properly authenticated mail not being able to traverse mail lists, but it seems worthy of further discussion as an option. > I just don't see a plausible scenario where you you > know you trust the list but still want to accept or reject mail based > on assertions the list itself makes. Does the use case I've articulated above make sense? -- Brett _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html