> Any filter or agent that makes any kind of filtering, routing or > sorting decision based on any header field which in turn presumes > there's only one such field without actually checking is a potential > security concern.
I think this is a subtely different problem though. All of the examples you cite (and all other pre-DKIM examples for that matter) are foolable with a single forged header today. That they could be further fooled with multiple headers is not an issue. In a future world where such tools (and UAs) could act with authority because DKIM has assured the headers/payload is where we have the problem. Only once tools and UAs take advantage of DKIM, do these attacks become relevant. That's why I think this is a DKIM problem. We are wanting tools and UAs to take advantage of DKIM but by doing so they are possibly making themselves more vulnerable to attackers. A simple (but hyperthetical) example. If you unsubscribe from a list today, most list servers typically confirm the request by emailing you back with some nonce to ensure the unsubscribe request isn't forged. You then hit reply or click on the link to confirm you have access to that mailbox, etc. In a DKIM world a list server could reasonable use DKIM to bypass this "confirm" sequence and make your life a bit simpler. Perhaps it relies on Authentication-Results or somesuch. In any event such a list server is actually *more* vulnerable than it is today if we let thru bogus payload that appear to be valid. IOW. Asking them to rely on DKIM is a backward step. Mark. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html