ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

2009-05-11 11:50:33

On May 11, 2009, at 8:29 AM, Eliot Lear wrote:

On 5/11/09 5:09 PM, Steve Atkins wrote:
On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:


I could conceivably see this being an issue on an acm.org style
forwarder,
if there were one that modified the content it forwarded, but not a
normal
mailing list. I don't think that's a iikely use case, though.


Sorry- I'm not quite sure what you're saying here.  That an ACM.ORG- 
like forwarding address is likely or that they would tag something  
to the bottom of a message?

I think it unlikely that they would modify the message, while not  
taking any responsibility for the message content.

A simple .forward style forwarder is fine, as it doesn't modify the  
content.

A forwarder that does modify the content in any way will invalidate  
DKIM signatures that do not use l= [1]. Because of that it will need  
to take that into account operationally, probably by signing with it's  
own signature on outbound and maybe validating signatures on inbound  
mail[2].

Whatever it does to handle forwarding of non-l=-using DKIM signed  
email correctly will also that it also forwards l=-using DKIM signed  
mail correctly, meaning l= adds no obvious value there.

Cheers,
   Steve

[1] it'll likely invalidate ones that do use l= too, but that's not  
important here.

[2] One of the more plausible use cases for the Authentication-Results  
header, where the header shows the results of inbound DKIM validation  
and is signed by the forwarders signature on outbound mail.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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