Sieve Email Filtering: Editheader Extension
Extracted elements (24)
editheader is the first standardized Sieve extension that allows alteration of messages being processed. The prohibition on modifying Received and Auto-Submitted headers was specifically chosen to preserve email loop prevention mechanisms defined in [SMTP].
It is not an error if no header fields match the deleteheader conditions or if the :index argument exceeds the number of named header fields; the action is simply a no-op in those cases.
editheader does not directly affect S/MIME or OpenPGP signatures because those schemes include a separate copy of header fields inside the signed body part; however, software comparing inner (signed) and outer (editheader-modified) headers may behave differently.
If the presence or value of a header field affects how the implementation parses or decodes other message parts (e.g., Content-Type affecting body decoding), the implementation MAY ignore changes to those header fields for parsing purposes, while still requiring that direct tests see the modified values.
The implicit keep is considered to execute at the end of the script after headers have been modified, so the delivered message reflects all header changes; a canceled implicit keep remains canceled regardless.
Actions that generate MDN, DSN, or similar disposition messages MUST do so using the original, unmodified message header. Similarly, if a script error triggers an implicit keep, the original header MUST be used.
All other actions that store, send, or alter the message MUST do so with the current set of header fields, including addheader and deleteheader themselves; each action's effects are immediately visible to subsequent actions.
An implementation MAY impose a length limit on the encoded header field, but such a limit MUST NOT be less than 998 characters (not including the terminating CRLF).
For the purpose of weeding out duplicates, a message modified by addheader or deleteheader MUST be considered the same as the original message; redundant keep/fileinto actions after header modification still count as a single delivery.
If a script tries to make a change that is not permitted by local policy (e.g., deleting a protected header field), the attempt MUST be silently ignored.
If the addheader field value does not match the [IMAIL] "unstructured" nonterminal or exceeds a length limit, the implementation MUST either flag an error or encode the field using folding white space and MIME encodings per [MIME3] or [MIMEPARAM].
If the field-name supplied to addheader or deleteheader is not a valid 7-bit US-ASCII header field name per the [IMAIL] "field-name" nonterminal, the implementation MUST flag an error.
Implementations MUST NOT permit attempts to delete "Received" and "Auto-Submitted" header fields, and MUST permit both addition and deletion of the "Subject" header field.
Tests and actions such as "exists", "header", or "vacation" that examine header fields MUST examine the current state of the header as modified by any actions that have taken place so far.
The deleteheader field-name is always matched as a case-insensitive US-ASCII string.
The implementation MUST flag an error if :last is specified in deleteheader without also specifying :index.
The addheader action adds a header field to the existing message header. Syntax: "addheader" [":last"] <field-name: string> <value: string>. By default it inserts at the beginning; with :last it appends at the end.
The capability string for this extension is "editheader". Implementations advertise support by including this string in the capability response.
The deleteheader action deletes occurrences of a named header field, optionally filtered by value-patterns and indexed position. Syntax: "deleteheader" [":index" <fieldno: number> [":last"]] [COMPARATOR] [MATCH-TYPE] <field-name: string> [<value-patterns: string-list>].
IANA registration of the Sieve capability name "editheader", which adds the addheader and deleteheader actions that modify the header of the message being processed. Registered per RFC 5293.
A Sieve script combining editheader, Sieve tests, and the redirect action back to the same user can maintain state across invocations; however, infinite loops are impossible because each iteration adds a Received header field and editheader cannot delete Received fields, so standard SMTP loop prevention will eventually non-deliver the message.
Deleting header fields may destroy evidence about the path a message has taken, and any header modification can invalidate digital signature mechanisms (e.g., DKIM) that cover header fields, including signatures that guarantee a header field's absence.
Header-based decision mechanisms in Sieve scripts are vulnerable to spoofing: a malicious sender can add any header or tag that the filter uses for access control decisions. Deleting or renaming such headers before processing is the recommended mitigation.
Someone with write access to a user's script storage may use editheader to generate headers that a user would otherwise be shielded from (e.g., headers stripped by a gateway MTA).