The address to which email is delivered might be different than any of the addresses shown in any of the content header fields [Mail-Fmt
], such as the To: and cc: fields that were created by the author's Message User Agent (MUA) [Mail-Arch
]. The address used by the Message Handling Service (MHS) is provided separately, in envelope information, such as through a "RCPT TO" command in [SMTP
As noted in Section 4.3.3
], 'A transfer of responsibility from the MHS to a Recipient's environment (mailbox) is called "delivery".' That is, when the destination address is fully and successfully processed, and any additional processing is by an agent working on behalf of that address, the message has been delivered. Rather than placing the message into a recipient inbox or otherwise completing the handling of the message, that agent might create additional processing, including to one or more different addresses. Each transition of responsibility, from the MHS to an agent of a current addressee, constitutes a distinct delivery. Given handling sequences that can include aliasing, mailing lists, and the like, the transit of a message from its author to a final recipient might include a series of submission/delivery events. Also, the delivery process at a receiving system can produce local (internal) address transformations.
Header fields that provide information about handling can be used when assessing email traffic issues and when diagnosing specific handling problems. To this end, it can be helpful for a message to have a common way to indicate each delivery in the handling sequence and to include each address that led to the final delivery. This can aid in the analysis of a message's transit handling.
An additional use can be to aid in detecting a delivery sequence loop, based on a specific address. With a problematic loop, the same copy of a message is delivered to the same email address more than once. This is different from having different copies delivered to the same address, such as happens when a message is sent directly to an address, as well as via a mailing list. It is also different from having two copies of the same message arrive at the same, ultimate destination address, having been originally posted to two different addresses. Further, this is different from noting when a message simply transits the same Message Transfer Agent (MTA) more than once, which might be necessary, such as when it is processed through a mailing list; an MTA services many addresses.
Delivering the same copy of a message more than once, to the same address, is almost certainly not an intended activity. An example of a problematic arrangement would be to send a message to mailing list List-A, where List-A contains an entry for List-B, and List-B contains an entry for List-A. The message will enter an infinite loop. Loop detection for email can be a complicated affair. The Delivered-To: header field provides helpful information, with a definitive indication that this copy of a message has (already) been delivered to a specific address.
When specifying new activity that is related to existing activity, there is a choice of design approach:
Seeking to change (some of) the existing behavior
Adding to the activity without changing what is already being done
Calling for separate, new activity
On the average, attempting to change existing activities is the least likely to obtain adoption; it can create operational confusion between old and new activities, which in turn creates resistance to adoption. Seeking new activity can make sense when that activity is sufficiently different and deemed sufficiently beneficial. Adding to existing activity has the selling point of building upon an installed base. The current specification builds upon an existing installed base of Delivered-To: activity. It calls for little technical enhancement; rather, it simply provides for a wider range of application.
Email handling information, such as this, provides information about the email infrastructure, as well as about the recipient. Disclosure of this information might engender privacy concerns.
A specification is not automatically assured of adoption or use. Therefore, this document is being published as an Experimental RFC, looking for extended constituency and for general operational utility.
This document was produced through the Independent RFC Stream and was not subject to the IETF's approval process.