-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Julian Mehnle
Sent: Tuesday, October 05, 2010 9:28 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple
5322.From
From: is already there. The RFC explains how to prevent addition of a
field that wasn't there to begin with, not to prevent addition of new
ones.
No, read section 5.4 again. Hector even quoted the relevant parts in
his thread opening message.
Ah, I see now. I understand 5.4, but I've only ever applied it to preventing
addition of a header field that wasn't there in the first place, not to prevent
addition of a second one. That's a pretty clever solution.
Still, though, it's a solution to deal with malformations to which MUAs are
susceptible, and not strictly a DKIM problem.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html