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