> The issue of A-R headers being trusted only when signed by DKIM runs > counter to their intended use.
That's not necessarily true. You're making hard assertions about a fuzzy situation. DKIM signing might work just fine in certain installations. That's why RFC5451 suggests doing this without requiring it. > Whatever leak that allows a bad actor's A-R header to appear > could also find itself inadvertently signed by the incoming domain. I agree that this is a security consideration, but it doesn't mean signing A-R headers is a waste of effort. At some sites it's probably the ideal solution. > Just check originating DKIM signatures, and ignore A-R headers would > be the safest solution. Use of A-R headers allow providers a means to > visibly modify messages without the recipient being aware that the > visible content had been added by the provider. In general, this > seems like a bad idea with respect to DKIM. I disagree with "in general". There seems to have been enough consensus to put A-R up to proposed standard status, and that seems to fly in the face of your claim that it's not useful. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
