[ietf-dkim] Removing A-R headers

[Doug Otis]

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