ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)

2009-06-22 11:47:59

On Jun 22, 2009, at 2:51 AM, Charles Lindsey wrote:

On Fri, 19 Jun 2009 17:55:57 +0100, Douglas Otis <dotis(_at_)mail- 
abuse.org>
wrote:

It dangerous to consider A-R headers of unknown origins as somehow  
inherently safe......

Unless they are included in a signature.

Unverifiable DKIM signatures will not confirm the origin of an A-R  
header.

An A-R record always includes an idication of the domain that  
purported to have place it there. If it is signed by that same  
domain (as would be the case in the scenarios we are discussing),  
then more reliance can be placed on it (depending on your opinion of  
that signer - but you opinion of the manager of a mailing list you  
have subscribed to is likely to be quite high).

There is no assurance that RFC 5451 "authserv-id" have any  
relationship with an RFC 4871 d= values.  There is also no assurance  
that  bogus A-R headers would have been removed.  Amongst  the  
confused advice about retaining A-R headers, there is also not a  
certain practice of not signing A-R headers, even when A-R headers are  
not added.  Do you expect there will be d= requirements imposed upon  
authserv-ids, since that is not how A-R validation works?

I agree that an unsigned A-R is dubious, but even then if it  
purports to have been placed there by a domain which
   a) the message has been passed through, and
   b) you are prepared to trust to have removed any pre-existing  
bogus A-R purporting to have been placed there by that domain
then it should be pretty safe (and this was indeed the case for the  
example we were discussing).


What this would be trusting may not be common practice.  In addition,  
there is no defined relationship between authserv-id and d= values or,  
for that matter, domains in general.

A mailing list might use a signing domain of "foo.tld" and the  
authserv-id of "bar.unique".

By allowing inclusion of A-R headers having unknown origins remains a  
risky practice since a recipient's MUA might trust these headers.

A safe practice would remove all foreign A-R headers.  Exceptions made  
when signed by verified DKIM signatures still requires trusting the  
DKIM signature not to introduce misleading A-R headers.  Again, there  
is no direct relationship between RFC 5451 "authserv-id" and RFC 4871  
d= values.

-Doug



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

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