ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Removing A-R headers

2009-06-10 14:50:39

On Jun 10, 2009, at 9:58 AM, Michael Thomas wrote:

J.D. Falk wrote:
Charles Lindsey wrote:

What I think it makes clear that we are in serious need of some  
document to provide Best Practice for how mailing list expanders  
should handle DKIM, and I think that is something that this WG  
needs to take on board.

Feel free to use my article on CircleID as a starting point:

http://www.circleid.com/posts/dkim_for_discussion_lists/

It's so simple and obvious (once you move from theory to practice)  
that I'm
not sure if it's worth the WG's time.

There is *NO* *REASON* to strip signatures. NONE.

In fact it is HARMFUL.

This is true for mailing lists when signature recovery is employed. :^)

In addition, acceptance of indirect A-R records should be handled with  
caution.   Keep in mind that A-R headers themselves are not secure,  
and that trust in "authserv-id" (that recipients may have been asked  
to enter into their MUA to enable annotations) need to have originated  
from their specific trust environment.  Unlike the d= parameter in  
DKIM, administrators of trust environments can assign an arbitrary and  
hopefully unique "authserv-id".  Imagine the fun and mischief this ad- 
hoc assignment permits, especially when identifiers have been  
encoded.  There are no A-R "authserv-id" police, nor is there a means  
to confirm legitimate use of "authserv-id" indirectly.  As such, the  
scope of specific "authserv-ids" should be restricted to the immediate  
receiving account.  To offer improved security,  non-local "authserv- 
id" A-R headers for the account should be removed or defanged to  
inhibit acceptance of possibly deceptive A-R headers.  It is common  
for filtering rules to move messages into folders shared by accounts,  
nor is there assurance that A-R headers have not been reordered when  
multiple A-R headers are discovered.

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