]> Fastmail Pty Ltd

Level 2, 114 William Street 3000 Australia +61 457 416 436 brong@fastmailteam.com

Internet-Draft This memo describes a method for describing the changes made to an email during common email modifications, for example those caused by mailing lists and forwarders. While this is general enough to be used for any changes, it is anticipated that this method will normally be used for removing added data rather than large complex changes. This method also captures hashes of important features of the message, allowing validation that the changes were described correctly, and allowing a signature which covers the Mail-Version header to, by extention, ensure that the important content of the message is unchanged.

Background and motivations Currently, when an email is sent with a DKIM signature, the message can go through multiple forwarders and still be authenticated, however if a single change is made to a header which is covered by the signature, or to the body, then the signature no longer validates - and it's impossible for the receiver to know what was changed, or even if the entire message was replaced. By producing a way to describe changes, the recipient can examine the sections which were changed and determine whether the change was malicious. By undoing the changes, it is possible to recreate a message which matches the original signature, and hence provide accountability for the content which was present in the copy of the message to which the signature was applied.

The Mail-Version Header Field This document describes an ordered set of header fields, each of which describes the message at a specific version, along with instructions on how to convert that version back to the previous version. To well formed, a message must have a monotonically increasing set of Mail-Version header fields, with the first having mv=1 and each having an increasing integer number, with no gaps.

Mail-Version Header The format of the value is a tag-list. Tag-lists contain key=value; key2=value2; - they can be wrapped, and all whitespace is normalised to a single space. TODO: we need to specify tag-list. Tag Type Value mv position Revision number (range: 1 to 100) h headerlist List of headers signed by the hh field. a hash-alg Hash Algorithm used (at least sha256 must be supported); used for hh, bh and ph hh base64 Header Hash for the named headers, using the 'relaxed' header algorith from bh base64 Body Hash, using the 'relaxed' body algorithm from ph.n.m base64 Hash for the binary representation of the numbered mime part, after removal of any content-transfer-encoding (this is the data returned by FETCH BINARY[n.m] as described in section 7.5.2) b body-recipe Recipe to replicate the previous version of the message body h.header head-recipe Recipe to replicate the previous version of the named header field TODO: do we want to add 'bh.n.m' to hash the un-decoded body of individual MIME parts, and hh.n.m to hash the headers of the MIME part as well?

body-recipe The Body Recipe is a comma separated list of instructions. Each instruction starts with a prefix. Commas can be followed by optional whitespace. The presence of a recipe replaces the previous value, so the tag-value b= creates an empty body, while the tag-value b=b: creates a message with a single blank line for the body. Prefix Value Action c: start-end Copy the lines (inclusive) numbered from 1. E.g. "c:1-3" copies the first three lines. b: base64 Decode the base64 to get the value of a line to insert. The base64 value does NOT include the trailing CRLF, which must be added at the end of the line, hence "b:" means insert an empty line, and "b:SGVsbG8=" inserts the line "Hello". z none If present, says that changes have been made to the body which can not be described to get back to the earlier version, meaning the signing system takes accountability for the full content.

header-recipe The Header Recipe is a comma separated list of instructions. Each instruction starts with a prefix. Commas can be followed by optional whitespace. While key names are case insensitive, implementations SHOULD create the header with the same case as the key. The presence of a recipe removes every instance of the named header field before applying the recipe, so the tag-value h.foo= removes all instances of Foo from the message. Prefix Value Action c: start-end Copy the values of the header-fields with the indexes, numbered from 1 and starting at the bottom; b: base64 Decode the base64 to get the value of a header field to insert. The base64 value does NOT include the trailing CRLF, which must be added at the end of the line, hence "b:" means insert a header-field with an empty value. z none If present, says that changes have been made to the named header field which can not be described to get back to the earlier version, meaning the signing system takes accountability for the full content of this message. NOTE: the headers are inserted from the bottom, i.e. prepended to the message in the order that they are named. e.g. given a message with headers:

And the recipe: h.Foo=c:1-1,b:Zm91cg==,c:2-3 The output will be: ~~~ Foo: three Foo: two Foo: four Foo: one ~~~

Examples Example for a message which has had Subject and From replaced, and Reply-To added.

Example:

Example - a URL was substituted in the content of the body (complex, but still easily doable!)

It is expected that 'c' will normally be used to copy lines directly from the new message, however in cases where a message needs to transit 7 bit systems cleanly, the email modifier may need to re-encode the octets of the original message, and this allows for doing so, albeit at some expense in header bloat!

Iterative application To get back to the original message and confirm that it was unchanged, it is necessary to apply this algorith iteratively. For example if you receive a message for which there is a modification to the headers at mv=3 and a modification to both headers and body at mv=2, to recreate the original message you would first apply the header changes from mv=3, then apply the header and body changes for mv=2. If this doesn't create a message which validates with the initial mv=1 hash, then some hop has corrupted the message.

Security Since a Mail-Version header can be used to recreate any email content, implementations need to be aware that this could be used to bypass security checks, and passing the generated message to a parser could expose it to content that would otherwise be blocked by earlier security checks, e.g. the base64 output could generate 8 bit content or NULL bytes that would otherwise be blocked by a simple filter.

IANA Considerations IANA is requested to add to the Permanent Message Header Field Names registry the following record. Header Field Name: Mail-Version Template: Protocol: mail Status: standard Trace: no Reference: this document

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409.

Changes from Earlier Versions

draft-gondwana-dkim2-mailversion-00 Rename this draft to "mailversion". Rename the header field to 'Mail-Version' Change 'v=' to 'mv=' so it matches DKIM2-Signature and doesn't confuse protocol versions Removed 't:' optional fields entirely. Added ha= to select the hash algorithm and documentation about how the hashes are calculated Renamed bin.partspec to ph.partspec for "part hash" and described it with reference to IMAP. Added security considerations Added IANA considerations

draft-gondwana-dkim2-modification-algebra-03 Rename header to 'MailVersion' Remove all requirements that it integrates with DKIM2. Add body hash and per-mime-part hashes (NOTE: this is a bunch of extra calculation, so definitely to discuss)

draft-gondwana-dkim2-modification-algebra-02 change the header format to have unique keys, making it fit the ABNF for these types of headers. allow easier editing of multi-value headers by always popping the first header and always prepending newly added headers. change body to use d.0, d.1, etc with the program in the value, so that the program ordering is reliable regardless of the parser used to read the header.

draft-gondwana-dkim2-modification-algebra-02 change to using line numbers rather than octet offsets remove d= base64 decoding capability for multiple lines; require a separate b= or t= for each line

draft-gondwana-dkim2-modification-algebra-01 rename 'DKIM2-Diff' headers to 'DKIM2-Delta' add 'z=y' option to DKIM2-Delta-Body for "complete replacement" add d= base64 decoding option to DKIM2-Delta-Body

draft-gondwana-dkim2-modification-algebra-00 original version [[This section to be removed by RFC Editor]]