ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Repeating the SPF/SRS mistakes (was Straw poll results

2010-08-11 13:20:01
Steve Atkins wrote:
On Aug 9, 2010, at 4:31 PM, Scott Kitterman wrote:
On Monday, August 09, 2010 06:52:04 pm Steve Atkins wrote:
One implication of that is that if you're planning to do something with
email that will break if there's a MLM involved, it's broken[1].

[1] We could call this "The SRS lemma".
Yes.  It's very similar.

However, it's wrong.  As a counterexample, S/MIME or PGP encryption will 
break if there's a MLM involved, but they're not broken.

One needs to decide what factors one cares about the most.  I said a few 
threads ago that I don't think there is a completely satisfactory solution.  
I 
think the possibilities are roughly:

1.  Fix lists so that signatures survive.

This has to be plan A.

2.  Have MLMs change the domain of the message.

3.  Have mail get rejected/discarded/etc.

4. Write off ADSP as broken, do something useful instead.

Agreed.  As a fact, I've had to disable ADSP in my DKIM-filter, because I'm 
unable to whitelist every MLM.

There are variants of all three possibilities, but none that will satisfy 
everyone. 

Yup.

Since someone asked about the difference between signing digests vs 
individual list messages, let me put a similar question:

   DKIM practices put much concern in preserving the integrity of an author's
   text.  Yet, when the same text is quoted in replies, it is subject to
   arbitrary changes, and nobody cares.

   Given that, why cannot we relax integrity requirements when a message is
   destined to a list, as if the list just "quoted" it?

As a practical possibility, a verifier may dump correctly signed List-Post 
addresses from incoming messages onto a database.  Let's call it the server's 
"participating MLMs DB."  When a signer is about to sign mail to a 
participating MLM, it puts l=0 and only signs the fields "From", "Date", and, 
if we wish to formalize the reason, "ADSP-Required".

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html