Alternatives drafts for SUBMITTER identity

   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. Authors' Addresses...........................................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:



       <scope>   - the "submit" scope identifier

       <ip>      - the ip address of the SMTP client host

       <domain>  - the domain portion of the SUBMITTER parameter

	 <sender>  - 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 maybe 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 

        [email protected] [email protected] ;

        SPF=pass (auth-ip=10.0.0.10

          SPF/submit=pass ([email protected]))



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 dramatis personae appear in the examples:



   [email protected]:         the original sender of each e-mail message



   [email protected]:   the final recipient of each e-mail



   [email protected]: an email address used by Bob which he has

                              configured to forward mail to his office

                              account at [email protected]



   [email protected]:  an e-mail account provided to Alice by her

                              mobile e-mail network carrier



   [email protected]: 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:<[email protected]> [email protected]

      S: 250 <[email protected]> sender ok

      C: RCPT TO:<[email protected]>

      S: 250 <[email protected]> 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

   [email protected].  Although the original sender of the message

   is [email protected], Alice is not responsible for this most recent

   retransmission of the message.  That role is filled by

   [email protected] who established the forwarding of mail to

   [email protected].  Therefore for almamater.edu.example MTA

   a new message responsible submitter is [email protected],

   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:<[email protected]>

              [email protected]

      S: 250 <[email protected]> sender ok

      C: RCPT TO:<[email protected]>

      S: 250 <[email protected]> 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 [email protected], 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:<[email protected]> [email protected]

      S: 250 <[email protected]> sender ok

      C: RCPT TO:<[email protected]>

      S: 250 <[email protected]> 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 [email protected],

   and it sets the SUBMITTER parameter accordingly. The following shows

   how SMTP session of maillist sending the message to its subscriber 

   [email protected] 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:<[email protected]>

              [email protected]

      S: 250 <[email protected]> sender ok

      C: RCPT TO:<[email protected]>

      S: 250 <[email protected]> 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:<[email protected]>

              [email protected]

      S: 250 <[email protected]> sender ok

      C: RCPT TO:<[email protected]>

      S: 250 <[email protected]> recipient ok

      C: DATA

      S: 354 okay, send message

      C: Sender: [email protected]

      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 [email protected] as the responsible submitter for

   this message.  Further this MTA also inserts a Sender header as

   required by RFC2822 to show that [email protected] 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 [email protected] 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:<[email protected]>

              [email protected]

      S: 250 <[email protected]> sender ok

      C: RCPT TO:<[email protected]>

      S: 250 <[email protected]> recipient ok

      C: DATA

      S: 354 okay, send message

      C: Sender: [email protected]

      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 [email protected] 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

   [email protected] (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 [email protected] 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:<> [email protected]

      S: 250 OK

      C: RCPT TO:<[email protected]>

      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. Authors' Addresses



   William Leibzon

   Elan Networks

   500 Laurelwood Rd, Suite 12

   Santa Clara, CA 95054

   USA



   E-mail: [email protected]   



































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-

   [email protected].





Acknowledgement



   Funding for the RFC Editor function is currently provided by the

   Internet Society.



















Leibzon                Expires - April 2005                    [Page 18]