ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

2010-04-30 09:07:58
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(_at_)mipassoc(_dot_)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

<Prev in Thread] Current Thread [Next in Thread>