SMTP Service Extension for Message Tracking
This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 14 must, 5 should, 3 may.
2 SMTP Extension Overview
- MUSTIn addition, the ENVID parameter of the MAIL command (as defined in RFC 3461) MUST be supported, with extensions as described below.
- MUSTThe ORCPT parameter of the RCPT command (as defined in RFC 3461) MUST also be supported.
- MUSTAll semantics associated with ENVID and ORCPT described in RFC 3461 MUST be supported as part of this extension.
3.1 The MTRK parameter to the ESMTP MAIL command
- MUSTThis random number MUST be at least 128 bits but MUST NOT be more than 1024 bits.
- MAYServers MAY ignore this value if it violates local policy.
- MAYIn particular, servers MAY silently enforce an upper limit to how long they will retain tracking data; this limit MUST be at least one day.
- SHOULDThis default SHOULD be 8-10 days and MUST be at least one day.
- MUST NOTNotwithstanding this clause, the information MUST NOT be
- MUST NOTexpired while the message remains in the queue for this server: that is, an MTQP server MUST NOT deny knowledge of a message while that same message sits in the MTA queue.
- SHOULDIf the message is relayed to another compliant SMTP server, the MTA acting as the client SHOULD pass an mtrk-timeout field equal to the remaining life of that message tracking information.
- MUST NOTIf the decremented tracking timeout is less than or equal to zero, the entire MTRK parameter MUST NOT be passed to the next MTA; essentially, the entire tracking path is considered to be lost at that point.
3.2 Use of ENVID
- MUSTFor that purpose, if the MTRK parameter is given, an ENVID parameter MUST be included, and the syntax of ENVID from RFC 3461 is extended as follows:
- MUSTThe unique-envid MUST be chosen in such a way that the same ENVID will never be used by any other message sent from this system or any other system.
- SHOULDIn this case, the fqhn SHOULD be replaced by the SHA1(fqhn) encoded into BASE64.
- MUSTAny resubmissions of this message into the message transmission system MUST assign a new ENVID.
3.3 Forwarding Tracking Certifiers
- SHOULDMTAs SHOULD forward unexpired tracking certifiers to compliant mailers as the mail is transferred during regular hop-to-hop transfers.
- MUSTIf the "downstream" MTA is not MTRK-compliant, then the MTRK= parameter MUST be deleted.
- MUST NOTIf the downstream MTA is DSN- compliant, then the ENVID and ORCPT parameters MUST NOT be deleted.
- SHOULDIf aliasing, forwarding, or other redirection of a recipient occurs, and the result of the redirection is exactly one recipient, then the MTA SHOULD treat this as an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT= values; these values MUST NOT be modified except for decrementing the mtrk-timeout field of the MTRK= value, which MUST be modified as described in section 4.1 above.
- MUST NOTMTAs MUST NOT copy MTRK certifiers when a recipient is aliased, forwarded, or otherwise redirected and the redirection results in more than one recipient.
- MAYHowever, an MTA MAY designate one of the multiple recipients as the "primary" recipient to which tracking requests shall be forwarded; other addresses MUST NOT receive tracking certifiers.
- MUST NOTMTAs MUST NOT forward MTRK certifiers when doing mailing list expansion.