Network Working Group W. Leibzon Internet Draft Elan Networks Document: draft-leibzon-emailredirection-traceheaders-00.txt Expires: May 2005 November 2004 Email Forwarding and Redirection Trace Headers Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. [STD] Internet-Drafts are working documents of 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo defines Redirected email trace header 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 - May 2005 [Page 1] Email Redirection Trace Headers November 2004 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 RFC-2119 [KEYWORDS]. Table of Contents 1. Introduction...................................................3 2. Redirected Email Header........................................3 2.1 Syntax of Redirected Header................................4 2.2 Required data in Redirected header.........................4 2.2.1 On-behalf-of parameter.................................5 2.2.2 Process-type parameter.................................5 2.3 Recording email envelope changes...........................5 2.4 Recording list of changed headers..........................7 3. Original-* and New-* headers...................................7 4. Examples.......................................................8 4.1 Mail Forwarding............................................9 4.2 Mail List.................................................11 4.3 Automated SMTP Redirection................................14 5. Security Considerations.......................................16 6. IANA Considerations...........................................16 7. References....................................................17 7.1 Normative References......................................17 7.2 Informative References....................................17 8. Acknowledgments...............................................17 9. Author's Address..............................................17 10. Full Copyright Statement.....................................18 Leibzon Expires - May 2005 [Page 2] Email Redirection Trace Headers November 2004 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 it received 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 which automated email forwarding and redirection systems may use to record changes done by them to email message. Additionally "Original-*" and "New-*" headers are also defined to allow these systems to record original and new values of those headers that may have been changed by them. 2. Redirected Email Header "Redirected:" email header MUST be added by email processing systems that change destination or source of an email message while its 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 MUST be used to provide information about type of email processing that occurred and email address of the party responsible for initiating email redirection. Further the header MUST include information about which email transmission RFC2821 parameters and/or RFC2822 headers are changed by redirection agent. Please 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 headers for this purpose. In case of manual forwarding if original headers 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-* headers to to specify new email source and recipient information as described in section 3.6.6 of [MSG-FORMAT]. Leibzon Expires - May 2005 [Page 3] Email Redirection Trace Headers November 2004 2.1 Syntax of Redirected Header The ABNF 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 [MSG-FORMAT] and domain and address-literal are defined in [SMTP]. 2.2 Required data in Redirected header Redirected header should start with information about system adding the header. 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 once 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]) After the system information follow redirection data parameters and two of them are required and its preferable that they be added immediately after system information data. Leibzon Expires - May 2005 [Page 4] Email Redirection Trace Headers November 2004 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. 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 and 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, that RCPT TO address can be used with 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 [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. There are three possible values that may be used - "forwarding", "mail-list" and "smtp-proxy". Please note that new types require explicit definition by IETF documents and 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 as in: process-type mail-list (list-id=) 2.3 Recording email envelope changes Email envelope is [SMTP] 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 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. Leibzon Expires - May 2005 [Page 5] Email Redirection Trace Headers November 2004 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 used in "MAIL FROM" and "RCPT TO" SMTP commands [SMTP] and other addresses associated with source or destination such as ORCPT parameter of RCPT command [SMTP-DSN] and SUBMITTER parameter of MAIL command [SUBMITTER]. Changes to other message identification parameters such as ENVID parameter of MAIL [SMTP-DSN] 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 by the processing done by redirection agent (this 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 item name used is determined 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 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 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. 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 should then be recorded directly by SMTP server (rather then mail list processing program) by means of "for" clause of Received header. Leibzon Expires - May 2005 [Page 6] Email Redirection Trace Headers November 2004 2.4 Recording list of changed headers In addition to modifying SMTP envelope data, most redirection agents also modify existing headers or add new headers to email message (and there are even some redirection agents that only add or modify source or destination headers without actually changing envelope). Consequently Redirected header offers a way that MRAs can report which headers were changed by means of "changed-headers" parameter. While there are number of headers used in email messages, for tracking email routing changes done by MRAs of most interest are those headers that specify source or destination information or other message identification data. The following is partial list and brief description of such headers with information on which document describes how header is used in more detail: To: - Primary recipient mailbox, see [MSG-FORMAT] Cc: - Carbon-copy recipient mailbox, see [MSG-FORMAT] From: - Mailbox of message author, see [MSG-FORMAT] Sender: - Mailbox of message sender, see [MSG-FORMAT] Reply-To: - Mailbox for replies to message, see [MSG-FORMAT] Message-ID: - Message identifier, see [MSG-FORMAT] List-ID: - Mail list identifier, see [LIST-ID] If changes are made to above headers by MRA, this SHOULD be recorded by means of Redirected header. Missing from above list are some headers that include message source or destination information but where existing instances of the headers are not supposed to be modified by subsequent email servers, but instead new instances are added to the beginning of the message. These headers including all trace headers like Received and Return- Path as well as all Resent-* headers are not supposed to be included in Redirected "changed-headers" parameter when new header is added. For other headers even if header is not related to message source or destination, if the header value is modified by retransmission agent, it MAY also be listed in Redirected "changed-headers" parameter. When listing headers following "changed-headers" parameter keyword, it should consist only of list of header names separated from each other by "," but not values of the headers. Unlike envelope data, values of changed headers are reported as separate headers as described in the next section of this document. 3. Original-* and New-* headers When header of an email message is modified or replaced by MRA as described in section 2.4 of this document, then original value of the header SHOULD be preserved by taking entire header and adding "Original-" before its name and them putting this new header right below corresponding Redirected header. Note that list of headers in "changed-headers" may include larger set of headers then what can be Leibzon Expires - May 2005 [Page 7] Email Redirection Trace Headers November 2004 preserved by means of Original- headers since changed-headers list also includes some headers that are newly added by Redirection agent. Additionally new value of header that has been changed or added by redirection agent and listed in the "changed-headers" parameter of Redirected header MAY also be saved for debugging purposes by means of New-* header. The process is the same as with Original-* header and involves taking entire header and adding "New-" before its name and putting this new header below Redirected. If both Original-* and New-* headers are added then New-* headers SHOULD be placed above Original-* headers and immediately above all added New-* headers MUST be Redirected header. If redirection agent is also adding Received header then Received SHOULD be added below the Original-* headers (but in some cases as described in section 2.3 adding extra Received header above Redirected may also be appropriate) Please note that Original-* headers can also be added by systems that do not add Redirected header at the same time. The meaning of the header must however be the same and represent value of the header at the earlier stage of email transmission. 4. Examples This section provides examples of how Redirected and corresponding Original-* and New-* headers 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 has 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 Leibzon Expires - May 2005 [Page 8] Email Redirection Trace Headers November 2004 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 headers 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> 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 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 ijklnmonpqrst1 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 Leibzon Expires - May 2005 [Page 9] Email Redirection Trace Headers November 2004 system therefore is changing RCPT TO envelope address but does not change RFC2821 MAIL FROM (which is alice@wonder.land.example) or any headers. As such the following trace header is added: 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 (mail.wonder.land.example C: [10.0.0.1]) by mail.almamater.edu.example (8.12.1/8.12.1) C: with ESMTP id ijklnmonpqrst1 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 S: 221 goodbye Leibzon Expires - May 2005 [Page 10] Email Redirection Trace Headers November 2004 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 headers 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 When message is received by maillist.org.example incoming SMTP server, it would add the following Received header 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 needs to add Sender, Reply-To and Mail-List headers, but before it does, the program checks if any of these headers are already present Leibzon Expires - May 2005 [Page 11] Email Redirection Trace Headers November 2004 in the message and those that are found are copied over to become Original-*. In this message existing header is Sender: "W. Rabbit" " and so to the top of the message the following is added: Original-Sender: "W. Rabbit" Additional header that is modified by mail list program is Subject, so original value is copied over to become header Original-Subject: Original-Subject: News from the Wonderland! Now mail list program is ready to add Redirected header, 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, 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-headers 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 which can now be different for each recipient the message is sent to. In this example the message goes to bob@company.com.example and so the following Received header is added: Received: from localhost (localhost [127.0.0.1]) by mail.maillist.org.example for ; Sat, 16 Oct 2004 00:00:03 +0000 Note: Mail list software program that has better integration with Leibzon Expires - May 2005 [Page 12] Email Redirection Trace Headers November 2004 SMTP Server (or one that prepares each email message separately for MTA) would want to directly add "recipient" address as part of "new- envelope" of Redirected header and probably would not add another Received trace header 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: 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 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 (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, recipient C: changed-headers 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 (mail.wonder.land.example C: [10.0.0.1]) by mail.maillist.org.example (8.12.1/8.12.1) C: with ESMTP id ijklnmonpqrst2 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 - May 2005 [Page 13] Email Redirection Trace Headers November 2004 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 emails through local mail server in Looking Glass and is pre-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 headers 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 An email proxy server mobile-proxy.wondermobile.land.example first adds Received header as follows: Leibzon Expires - May 2005 [Page 14] Email Redirection Trace Headers November 2004 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 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 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-headers Sender ; Mon, 18 Oct 2004 00:00:02 +0000 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]) 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-headers 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 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 - May 2005 [Page 15] Email Redirection Trace Headers November 2004 7. Security Considerations Redirection header by itself does not provide reliable means of verification that email redirection and forwarding really took place as described by the header and its possible for some SMTP system to forge this header 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 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 more then one SMTP hop away where direct SMTP session transmission verification is not possible, the authentication should be done by means of cryptographic email signatures. 8. IANA Considerations IANA is herewith requested to register the Redirected header in the Message Header Fields Registry as follows: --------------------------------------------------------------------- Header field name: Redirected Applicable protocol: Email (RFC2821, RFC2822) Status: provisional (Note to RFC Editor: Replace this with "standard") Author/Change controller: William Leibzon, william@elan.net (Note to RFC Editor: Replace this with "IETF" in the future) Specification document(s): Internet-Draft draft-leibzon-emailredirection-traceheaders-00.txt (Note to RFC Editor: Replace this with RFC YYYY if document achieves RFC status) Related information: none --------------------------------------------------------------------- Original-* and New-* will also need to be registered and listed separately in IANA directory unless way is found to register general "Prefix" for headers as reference to existing headers. Leibzon Expires - May 2005 [Page 16] Email Redirection Trace Headers November 2004 9. References 9.1 Normative References [ABNF] Crocker, D. and R. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LIST-ID] Chandhok, R. and Wenger G., "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC2919, March 2001 [MSG-FORMAT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [STD] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 9.2 Informative References [SMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC3461, January 2003 [SUBMITTER] Leibzon, W., "Responsible Submitter of an Email Message", draft-leibzon-responsible-submitter-00 (work in progress), October 2004 10. Acknowledgments 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. 11. Author's Address William Leibzon Elan Networks 500 Laurelwood Rd, Suite 12 Santa Clara, CA 95054, USA E-mail: william@elan.net Leibzon Expires - May 2005 [Page 17] Email Redirection Trace Headers November 2004 12. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 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. Intellectual Property 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Leibzon Expires - May 2005 [Page 18]