ietf-corpus

rfc-3885

SMTP Service Extension for Message Tracking

E. Allman, T. Hansen
date2004-09 streamIETF areaapp wgmsgtrk statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc3885 doi10.17487/RFC3885
This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]

updates

Extracted elements (22)

design-rationale §3.1

A timeout (relative duration) is used for the mtrk-timeout field rather than an absolute time, following the rationale in RFC 2852 (Deliver By). This avoids clock synchronization issues between MTAs.

email

design-rationale §3.2

When (local-envid + fqhn + 1) exceeds 100 characters, the fqhn SHOULD be replaced by SHA1(fqhn) encoded in BASE64, yielding a 27-octet string and limiting local-envid to 72 octets. This preserves global uniqueness within the ENVID length constraint.

email, crypto

interoperability-note §1

Message Tracking is intended as a last-resort mechanism; DSNs and MDNs provide primary delivery status. A tracking query should only be issued if the message is not received and neither DSN nor MDN has responded.

email

normative-requirement §3.1 SHOULD

If no mtrk-timeout is specified, the server SHOULD use a local default of 8-10 days, and that default MUST be at least one day.

email

normative-requirement §3.3 MUST

If the downstream MTA is DSN-compliant, the ENVID and ORCPT parameters MUST NOT be deleted even when dropping the MTRK= parameter.

email

normative-requirement §2 MUST

If the MTRK parameter is given, an ENVID parameter MUST be included on the MAIL command. The ENVID and ORCPT parameters from RFC 3461 MUST be supported, and all RFC 3461 semantics MUST be supported as part of this extension.

email

normative-requirement §3.3 MUST

MTAs MUST NOT copy MTRK certifiers when redirection results in more than one recipient. An MTA MAY designate one primary recipient for tracking; other addresses MUST NOT receive tracking certifiers. MTAs MUST NOT forward MTRK certifiers during mailing list expansion.

email

normative-requirement §3.3 MUST

MTAs SHOULD forward unexpired tracking certifiers to compliant mailers during hop-to-hop transfers. If the downstream MTA is not MTRK-compliant, the MTRK= parameter MUST be deleted.

email

normative-requirement §3.1 MUST

Servers MAY ignore the mtrk-timeout value if it violates local policy, but any enforced upper limit MUST be at least one day. An MTQP server MUST NOT deny knowledge of a message while that message still sits in the MTA queue.

email

normative-requirement §3.1 MUST

The random number A used to compute the tracking certifier MUST be at least 128 bits but MUST NOT be more than 1024 bits.

email, crypto, security

normative-requirement §3.2 MUST

The unique-envid MUST be chosen so the same ENVID is never used by any other message from any system. Any resubmission of a message into the transmission system MUST assign a new ENVID.

email

normative-requirement §3.3 SHOULD

When aliasing or forwarding results in exactly one recipient, the MTA SHOULD treat it as an ordinary hop-to-hop transfer and forward MTRK=, ENVID=, and ORCPT= values; these MUST NOT be modified except for decrementing mtrk-timeout.

email

normative-requirement §3.1 MUST

When relaying to another compliant SMTP server, the MTA SHOULD pass an mtrk-timeout decremented by the seconds the message lingered. If the decremented timeout is <= 0, the entire MTRK parameter MUST NOT be passed to the next MTA.

email

protocol-element §2

The maximum length of a MAIL command line is increased by 40 characters to accommodate the MTRK keyword and value, in addition to the 507-character extension for ORCPT and the 107-character extension for ENVID mandated by RFC 3461.

email

protocol-element §3.1

The MTRK parameter to the MAIL command carries a base64-encoded SHA-1 hash (mtrk-certifier) and an optional timeout in seconds (mtrk-timeout). The sender generates a large random number A, computes B=SHA1(A), base64-encodes B, and passes it as the mtrk-certifier.

email, crypto, security

protocol-element §2

The SMTP service extension 'Message Tracking' is identified by the EHLO keyword 'MTRK'. No parameters are allowed with this EHLO keyword value. Future documents may extend this specification by specifying parameters.

email, registry

registry §5

IANA has registered the SMTP extension 'Message Tracking' with EHLO keyword 'MTRK' as defined in section 3 of this document.

email, registry

security-consideration §4.1

An attacker could flood a server's tracking database by submitting large numbers of small tracked messages (denial of service). Sites may mitigate by retroactively lowering their maximum retention period.

email, security

security-consideration §4.2

Site administrators may wish to treat delivery to an alias as final delivery to protect individual identities (e.g., postmaster or webmaster aliases), and implementors are encouraged to provide mechanisms allowing administrators to choose whether to permit tracking through aliases.

email, security, privacy

security-consideration §4.2

The mtrk-authenticator value A must be hard to predict and must not be reused. The originating client must protect the secret from attackers, particularly on shared message stores such as a 'Sent' folder.

email, security, crypto

wire-format §3.2

The ENVID parameter is extended to require a globally unique form: unique-envid = local-envid '@' fqhn, where fqhn is the fully qualified host name. The total ENVID length must not exceed 100 characters.

email

wire-format §3.1

The MTRK parameter syntax is: mtrk-parameter = 'MTRK=' mtrk-certifier [':' mtrk-timeout]; mtrk-certifier is a base64-encoded 128-bit SHA-1 hash; mtrk-timeout is 1-9 decimal digits representing seconds until timeout.

email