ietf-dkim
[Top] [All Lists]

[ietf-dkim] Alternative MAiling List Approach

2010-07-29 07:07:48
I promised to do this some while back, but only just got a round tuit.

Scenario:
     discardable.example publishes a 'discardable' ADSP
     MLM.example operates a mailing list that adds boilerplate that breaks  
signatures.
     joe(_at_)discardable(_dot_)example sends mail to the mailing list with
         From: joe(_at_)discardable(_dot_)example
     client(_at_)somewhere(_dot_)example subscribes to the mailing list. He (or 
his  
boundary provider) observes the broken signature and 'discardable' ADSP  
and discards, perhaps noisily. So client does not see the message but,  
worse, MLM.example may see the noisy rejection and unsubscribe client from  
the list.

Various suggestions  to mitigate this problem have been mooted, but none  
of them works perfectly, mainly because they rely on certain behaviours by  
discardable.example, MLM.example and discardable.example, all of whom need  
to persuaded to observe whatever "Best Practice" is being proposed.

The REAL cause of the problem is that From: line. My proposal is that MLM  
should change the From: header in such a way that the mail appears to have  
come from MLM.example and not from discardable.example. Clearly, this  
removes the cause of the problem at a stroke (the mail will no longer be  
discarded), but obviously it raises several other issues instead.

Chiefly, list subscribers (such as client(_at_)somewhere(_dot_)example) will 
not  
immediately see who the mail is from, and will not be able to reply  
directly to joe(_at_)discardable(_dot_)example(_dot_) There are several things 
that would  
need to be done to mitigate this:

1. Preserve in  an X-Old-From: joe(_at_)discardable(_dot_)example (but mailing 
agents  
will tend not to display that header).

2. Add a Reply-To: joe(_at_)discardable(_dot_)example (unless Joe had already  
supplied his own Reply-To:, or mailing list policy is to set Reply-To to  
point back to the list).

3. Preserve any <display-name> in the modified From: e.g.
        From "Joseph" <something(_at_)MLM(_dot_)example>

4. Somehow encode the original joe(_at_)discardable(_dot_)example within the 
revised  
From: header, preferably in such a way that replies will still get back to  
Joe.

And it is #4 which is really going to solve the problem, though #1-3  
should still be applied as backup measures that will assist the confused  
recipient.

So how to encode the old address within the new? Here is my proposal:

        From: "Joseph" <joe%discardable(_dot_)example(_at_)MLM(_dot_)example>

Which is, of course, the old (discredited?) "percent hack". But here used  
in a safely controlled environment.

Firstly, a recipient seeing it should have no problem extracting the real  
address manually. But we can do better than that. All that is required is  
for MLM.example to honour the "percent hack". And if he is using sendmail  
or EXIM, this is just a matter of configuring it back on.

In reality, MLM should be a bit nore cautious, perhaps only implementing  
the percent hack for cases which are subscribers to his mailing list, or  
adresses to which he knows he has previously sent mofified From: headers.

And there are further things that MLM could and SHOULD do as a matter of  
good practice:

1. Only modify the From: in cases where the incoming mail was DKIM-signed.

2. Verify any incoming DKIM signature and record the fact in an  
Authentication-Results header (unless he chooses to discard it for lack of  
authentication).

3. (Re-)Sign it, covering any added Authentication-Results.

So there it is. Discussion?

And if people like the idea, I could write it up as an ID.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html