Network Working Group W. Leibzon Internet-Draft Elan Networks Expires: November 2, 2005 May 01, 2005 Email Forwarding and Redirection Trace Header Fields draft-leibzon-emailredirection-traceheaders-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines Redirected email trace header field which can be used to identify changes made to source and destination parameters of email message by SMTP forwarding and redirection systems and to identify what type of redirection took place. Original-* headers are also defined to show changes made to other headers by forwarding and redirection systems. Leibzon Expires November 2, 2005 [Page 1] Internet-Draft Email Redirection Trace Header May 2005 Conventions Used in This Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Redirected Email Header Field . . . . . . . . . . . . . . . . 4 2.1 Syntax of Redirected Header Field . . . . . . . . . . . . 5 2.2 Required data in Redirected header field . . . . . . . . . 5 2.2.2 Process-type parameter . . . . . . . . . . . . . . . . 6 2.3 Recording email envelope changes . . . . . . . . . . . . . 6 2.4 Recording list of changed header fields . . . . . . . . . 8 3. Original-* and Saved-* header fields . . . . . . . . . . . . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Mail Forwarding . . . . . . . . . . . . . . . . . . . . . 11 4.2 Mail List . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 Automated SMTP Redirection . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1 Normative References . . . . . . . . . . . . . . . . . . . 25 8.2 Informative References . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 26 Leibzon Expires November 2, 2005 [Page 2] Internet-Draft Email Redirection Trace Header May 2005 1. Introduction Email message on its way from sender to recipient passes through a number of SMTP systems and may undergo various changes to its destination and source information. These changes are the result of email message being processed by systems such as forwarders, mail list processors, an SMTP proxy systems and other types of forwarding and email redirection systems. The final recipient often has no idea what kind of changes may have happened to the email message while it was in transit and this information is often desired when debugging email routing problems, when investigating the source of unwanted email and for many other reasons. This document attempts to help in tracking changes done to email message during transmission by introducing "Redirected" trace header field which automated email forwarding and redirection systems may use to record changes done by them to email message. Additionally "Original-*" and "Saved-*" header fields are also defined to allow these systems to record original and new values of those headers that may have been changed. Leibzon Expires November 2, 2005 [Page 3] Internet-Draft Email Redirection Trace Header May 2005 2. Redirected Email Header Field "Redirected:" email header field SHOULD be added by email processing systems that change destination or source of an email message while it is in transit. Such systems include but are not limited to mail list processing systems, email forwarding systems, SMTP proxy systems and others. In this document all such email processing systems are referred to collectively as mail redirection agents (MRA) and the processing done by such systems is referred to as email redirection. The header is used to provide information about type of email processing occurred and email address of the party responsible for initiating email redirection. When used this header field MUST include information about which email transmission [RFC2821] parameters and/or [RFC2822] header fields are changed by mail redirection agent. Note that Redirected header is intended to be used when email forwarding is being done automatically, but not in case of manual user-initiated email forwarding. In cases of manual forwarding, saving original values of RFC2821 session parameters should be done by mail delivery agent, which can use "Return-Path:", "Delivered-To:" and other similar header fields for this purpose. In case of manual forwarding if original header fields are desired to be preserved, the forwarding agent may either include them together with original message by creating Message/RFC2822 mime part or it can keep entire message as it was and use Resent-* header fields to specify new email source and recipient information as described in section 3.6.6 of [RFC2822]. Leibzon Expires November 2, 2005 [Page 4] Internet-Draft Email Redirection Trace Header May 2005 2.1 Syntax of Redirected Header Field The ABNF [RFC2234] syntax of "Redirected:" email header is as follows: Redirected = "Redirected:" FWS "by" system-info FWS params-list [FWS] ";" date-time CRLF system-info = system-name [optional-info] system-name = domain / address-literal params-list = param *(FWS param) param = param-name FWS data-val-list [optional-info] param-name = ALPHA *(["-"] (ALPHA / DIGIT)) optional-info = FWS "(" [FWS] data-val-list [FWS] ")" data-val-list = data-val-pair *([FWS] "," FWS data-val-pair) data-val-pair = item-name [ "=" item-value ] item-name = ALPHA *(["-"] (ALPHA / DIGIT)) item-value = quoted-string Of the structures not defined above - date-time, quoted-string, domain, FWS and CRLF are defined in [RFC2822] and domain and address- literal are defined in [RFC2821]. 2.2 Required data in Redirected header field Redirected header field should start with information about system adding it. Fully qualified domain name of the system MUST be added following "by" clause and furthermore ip address of the system SHOULD be recorded by putting it inside "( )" data structure that follows system name. The ip address should be recorded as "ip=[A.B.C.D]" where a.b.c.d is actual ip address and if system has ip addresses of multiple types (i.e. both IPv4 and IPv6 addresses) then all these ip addresses SHOULD be added and this is done by having more then one instance of "ip=" separated by ",". Here is how this would look like for system forwarder.example.com, which has IPv4 address 192.168.0.1 Redirected: by forwarder.example.com (ip=[192.168.0.1]) Leibzon Expires November 2, 2005 [Page 5] Internet-Draft Email Redirection Trace Header May 2005 2.2.1 On-behalf-of parameter The first required redirection parameter is "on-behalf-of", which is used to specify email address of the person or entity that caused redirection agent to do email processing being recorded by the Redirected header field. Choosing email address depends on what kind of redirection is taking place. In case of mail lists, the entity responsible for initiating processing is mail list itself, and so email address of the list or email address of the list owner should be entered here. In case of SMTP proxy, the entity is always proxy itself, so specially designated address or address of SMTP proxy system postmaster is to be used. For forwarders that change destination of the message based on settings associated with original RCPT TO address, this RCPT TO address can be used in on-behalf-of parameter. If there are privacy concerns regarding using real user email address, then forwarding agent may use an alias or may designate and use its own default administrator account, such as postmaster. For those systems that support responsible submitter extension (see [responsible-submitter]) the email address used with SUBMITTER MAIL parameter would often be the same as on-behalf-of address. 2.2.2 Process-type parameter The second required parameter is "process-type" which is used to specify type of email processing taking place. In this document there are three values defined that can be used: "forwarding", "mail- list" and "smtp-proxy". Any other types that are used MUST be defined by other IETF documents. If it is not certain what type of processing is being done by forwarding agent, then it SHOULD be reported as default "forwarding" type. An optional information can also be reported together with this parameter that indicates an exact processing id, for instance for email lists it is recommended that list-id be included. Example of this is: process-type mail-list (list-id=) 2.3 Recording email envelope changes Email envelope is SMTP [RFC2821] session data associated with MAIL FROM and RCPT TO commands. If email is relayed by SMTP server, then these data values are not changed and SMTP Server would use the same information when it connects to another SMTP server as what it received from incoming connection. But if redirection is taking Leibzon Expires November 2, 2005 [Page 6] Internet-Draft Email Redirection Trace Header May 2005 place then some of these parameters maybe changed and new MAIL FROM and/or RCPT TO email addresses would be used in the message transmitted to next SMTP server by redirection agent. Redirected header SHOULD be used to record changes done by email processing systems to email envelope parameters that are associated with either source or destination addresses of email message. Such parameters include actual email addresses in "MAIL FROM" and "RCPT TO" SMTP commands and other addresses associated with source or destination such as ORCPT parameter of RCPT command (see [RFC3461]) and SUBMITTER parameter of MAIL command (see [responsible-submitter]. Changes to other message identification parameters such as ENVID parameter of MAIL [RFC3461] may also be recorded by this header. Two Redirected data parameters that are used to record changes to email envelope are "original-envelope" and "new-envelope". After original-envelope follows list of envelope parameter values that are changed during processing done by redirection agent (this also includes listing those parameters that were present in incoming SMTP session but would not be passed along to the next server). Following new-envelope is a list of those envelope parameters that were changed with their new values as well as list of any new source or destination or message identity SMTP parameters that are being introduced by redirection agent. Each envelope parameter is recorded following original-envelope or new-envelope and name of the recorded parameter is based on if the parameter is passed with MAIL command or RCPT command. For MAIL command parameters, the name should be 'mail-name' where name is exactly the same as MAIL parameter keyword name, for example for SUBMITTER [responsible-submitter] parameter the name would be "mail- submitter". For RCPT command parameters, the name should be rcpt- name where name is exactly the same as RCPT parameter keyword, for example "rcpt-orcpt" for ORCPT [RFC3461] For email address directly following MAIL FROM, the item name used for recording this address is "return-path". For email addresses following RCPT TO the item name used is "recipient". If any of the MAIL or RCPT parameters to be recorded consist of multiple email addresses (such as multiple addresses following RCPT TO) then listing of all of them requires use of quotes to make the list of these addresses become one string value. Note also, that if original value contains a list of addresses and new value of same parameter contains singular address, but one found among original list, then it is NOT RECOMMENDED that these values be recorded in original-envelope and new-envelope parameters. If there are multiple RCPT commands issued during the same SMTP Leibzon Expires November 2, 2005 [Page 7] Internet-Draft Email Redirection Trace Header May 2005 session then mail agent should treat them as separate instances for purposes of adding Redirected header field. In particular the address and parameters from one RCPT instance MUST NOT appear in the Redirected header field included in the email message being sent as a result of processing of another RCPT command, except when as a result of forwarding action the actual recipient is the same, in which case all the original recepient addresses SHOULD be included as part of "original-envelope" section and multiple mailboxes from original "RCPT TO" can then be collated into the single "recepient" parameter with multiple addresses. Additionally in case of email list it is often desirable for mail list processor to prepare single mail message content data for delivery to all mail list subscribers. However "RCPT TO" address would be different for each subscriber, so adding "recipient" into "new-envelope" parameter would require different message content for different subscribers. An alternative to this is to record only "recipient" parameter name in the "new-envelope" (without =") to indicate that it has been changed. The new value of RCPT TO can then be recorded directly by SMTP server (rather then mail list processing program) by means of "for" clause of Received header field. For more information, please refer to "Mail List" example include in this document. 2.4 Recording list of changed header fields In addition to modifying SMTP envelope data, most redirection agents also modify existing header fields or add new header fields to email message (and there are even some redirection agents that only add or modify source or destination header fields without actually changing envelope). Consequently Redirected header offers a way that MRA can report which header fields were changed by means of "changed-header" parameter. While there are number of header fields used in email message, when tracking email routing changes done by MRAs of most interest are those header fields that specify source or destination information or other message identification data. The following is partial list and brief description of such fields with information as to which IETF document describes how the field is used: To: - Primary recipient mailbox, see [RFC2822] Cc: - Carbon-copy recipient mailbox, see [RFC2822] From: - Mailbox of message author, see [RFC2822] Sender: - Mailbox of message sender, see [RFC2822] Reply-To: - Mailbox for replies to message, see [RFC2822] Message-ID: - Message identifier, see [RFC2822] List-ID: - Mail list identifier, see [RFC2919] If changes are made to above listed header fields by MRA, than it Leibzon Expires November 2, 2005 [Page 8] Internet-Draft Email Redirection Trace Header May 2005 SHOULD be recorded by means of Redirected header. Missing from above list are some header fields that include message source or destination information, but where existing instances of the header fields are not supposed to be modified by subsequent email processing agents. This includes all fields, where new instances are added to the beginning of the message (but existing instances are not removed) as are all trace header fields like Received and Return- Path as well as all Resent-* header fields. This also includes "BCC:", which field, if present, is not supposed to be modified; nor is reporting it in trace header appropriate because of privacy concerns, as it is supposed to be hidden field present only during message submission by MUA, but not in subsequent processing done by MRA. For other header fields, even if field is not related to message source or destination, if its value is modified by retransmission agent, it MAY also be listed in Redirected "changed-header" parameter. When listing header fields following "changed-header" parameter keyword, it should consist only of list of field names separated from each other by "," but not any values of these header fields. Unlike envelope data, values of changed header fields are reported as separate header fields as described in the next section of this document. Leibzon Expires November 2, 2005 [Page 9] Internet-Draft Email Redirection Trace Header May 2005 3. Original-* and Saved-* header fields When header field of an email message is modified or replaced by an MRA as described previous section of this document, then the original value of the field SHOULD be preserved by taking entire header field and adding "Original-" before its name and them putting this new header field right below corresponding Redirected header field. Note that list of header fields in "changed-header" parameter may include larger set of header fields then what is preserved by means of Original- fields, since 'changed-header' list also includes some header fields that are newly added by redirection agent. Additionally new value of header field that has been changed or added by redirection agent and listed in the "changed-headers" parameter MAY also be saved for debugging purposes by means of Saved-* header field. The process is the same as with Original-* and involves taking entire header field, adding "Saved-" before its name and then putting this new header field below or above Redirected. If both Original-* and Saved-* header fields are added then Saved-* header fields MUST be placed above Original-*, Redirected header field MUST also always be above corresponding Original- fields. If redirection agent is also adding Received header field then Received SHOULD be added below the Original-* fields (but in some cases as described in section 2.3 adding extra Received header field above Redirected may also be appropriate) . Please note that Original-* header fields maybe added by systems that do not add Redirected header field at the same time. The meaning of these header fields is the same and represents value of the header fields at the earlier stage of email transmission. Leibzon Expires November 2, 2005 [Page 10] Internet-Draft Email Redirection Trace Header May 2005 4. Examples This section provides examples of how Redirected and corresponding Original-* and Saved-* header fields can be used by various email forwarding and redirection systems . The following dramatic personae appear in the examples: alice@wonder.land.example: the original author of e-mail message rabbit@wonder.land.example: Alice's assistant who is the one actually sending most messages bob@company.com.example: the final recipient of each e-mail bob@almamater.edu.example: an email address used by Bob which he configured to forward mail to his office account at bob@company.com.example list@maillist.org.example: a mail list which both Bob and Alice are subscribed to The mail systems in the examples have the following ip addresses: mail.wonder.land.example - 10.0.0.1 mail.company.com.example - 10.2.0.1 mail.almamater.edu.example - 10.4.0.1 mail.maillist.org.example - 10.8.0.1 mobile-123.wondermobile.land.example - 10.10.3.123 mobile-proxy.wondermobile.land.example - 10.10.2.1 4.1 Mail Forwarding Alice asks Mr Rabbit to deliver a message to her Uncle Bob and Mr. Rabbit being sophisticated fellow with busy schedule decides to send it by email. He creates message with header fields as follows: From: "Alice" To: "Uncle Bob" Sender: "W. Rabbit" Subject: Invitation to tea party Date: Sat, 16 Oct 2004 00:00:00 +0000 Message-ID: <123456789@wonder.land.example> Leibzon Expires November 2, 2005 [Page 11] Internet-Draft Email Redirection Trace Header May 2005 An SMTP session from mail.wonder.land.example server might then look something like this: S: 220 mail.almamater.edu.example ESMTP server ready C: EHLO mail.wonder.land.example S: 250-mail.almamater.edu.example S: 250-DSN S: 250-AUTH S: 250 SIZE C: MAIL FROM: RET=HDRS ENVID=QRSTUV123 S: 250 sender ok C: RCPT TO: NOTIFY=SUCCESS S: 250 recipient ok C: DATA S: 354 okay, send message C: From: "Alice" C: To: "Uncle Bob" C: Sender: "W. Rabbit" C: Subject: Invitation to tea party C: Date: Sat, 16 Oct 2004 00:00:00 +0000 C: Message-ID: <123456789@wonder.land.example> C: (rest of message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye When message is received by almamater.edu.example SMTP server, it would add the following Received header field to the message: Received: from mail.wonder.land.example (mail.wonder.land.example [10.0.0.1]) by mail.almamater.edu.example (8.12.1/8.12.1) with ESMTP id ijklnmonpqrst for ; Sat, 16 Oct 2004 00:00:01 +0000 Based on user settings for account bob@almamater.edu.example (such as presence of .forward), the mail.almamater.edu.example must now forward this message to bob@company.com.example. The forwarding system therefore is changing RCPT TO envelope address, but does not change RFC2821 MAIL FROM (which is alice@wonder.land.example) or any header field. As such the following trace header field is added: Leibzon Expires November 2, 2005 [Page 12] Internet-Draft Email Redirection Trace Header May 2005 Redirected: by mail.almamater.edu.example (ip=[10.4.0.1]) on-behalf-of bob@almamater.edu.example process-type forwarding original-envelope recipient=bob@almamater.edu.example new-envelope recipient=bob@company.com.example, rcpt-orcpt="rfc2822;bob@almamater.edu.example" ; Sat, 16 Oct 2004 00:00:02 +0000 The message is now transmitted from mail.almameter.edu.example to mail.company.com.example and SMTP session might look like this: S: 220 mail.company.com.example ESMTP server ready C: EHLO mail.almamater.edu.example S: 250-mail.company.com.example S: 250-DSN S: 250-AUTH S: 250 SIZE C: MAIL FROM: RET=HDRS ENVID=QRSTUV123 S: 250 sender ok C: RCPT TO: NOTIFY=SUCCESS ORCPT=rfc2822;bob@almamater.edu.example S: 250 recipient ok C: DATA S: 354 okay, send message C: Redirected: by mail.almamater.edu.example (ip=[10.4.0.1]) C: on-behalf-of bob@almamater.edu.example C: process-type forwarding C: original-envelope recipient=bob@almamater.edu.example C: new-envelope recipient=bob@company.com.example, C: rcpt-orcpt="rfc2822;bob@almamater.edu.example" ; C: Sat, 16 Oct 2004 00:00:02 +0000 C: Received: from mail.wonder.land.example C: (mail.wonder.land.example [10.0.0.1]) C: by mail.almamater.edu.example (8.12.1/8.12.1) C: with ESMTP id ijklnmonpqrst1 C: for ; C: Sat, 16 Oct 2004 00:00:01 +0000 C: From: "Alice" C: To: "Uncle Bob" C: Sender: "W. Rabbit" C: Subject: Invitation to tea party C: Date: Sat, 16 Oct 2004 00:00:00 +0000 C: Message-ID: <123456789@wonder.land.example> C: (rest of message body goes here) C: . S: 250 message accepted C: QUIT Leibzon Expires November 2, 2005 [Page 13] Internet-Draft Email Redirection Trace Header May 2005 S: 221 goodbye 4.2 Mail List When Mr Rabbit is preparing the message that Alice has written for delivery to the mail list list@maillist.org.example the header of the new message might look like: From: "Alice" To: "The List" Sender: "W. Rabbit" Subject: News from the Wonderland! Date: Sat, 16 Oct 2004 00:00:00 +0000 Message-ID: <123456789@wonder.land.example> An original SMTP session from mail.wonder.land.example server might then look something like this: S: 220 maillist.org.example ESMTP server ready C: EHLO mail.wonder.land.example S: 250-maillist.org.example S: 250-DSN S: 250-AUTH S: 250 SIZE C: MAIL FROM: S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: From: "Alice" C: To: "The List" C: Sender: "W. Rabbit" C: Subject: News from the Wonderland! C: Date: Sat, 16 Oct 2004 00:00:00 +0000 C: Message-ID: <123456789@wonder.land.example> C: (rest of message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Leibzon Expires November 2, 2005 [Page 14] Internet-Draft Email Redirection Trace Header May 2005 When message is received by maillist.org.example incoming SMTP server, it would add the following Received header field to the message: Received: from mail.wonder.land.example (mail.wonder.land.example [10.0.0.1]) by mail.maillist.org.example (8.12.1/8.12.1) with ESMTP id ijklnmonpqrst2 for ; Sat, 16 Oct 2004 00:00:01 +0000 Mail list processing program is now run at maillist.org.example which adds Sender, Reply-To and Mail-List header fields, but before it does, the program checks if any of these fields are already present in the message and those that are found are copied over to become Original-*. In this message existing header field is Sender: "W. Rabbit" " and so to the top of the message the following is added Original-Sender: "W. Rabbit" Additional header field that is modified by mail list program is Subject, so original value is copied over to become header field Original-Subject: Original-Subject: News from the Wonderland! Leibzon Expires November 2, 2005 [Page 15] Internet-Draft Email Redirection Trace Header May 2005 Now mail list program is ready to add Redirected header field. To do that it also needs to know original envelope parameters values, which in some way should have been passed along from SMTP server to mail list program. It is also notable, that since mail list server is creating new message for multiple subscribers, it can not put all their names in the Redirect header field, so new value of SMTP recipient is not specified. In the end the message that leaves mail list processing program may look something like this: Redirected: by maillist.org.example (ip=[10.8.0.1]) on-behalf-of list@maillist.org.example process-type mail-list (list-id=) original-envelope return-path=alice@wonder.land.example, recipient=list@maillist.org.example new-envelope return-path=list@maillist.org.example, recipient changed-header Sender, Reply-To, List-ID, Subject ; Sat, 16 Oct 2004 00:00:02 +0000 Original-Sender: "W. Rabbit" Original-Subject: News from the Wonderland! Received: from mail.wonder.land.example (mail.wonder.land.example [10.0.0.1]) by mail.maillist.org.example (8.12.1/8.12.1) with ESMTP id ijklnmonpqrst2 for ; Sat, 16 Oct 2004 00:00:01 +0000 Reply-To: list@maillist.org.example From: "Alice" To: "The List" Subject: [list] News from the Wonderland! Date: Sat, 16 Oct 2004 00:00:00 +0000 Message-ID: <123456789@wonder.land.example> Sender: List-ID: After mail list processing program completes, it then passes the message to local MTA for further delivery. MTA program at the time of delivery adds additional Received header field which can now be different for each recipient the message is sent to. In this case the message goes to bob@company.com.example and so the following Received header field is added: Received: from localhost (localhost [127.0.0.1]) by mail.maillist.org.example for ; Sat, 16 Oct 2004 00:00:03 +0000 Leibzon Expires November 2, 2005 [Page 16] Internet-Draft Email Redirection Trace Header May 2005 Note: Mail list software program that has better integration with SMTP Server (or one that prepares each email message separately for MTA) would want to directly add "recipient" address as part of "new- envelope" parameter of Redirected header field and probably would not add another Received trace header field on top of that. The message is now transmitted from mail.maillist.org.example to mail.company.com.example and SMTP session might look like this: Leibzon Expires November 2, 2005 [Page 17] Internet-Draft Email Redirection Trace Header May 2005 S: 220 company.com.example ESMTP server ready C: EHLO mail.maillist.org.example S: 250-company.com.example S: 250-DSN S: 250-AUTH S: 250 SIZE C: MAIL FROM: S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Received: from localhost (localhost [127.0.0.1]) C: by mail.maillist.org.example C: for ; C: Sat, 16 Oct 2004 00:00:03 +0000 C: Redirected: by maillist.org.example (ip=[10.8.0.1]) C: on-behalf-of list@maillist.org.example C: process-type mail-list C: (list-id=) C: original-envelope return-path=alice@wonder.land.example, C: recipient=list@maillist.org.example C: new-envelope return-path=list@maillist.org.example, C: recipient C: changed-header Sender, Reply-To, List-ID, Subject ; C: Sat, 16 Oct 2004 00:00:02 +0000 C: Original-Sender: "W. Rabbit" C: Original-Subject: News from the Wonderland! C: Received: from mail.wonder.land.example C: (mail.wonder.land.example [10.0.0.1]) C: by mail.maillist.org.example (8.12.1/8.12.1) C: with ESMTP id ijklnmonpqrst2 C: for ; C: Sat, 16 Oct 2004 00:00:01 +0000 C: Reply-To: list@maillist.org.example C: From: "Alice" C: To: "The List" C: Subject: [list] News from the Wonderland! C: Date: Sat, 16 Oct 2004 00:00:00 +0000 C: Message-ID: <123456789@wonder.land.example> C: Sender: C: List-ID: C: (rest of message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Leibzon Expires November 2, 2005 [Page 18] Internet-Draft Email Redirection Trace Header May 2005 4.3 Automated SMTP Redirection Alice on a trip through Looking Glass can not find Mr Rabbit to deliver her messages and when she asks Red Queen to help and she gives Alice as a gift email mobile access device. The device would normally send email through local mail server in Looking Glass and is per-configured with its name for submitting finished email, but the device does support roaming and works in other places. So having mastered use of this device Alice no longer needs help of Mr Rabbit and on her next visit to Wonderland uses roaming capabilities to send email through Wonderland local mobile service provider WonderMobile. For security reasons WonderMobile does not allow roaming and guest users to connect to remote SMTP servers and redirects all SMTP connections to its own SMTP proxy server. When email is being sent from this mobile device, the message header fields are as follows: From: "Alice" To: "Uncle Bob" Subject: I'm back in Wonderland Date: Mon, 18 Oct 2004 00:00:00 +0000 Mobile device tries to establish SMTP session for submitting this email to mail.lgmobile.looking-glass.example but its caught by proxy, and SMTP session is established to mail.wondermobile.land.example: S: 220 mobile-123.wondermobile.land.example ESMTP server ready C: EHLO mobile-proxy.wondermobile.land.example S: 250-mobile-123.wondermobile.land.example S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=alice@wonder.land.example S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: From: "Alice" C: To: "Uncle Bob" C: Subject: I'm back in Wonderland C: Date: Mon, 18 Oct 2004 00:00:00 +0000 C: (rest of message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Leibzon Expires November 2, 2005 [Page 19] Internet-Draft Email Redirection Trace Header May 2005 An email proxy server mobile-proxy.wondermobile.land.example first adds Received header field as follows: Received: from mobile-123.wondermobile.land.example (mobile-123.wondermobile.land.example [10.10.3.123]) by mobile-proxy.wondermobile.land.example (8.12.1/8.12.1) with ESMTP id ijklnmonpqrst3 for ; Mon, 18 Oct 2004 00:00:01 +0000 The proxy server then adds its own Sender header field to identify the email as having been sent by means of this proxy (since there was no Sender header in the email before, Original-Sender header is not added) and it adds Redirected header field to identify that redirection took place: Redirected: by mobile-proxy.wondermobile.land.example (ip=[10.10.2.1]) on-behalf-of proxy@wondermobile.land.example process-type smtp-proxy original-envelope mail-submitter=alice@wonder.land.example new-envelope mail-submitter=proxy@wondermobile.land.example changed-header Sender ; Mon, 18 Oct 2004 00:00:02 +0000 Leibzon Expires November 2, 2005 [Page 20] Internet-Draft Email Redirection Trace Header May 2005 The SMTP session from mobile-proxy.wondermobile.land.example to mail.almamater.edu.example would now look like this: S: 220 mail.almamater.edu.example ESMTP server ready C: EHLO mobile-proxy.wondermobile.land.example S: 250-mail.almamater.edu.example S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=proxy@wondermobile.land.example S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Redirected: by mobile-proxy.wondermobile.land.example C: (ip=[10.10.2.1]) C: on-behalf-of proxy@wondermobile.land.example C: process-type smtp-proxy C: original-envelope mail-submitter=alice@wonder.land.example C: new-envelope mail-submitter=proxy@wondermobile.land.example C: changed-header Sender ; Mon, 18 Oct 2004 00:00:02 +0000 C: Sender: proxy@wondermobile.land.example C: Received: from mobile-123.wondermobile.land.example C: (mobile-123.wondermobile.land.example [10.10.3.123]) C: by mobile-proxy.wondermobile.land.example (8.12.1/8.12.1) C: with ESMTP id ijklnmonpqrst3 C: for ; C: Mon, 18 Oct 2004 00:00:01 +0000 C: From: "Alice" C: To: "Uncle Bob" C: Subject: I'm back in Wonderland C: Date: Mon, 18 Oct 2004 00:00:00 +0000 C: (rest of message body goes here) C: . S: 250 message accepted Leibzon Expires November 2, 2005 [Page 21] Internet-Draft Email Redirection Trace Header May 2005 5. IANA Considerations IANA is herewith requested to register the Redirected header field in the Message Header Fields Registry as follows: --------------------------------------------------------------------- Header field name: Redirected Applicable protocol: mail Status: standard Author/Change controller: William Leibzon, william@elan.net Specification document(s): Internet-Draft draft-leibzon-emailredirection-traceheaders-01.txt (Note to RFC Editor: replace above with RFC YYYY if document becomes an RFC) Related information: none --------------------------------------------------------------------- Original-* and Saved-* also need to be registered and listed separately in IANA directory as general prefix. Separate document will be used to provide more details and register these header fields with IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Leibzon Expires November 2, 2005 [Page 22] Internet-Draft Email Redirection Trace Header May 2005 6. Security Considerations Use of Redirection header field may expose to the public certain email addresses that otherwise would have stayed hidden as intermediate steps in email transmission. Mail agents should use caution in this regard when deciding when and how Redirected header field is added so it does not compromise security of the email system. Redirection header field by itself does not provide reliable means of verification that email redirection and forwarding really took place as described and its possible for some SMTP system to forge this header field in the email being sent, possibly in order to make it appear that another system may have been original source of the email message. As such any information in this header field can only be relied upon if some other form of authentication of the system that added the header is available, such as if SMTP Server can verify SMTP Client system based on its ip address, it can then trust information added by the SMTP Client in trace headers to be valid. For systems, that are more then one SMTP hop away and where direct SMTP session transmission verification is not possible, the authentication should be done by means of cryptographic email signatures and Redirected and all other related header fields should be included as part email signature data. Leibzon Expires November 2, 2005 [Page 23] Internet-Draft Email Redirection Trace Header May 2005 7. Acknowledgements The author would also like to thank participants of the IETF MARID working group and SPF-discuss mail list for valuable feedback that has been used in writing this document. Leibzon Expires November 2, 2005 [Page 24] Internet-Draft Email Redirection Trace Header May 2005 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001. [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004. 8.2 Informative References [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [responsible-submitter] Leibzon, W., "Responsible Submitter of an Email Message", October 2004, . Author's Address William Leibzon Elan Networks 500 Laurelwood Rd, Suite 12 Santa Clara, CA 95054 USA Email: william@elan.net URI: http://www.elan.net/~william/emailsecurity/ Leibzon Expires November 2, 2005 [Page 25] Internet-Draft Email Redirection Trace Header May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Leibzon Expires November 2, 2005 [Page 26]