Header fields are sometimes used to communicate information between email servers within a private network.   The Authentication-Results header field definition was an attempt to formalize that behavior while providing a single header within which that communication takes place.     

When a header field is used to alter downstream behavior, header field security becomes a concern.  If an attacker learns what header fields will alter behavior in a victim organization, the attacker has an incentive to spoof those headers.   In the worst case, the spoofed header field may cause a dangerous message to be treated as acceptable.

The RFC for Authentication-Results provides two mechanisms to address the problem:   (1) a label to identity messages created locally, and (b) purging.    The label is an insecure method of indicating which server inserted the header, but it can prevent confusion.  To prevent spoofing, the RFC recommends purging any Authentication-Results header fields embedded in a message upon arrival.  To prevent information leakage, internally-generated Authentication-Result should be purged prior to outbound transmission.

The problem is not limited to Authentication-Results; it is applicable to any header field that is used for communication along the mail stream.  So I am asking for an implementation that provides a general solution.

There are two ways to defeat a spoofed header:  removing it from the message or renaming it so that it is ineffective.   For editing of inbound traffic, I favor the renaming method, as it preserves evidence if a spoofing attack has actually occurred.  (Renaming simply requires inserting a prefix on the header field name, so that “headername” becomes “x-prefix-headername”.)  For outbound traffic, deleting is preferable, because it is performed to hide internal-only information.  An implementation that provides both options allows for both scenarios and allows for administrator preference.

I envision three different edits: