Network Working Group W. Leibzon Internet Draft Elan Networks Document: draft-leibzon-responsible-submitter-00.txt Expires: April 2005 October 2004 Responsible Submitter of an E-mail Message 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 an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. Leibzon Expires - April 2005 [Page 1] Responsible Submitter of an E-mail Message October 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. The SUBMITTER Service Extension................................4 3. The SUBMITTER Keyword of the EHLO Command......................4 4. The SUBMITTER Parameter of the MAIL Command....................4 4.1 Setting the SUBMITTER Parameter Value......................4 4.2 Processing the SUBMITTER Parameter.........................5 5. Authorizing Use of Responsible Submitter Address...............5 5.1 Publishing DNS Authorization Records.......................6 5.2 Checking DNS Authorization Records.........................6 5.3 Interpreting the Results of SPF Verification...............6 5.3.1 None..................................................7 5.3.2 Neutral...............................................7 5.3.3 Pass..................................................7 5.3.4 Fail..................................................7 5.3.5 SoftFail..............................................7 5.3.6 TempError.............................................8 5.3.5 PermError.............................................8 5.4. Saving Verification Results...............................8 5.4.1 Displaying Verification Results in MUA.................8 6. Examples.......................................................9 6.1 Mail Submission............................................9 6.2 Mail Forwarding...........................................10 6.3 Mail List.................................................11 6.4 Mobile User...............................................12 6.5 Guest E-mail Service......................................13 6.6 SUBMITTER Used on a Non-Delivery Report...................13 7. Security Considerations.......................................14 7.1 DNS Attacks...............................................14 7.2 TCP Attacks...............................................14 7.3 Address Space Hijacking...................................15 8. IANA Considerations...........................................15 9. References....................................................16 9.1 Normative References......................................16 9.2 Informative References....................................16 10. Acknowledgments..............................................17 11. Author's Address.............................................17 12. Full Copyright Statement.....................................18 Leibzon Expires - April 2005 [Page 2] Responsible Submitter of an E-mail Message October 2004 1. Introduction The practice of falsifying the identity of the sender of an e-mail message, commonly called "spoofing", is a prevalent tactic used by senders of unsolicited commercial e-mail or "spam". This form of abuse has highlighted the need to improve identification of the "responsible submitter" of an e-mail message. This document solves the problem by introducing Responsible Submitter email parameter which SMTP client can use to specify email address of the entity most recently responsible for injecting a message into the e-mail transport stream. This parameter and verification mechanisms of this document allow one to answer the following question: When a message is transferred via SMTP between two UNRELATED parties, does the SMTP client host have permission to send mail on behalf of the mailbox that allegedly caused the most recent introduction of the message into the mail delivery system? As seen from the question, this mechanism applies to unrelated parties: it is useful at the point where a message passes across the Internet from one organization to another. It is beyond the scope of this document to describe authentication mechanisms that can be deployed within an organization. This specification uses mechanism described in [SMTP] to describe an extension to the SMTP protocol. Using this extension, an SMTP client can specify the e-mail address of the entity most recently responsible for submitting the message to the SMTP client in a new SUBMITTER parameter of the SMTP MAIL command. SMTP servers can use this information to verify that the SMTP client is authorized to transmit e-mail on behalf of the Internet domain contained in the SUBMITTER parameter. As specified above, the verification mechanisms of this document seeks to authenticate the mailbox associated with the MOST RECENT introduction of a message into the mail delivery system. In simple cases, this is who the mail is from. However, in the case of a third-party mailer, a forwarder or a mailing list server, the address being authenticated is that of the third party, the forwarder or the mailing list. This document provides means to authenticate the DOMAIN of the appropriate email address; it is not directed at the local-part. A domain owner gets to determine which SMTP clients speak on behalf of addresses within the domain; a responsible domain owner should not authorize SMTP clients that will lie about local parts. Leibzon Expires - April 2005 [Page 3] Responsible Submitter of an E-mail Message October 2004 2. The SUBMITTER Service Extension The following SMTP service extension is hereby defined: (1) The name of this SMTP service extension is "Responsible Submitter"; (2) The EHLO keyword value associated with this extension is "SUBMITTER"; (3) The SUBMITTER keyword has no parameters; (4) No additional SMTP verbs are defined by this extension; (5) An optional parameter is added to the MAIL command using the esmtp-keyword "SUBMITTER", and is used to specify the e-mail address of the entity responsible for submitting the message for delivery; (6) This extension is appropriate for the submission protocol [SUBMIT]. 3. The SUBMITTER Keyword of the EHLO Command An SMTP server includes the SUBMITTER keyword in its EHLO response to tell the SMTP client that the SUBMITTER service extension is supported. The SUBMITTER keyword has no parameters. 4. The SUBMITTER Parameter of the MAIL Command The syntax of the SUBMITTER parameter is: "SUBMITTER=" Mailbox where Mailbox is the ABNF [ABNF] production defined in Section 4.1.2 of [SMTP]. Characters such as SP, "+" and "=" which may occur in Mailbox but are not permitted in ESMTP parameter values MUST be encoded as "xtext" as described in section 4 of [DSN]. 4.1 Setting the SUBMITTER Parameter Value The purpose of the SUBMITTER parameter is to allow the SMTP client to indicate to the server the address of the entity most recently responsible for injecting a message into the e-mail transport stream. In case of email submission by end-user this address can be found in "Sender:" header since RFC2822 specifies that Sender header represents Leibzon Expires - April 2005 [Page 4] Responsible Submitter of an E-mail Message October 2004 "agent responsible for actual transmission of the message" and if Sender is not present then responsible party is email author listed in "From:" header. In case of email list, the responsible party is mail list and the address should be that of email list itself. In case of forwarding service, the address should be that of the forwarding agent or that of a user of that forwarding agent, whose settings caused email retransmission. SMTP servers which are involved in retransmission of the message but which do not cause change in the direction of SMTP transmission SHOULD use SUBMITTER value they received during incoming SMTP transmission as value for outgoing SMTP transmission. If there was no SUBMITTER MAIL parameter during incoming transmission, then SMTP server MUST NOT use SUBMITTER for outgoing transmission unless it can find email address of the entity which last caused introduction of a message into the email delivery system by other means. An SMTP client that supports the Responsible Submitter extension and that can set Responsible Submitter value MUST include the SUBMITTER parameter on all messages. This includes messages containing a null reverse-path in the MAIL command. 4.2 Processing the SUBMITTER Parameter Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD perform such tests, including those defined in section 5 of this document, as are deemed necessary to determine whether the connecting SMTP client is authorized to transmit e-mail messages on behalf of the domain part of the SUBMITTER address. If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed." Note that the presence of the SUBMITTER parameter on the MAIL command MUST NOT change the effective reverse-path of a message. Any delivery status notifications must be sent to the reverse-path, if one exists, as per section 3.7 of [SMTP] regardless of the presence of a SUBMITTER parameter. If the reverse-path is null, delivery status notifications MUST NOT be sent to the SUBMITTER address. 5. Authorizing Use of Responsible Submitter Address Responsible Submitter provides information regarding party most recently responsible for introduction of the message into email transport stream. When such information is transmitted to an SMTP server of different organization, to be able to rely on this information, there needs a way that such server can confirm that address used does indeed belong to the party that is affiliated with most recent introduction of the message. Such affiliation Leibzon Expires - April 2005 [Page 5] Responsible Submitter of an E-mail Message October 2004 can be confirmed by means of the SPF dns lookup on the domain part of the Responsible Submitter email address as found in SUBMITTER parameter. SPF protocol [SPF-PROTOCOL] describes a system that allows domain owner to publish email policy records that can be used to confirm such affiliation and confirm if SMTP Client is allowed to use given domain as part of its email transmission parameters. 5.1 Publishing DNS Authorization Records Domains that are used as part of the Responsible Submitter address SHOULD publish SPF DNS Authorization records that allow to verify ip addresses of hosts that are authorized to use given domain when setting SUBMITTER parameter. SPF records used for publishing this information MUST use "submit" scope identifier. Domains SHOULD publish SPF records that end in "-all" or redirect to other records that do, so that a definitive determination of authorization can be made. An example of SPF authorization record for domain example.com that allows to use this domain in Responsible Submitter email address by all servers and clients located in 192.168.0.0/16 ip block is: example.com. IN SPF "SPF2.0/submit +ip4:192.168.0.0/16 -all" 5.2 Checking DNS Authorization Records For an SMTP Server to test authorization of SMTP Client to use certain domain as part of the SUBMITTER parameter, the SMTP Server MUST evaluate the results of check_host() function as defined in [SPF-PROTOCOL] with arguments as follows: - the "submit" scope identifier - the ip address of the SMTP client host - the domain portion of the SUBMITTER parameter - the full email address in SUBMITTER parameter If SMTP Client provided SUBMITTER argument to MAIL command then SMTP Client SHOULD perform authorization check during the time of SMTP transaction. The check can be performed directly at the time of MAIL command or it may be easier to delay the check to later stage of SMTP transmission. 5.3 Interpreting the Results of SPF Verification The check_host() function of SPF verification can return one of seven result as a outcome of verification attempt and may also return additional information (such as "explanation string"). This section describes how software performing authorization should interpret these results. Leibzon Expires - April 2005 [Page 6] Responsible Submitter of an E-mail Message October 2004 5.3.1 None This is a result if no SPF records for "submit" scope were published for domain. No conclusion can be made if SMTP Client is authorized or not. An SMTP server receiving one of these results SHOULD NOT reject the message for this reason alone, but MAY subject the message to heightened scrutiny by other email security measures, and MAY reject the message as a result of this heightened scrutiny. 5.3.2 Neutral The Neutral result MUST be treated exactly like a None result. 5.3.2 Pass A Pass result means the client is authorized to use the domain as part of Responsible Submitter address. An SMTP server receiving this result SHOULD treat the message as authentic, but may still want to test other parameters of email message and may accept or reject the message depending on results of these tests and based on other policies 5.3.4 Fail A Fail result means the client IS NOT authorized to use the domain as part of Responsible Submitter Address. An SMTP server receiving this result SHOULD NOT accept email and when doing so MUST use 550 reply code to indicate that email is rejected (see section 4.2 of this document). Note that SPF check may provide an "explanation string" as part of its result and such string may contain a URL. This explanation comes from the domain that published SPF record and if SMTP Server wants use this explanation string when constructing 550 rejection message, then SMTP Server must caution the user that this text is not trusted. Example of reply message when SPF authorization failed is as follows: 550-5.7.1 Submitter not allowed - SPF verification failed 550-The domain example.com said: 550 Please see http://www.example.com/mailpolicy.html 5.3.5 SoftFail A result of SoftFail should be treated as somewhere between Fail and Neutral. This value is used by domains as intermediate state during roll-out of publishing records. The domain believes the host isn't authorized but is not willing to make that strong of a statement. SMTP Servers SHOULD NOT reject the message based on this result alone but MAY subject the message to closer scrutiny and run other tests to verify message transmission is authorized and MAY reject the message depending on results of these tests and based on other policies. Leibzon Expires - April 2005 [Page 7] Responsible Submitter of an E-mail Message October 2004 5.3.6 TempError A result of TempError means that there was encountered transient error while performing the check. SMTP Server can choose to accept or temporarily reject the message. If the server chooses to accept the message, it must treat it as if the result was None. If the SMTP server is rejecting the message then it MUST use reply code of 450 to indicate temporary error. 5.3.7 PermError A result of PermError means that domain's published records could not be correctly interpreted. SMTP Server may choose to reject the message with 550 reply code or may choose to accept the message based on its policies and based on verification of other parameters of the message. This result should be treated similar to SoftFail but it is acceptable to reject the message based on this result along if no other information regarding the message can be verified. 5.4. Saving Verification Results In order to preserve results of SPF verification and the value of Responsible Submitter at the time of verification, SMTP servers SHOULD add Authentication-Results header as defined in [AUTH-STATUS]. In Authentication-Results header, the authentication type is SPF with SPF authentication method "spf/submit". The value of SUBMITTER should be added to the list of identity headers (they follow the name of the system doing authentication) as header "envelope-submitter". The same address should also be entered in the commentary part of "spf/submit" as information parameter "auth-name". Example of Authentication-Results header is as follows: Authentication-Results: test-system.example.com from=user@example.com envelope-submitter=user@example.com ; SPF=pass (auth-ip=10.0.0.10 SPF/submit=pass (auth-name=user@example.com)) 5.4.1 Displaying Verification Results in MUA When displaying a received message, an MUA SHOULD check message for Authentication-Results headers and if last entered such header is proceeded only by Received and Return-Path trace headers which appear to have been added by MDA or by other MTAs which are known to be on the same network as MUA, then MUA should display the value of Responsible Submitter as found in "envelope-submitter" as well as display to the user the results of SPF verification. If email address of Responsible Submitter is the same as address in one of the "From:" headers, then MUA should show that email address Leibzon Expires - April 2005 [Page 8] Responsible Submitter of an E-mail Message October 2004 as email origin and indicate by some means that it has been SPF- verified based on submitter identity. If header "From:" address is not the same, then origin of the email should be indicated as being that of Responsible Submitter with email listed as having been sent on behalf of the party listed in "From:" header. It should be made clear that only Responsible Submitter part of the email origin has been SPF-verified and not the header "From:" address part. MUA may also want to find envelope-submitter values from all "Authentication-Results:" headers as well as "Sender:" and all "From:" headers and display them as addresses responsible for transmission of the message. 6. Examples This section provides examples of how the SUBMITTER parameter would be used. The following dramatic personae appear in the examples: alice@example.com: the original sender of each e-mail message 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 alice@mobile.net.example: an e-mail account provided to Alice by her mobile e-mail network carrier list@maillist.org.example: a mail list which both Bob and Alice are subscribed to 6.1 Mail Submission Under normal circumstances, Alice would configure her MUA to submit her message to the mail system using the SUBMIT protocol [SUBMIT]. The MUA would transmit the message without the SUBMITTER parameter. The SUBMIT server would validate that the MUA is allowed to submit a message through some external scheme, perhaps SMTP Authentication [SMTPAUTH]. The SUBMIT server would then extract her address from the RFC 2822 header "Sender" or if it missing then out of first "From:" header and it would set SUBMITTER parameter to this address for subsequent transmissions of the message. Note that setting SUBMITTER parameter based on values of "Sender" and "From" header should be done ONLY if SMTP Server is certain that mail submission is taking place, i.e. if either SUBMIT protocol is used or if SMTP protocol with SMTP authentication [SMTPAUTH] is used. Leibzon Expires - April 2005 [Page 9] Responsible Submitter of an E-mail Message October 2004 6.2 Mail Forwarding When Alice sends a message to Bob's almamater.edu.example account, SMTP session from her SUBMIT server might look something like this: S: 220 almamater.edu.example ESMTP server ready C: EHLO example.com S: 250-almamater.edu.example S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=alice@example.com S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: (message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye The almamater.edu.example MTA must now forward this message to bob@company.com.example. Although the original sender of the message is alice@example.com, Alice is not responsible for this most recent retransmission of the message. That role is filled by bob@almamater.edu.example who established the forwarding of mail to bob@company.com.example. Therefore for almamater.edu.example MTA a new message responsible submitter is bob@almamater.edu.example, and it sets the SUBMITTER parameter accordingly. S: 220 company.com.example ESMTP server ready C: EHLO almamater.edu.example S: 250-company.com.example S: 250-DSN S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=bob@almamater.edu.example S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Received By: ... C: (message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Leibzon Expires - April 2005 [Page 10] Responsible Submitter of an E-mail Message October 2004 6.3 Mail List When Alice sends a message to list@maillist.org.example, an original SMTP session from her SUBMIT server might look something like this: S: 220 maillist.org.example ESMTP server ready C: EHLO example.com S: 250-maillist.org.example S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=alice@example.com S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: (message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye The mail list software run at maillist.org.example must now forward this message to all mail list subscribers including Bob. Mail list is now responsible for new introduction of the message into email delivery. Therefore for maillist.org.example MTA a new message responsible submitter is mail list address list@maillist.org.example, and it sets the SUBMITTER parameter accordingly. The following shows how SMTP session of maillist sending the message to its subscriber bob@company.com.example might look like: S: 220 company.com.example ESMTP server ready C: EHLO maillist.org.example S: 250-company.com.example S: 250-DSN S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=list@maillist.org.example S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Received By: ... C: (message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Leibzon Expires - April 2005 [Page 11] Responsible Submitter of an E-mail Message October 2004 6.4 Mobile User Alice is at the airport and uses her mobile e-mail device to send a message to Bob. The message travels through the carrier network provided by mobile.net.example, but Alice uses her example.com address on the From line of all her messages so that replies go to her office mailbox. Here is an example of the SMTP session between the MTAs at consolidatedmessanger.net and almamater.edu.example. S: 220 almamater.edu.example ESMTP server ready C: EHLO mobile.net.example S: 250-almamater.edu.example S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=alice@mobile.net.example S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Sender: alice@mobile.net.example C: Received By: ... C: (message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Note that mobile.net.example uses the SUBMITTER parameter to designate alice@mobile.net.example as the responsible submitter for this message. Further this MTA also inserts a Sender header as required by RFC2822 to show that alice@mobile.net is the actual agent responsible for this email transmission. Likewise, conventional ISPs may also choose to use the SUBMITTER parameter to designate as the responsible submitter the user's address on the ISP's network if that address is different from the MAIL FROM address. When the message is subsequently forwarded by the almamater.edu.example MTA, that MTA will replace the SUBMITTER parameter with bob@almamater.edu.example as in section 6.2 and add new Submitted-By header to indicate email forwarding by MTA. Leibzon Expires - April 2005 [Page 12] Responsible Submitter of an E-mail Message October 2004 6.5 Guest E-mail Service While on a business trip, Alice uses the broadband access facilities provided by the Exemplar Hotel to connect to the Internet and send e- mail. The hotel routes all outbound e-mail through its own SMTP server, email.hotel.com.example. The SMTP session for Alice's message to Bob from the Exemplar Hotel would look like this: S: 220 almamater.edu.example ESMTP server ready C: EHLO email.hotel.com.example S: 250-almamater.edu.example S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=guest.services@email.hotel.com.example S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Sender: guest.services@email.hotel.com.example C: Received By: ... C: (message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye Note that email.hotel.com.example uses the SUBMITTER parameter to designate a generic account guest.services@email.hotel.com.example as the responsible submitter address for this message. A generic account is used since Alice herself does not have an account at that domain. Furthermore email.hotel.com.example also adds new Sender header to indicate that it is sending the message on behalf of alice@example.com (if message already contains "Sender:" header, then that address should be preserved in "Original-Sender:" header) As before, when the message is subsequently forwarded by the almamater.edu.example MTA, that MTA will replace the SUBMITTER parameter with bob@almamater.edu.example as in section 6.2. 6.6 SUBMITTER Used on a Non-Delivery Report Alice sends an incorrectly addressed e-mail message and receives a non-delivery report from a SUBMITTER-compliant server. Leibzon Expires - April 2005 [Page 13] Responsible Submitter of an E-mail Message October 2004 S: 220 example.com ESMTP server ready C: EHLO almamater.edu.example S: 250-example.com S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM:<> SUBMITTER=mailer-daemon@almamater.edu.example S: 250 OK C: RCPT TO: S: 250 OK C: DATA S: 354 OK, send message C: (message body goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye 7. Security Considerations This document describes SMTP extension mechanism to allow SMTP client to identify the Responsible Submitter of an e-mail message and to enable SMTP servers to perform efficient validation of that identity which allows to catch and filter out spoofed email, which is today a pervasive security problem in the Internet. Assuming that this extension and verification mechanisms are widely deployed, the following sections describe counter-attacks that could be used to defeat this system: 7.1 DNS Attacks SPF verification mechanism is entirely dependent on DNS lookups, and is therefore only as secure as DNS. An attacker bent on spoofing messages could attempt to get his messages accepted by sending forged answers to DNS queries. An MTA could largely defeat such an attack by using a properly paranoid DNS resolver. DNSSEC may ultimately provide a way to completely neutralize this class of attacks. 7.2 TCP Attacks This mechanism is designed to be used in conjunction with SMTP over TCP. A sufficiently resourceful attacker might be able to send TCP packets with forged from-addresses, and thus execute an entire SMTP session that appears to come from somewhere other than its true origin. Leibzon Expires - April 2005 [Page 14] Responsible Submitter of an E-mail Message October 2004 Such an attack requires guessing what TCP sequence numbers an SMTP server will use. It also requires transmitting completely in the blind - the attack will be unable hear any of the server's side of the conversation. Attacks of this sort can be ameliorated if IP gateways refuse to forward packets when the source address is clearly bogus. 7.3 Address Space Hijacking This system assumes the integrity of IP address space for determining whether a given client is authorized to send messages based on provided Responsible Submitter identity. In addition to the TCP attack given in section 6.2, a sufficiently resourceful attacker might be able to alter the IP routing structure to permit two-way communication using a specified IP address. It would then be possible to execute an SMTP session that appears to come from an authorized address, without the need to guess TCP sequence numbers or transmit in the blind. Such an attack might occur if the attacker obtained access to a router which participates in external BGP routing. Such a router could advertise a more specific route to a rogue SMTP client, temporarily overriding the legitimate owner of the address. 8. IANA Considerations IANA is hereby requested to register the SUBMITTER SMTP service extension. 9. References 9.1 Normative References [ABNF] Crocker, D. and R. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997 [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MSG-FORMAT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. Leibzon Expires - April 2005 [Page 15] Responsible Submitter of an E-mail Message October 2004 [SMTPAUTH] Meyers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [SPF-PROTOCOL] Wong, M and M. Lentczner, "SPF Record: Format and Interpretation", draft-ietf-marid-protocol-03 (work in progress), September 2004 [STD] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. 9.2 Informative References [AUTH-STATUS] Kucherawy, M. S., "Message Header for Indicating Sender Authentication Status", draft-kucherawy-sender -auth-header-00 (work in progress), September 2004 [DMP] Fecyk G., "Designated Mailers Protocol", draft-fecyk-dmp-02.txt (work in progress), May 2004 [RMX] Danisch, H., "The RMX DNS RR and method for lightweight SMTP sender authorization", draft-danisch-dns-rr- smtp-04 (work in progress), May 2004 [Green] Green, D., "Domain-Authorized SMTP Mail", http://ops.ietf.org/lists/namedroppers/ namedroppers.2002/msg00656.html, June 2002 [Vixie] Vixie, P., "Repudiating Mail-From", http://ops.ietf.org/lists/namedroppers/ namedroppers.2002/msg00658.html, June 2002 Leibzon Expires - April 2005 [Page 16] Responsible Submitter of an E-mail Message October 2004 10. Acknowledgments This text is based primarily on draft-ietf-marid-submitter-03 document written by Eric Allman and Harry Katz and in part on draft-ietf-marid-core-03 written by Jim Lyon and Meng Weng Wong The idea of using a DNS record to check the legitimacy of an email was previously discussed in [RMX] draft by Hadmut Danisch and in [DMP] draft by Gordon Fecyk. This idea traces its ancestry to "Repudiating Mail-From" [Vixie] draft by Paul Vixie (who based it on suggestion by Jim Miller) and to "Domain-Authorized SMTP Mail" [Green] draft by David Green who first introduced this concept on namedroppers maillist in 2002. The author would also like to thank all the participants of the IETF MARID working group and SPF-discuss mail list. Special recognition is owed to the following individuals for their comments and suggestions on the concepts that went into this document: Robert Atkinson, Simon Attwell, Roy Badami, Greg Connor, Ned Freed, Dave Crocker, Matthew Elvey, Tony Finch, Mark Lentczner, Jim Lyon, Bruce McMillan, Sam Neely, Daryl Odnert, Meng Weng Wong, Margaret Olson, Pete Resnick, Hector Santos, Nick Shelness, Rand Wacker, Andrew Newton, Jim Fenton, Stephane Bortzmeyer. 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 - April 2005 [Page 17] Responsible Submitter of an E-mail Message October 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 - April 2005 [Page 18]