> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Julian Mehnle > Sent: Tuesday, October 05, 2010 9:28 AM > To: ietf-dkim@mipassoc.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
