Internet Draft Jefferson Nunn draft-nunn-ssmtp-00.txt Internet Solution Group, Inc. June 12, 2002 Secure Simple Mail Transport Protocol Status of this Memo =================== This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete 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. Abstract ======== The Simple Mail Transport Protocol currently doesn't verify the authenticity of the message such that it allows spammers and scammers to exist without fear of retribution. This is due in part to the fact that almost all data contained within the DATA section of an SMTP mail transport can be spoofed. The SSMTP protocol would alleviate much of this concern. Revision Notes ============== Rev. 0 June 11, 2002 Initial draft. Stuff that needs checking: * Mail Server Response Codes (e.g. 250, 255, etc.) * References to SMTP commands in references section. * Table of Contents Rev. 1 June 12, 2002 08:45a Added: * 2.1 - Expanded the description of the mail client verification sequence * 4.2 - Added a set TTL logic on mail client message verification. * 4.3 - Detection of false verification servers. Stuff that still needs checking: * Mail Server Response Codes (e.g. 250, 255, etc.) * References to SMTP commands in references section. * Table of Contents Rev. 2 - June 12, 2002 * Verified Response Codes based on RFC 0821. * Added a reference to RFC2821. * Table of Contents (without pagination...hmmm.) Stuff that still needs doing: * Figure out the pagination thingie. * Refine the references * Add some additional tables for easy reviewing (error codes, transport diagrams) TABLE OF CONTENTS ================= 1.0 Introduction 2.0 Client to Server communications 2.1 SSMTP Client to Server Authentication 2.2 X-SOURCEIP Server-based generated SMTP Extension. 2.3 X-USER Server-based generated SMTP Extension. 2.4 Error Message additions 3.0 Server to Server communications using SSMTP 3.1 Authentication 3.2 Message Verification error messages 4.0 Mail client to source mail server communications 4.1 Client verification 4.2 Verification Exceptions 4.3 Validating the Verification Service 5.0 References 1.0 Introduction Presently, the SMTP protocol, as implemented, doesnÆt support any sort of verification process which would allow for the authenticity of a message to be verified. This creates a series of problems which spammers and scammers routinely exploit. Present-day proposals for blocking these types of activities, including Open Relay Databases (ORDB) doesnÆt stem the tide of spasm. The typical user receives, on average, 50 to 100 spam messages per day. The typical spammer can exploit this vulnerability, and launch a serious information warfare attack, for less than $50. ORDB does little to protect against this, since it can actually be used as a source database for a spammer. Persons that subscribe to the ORDB frequently complain about not receiving messages, such that business people force technicians to undo the ORDB protection. In addition, anyone, today, with very little money can spoof an email address without fear of retribution. A much more secure protocol is required such that it can be phased in, over time, and eventually become a standard. It needs to support tracing and verification activity in order to ensure that the person that actually sent the message was the person that actually sent the message. SSMTP (Secure Simple Mail Transport Protocol) is comprised of three parts and is an extension of the SMTP protocol. * Client to Server communications This is used to send the message using a mail server. * Server to Server communications This is used to transport the message from the source mail server to the destination mail server. * Client to Source Server communications This is used to verify the message received against the source mail server. By implementing these standards, a typical spammer would expect to incur a greater cost in order to spam messages. In addition, their location would be known and law enforcement personnel could take additional actions against a scammer. 2.0 Client to Server communications The SMTP [1] protocol would be extended by implementing additional functions: * Authentication * X-SOURCEIP * X-USERTOKEN 2.1 SSMTP Client to Server Authentication The Mail client must authenticate to a mail server before it can deliver a message. This ensures that the user is authorized to use the mail server. The Mail Server Administrator can incorporate the enterprise based authentication scheme of his/her choice, as the authentication sequence must be verified against a local authentication server. Using Port 25 as a ôwake upö port, the mail server would initiate a reverse path over one of the additional ports (such as 1024 to 65535) to the requesting IP. In the event that the reverse path fails, the server closes the session. Over this path, the following commands are made available: HELO EHLO USER PASS VERIFY A mail client would first authenticate to the mail server using USER and PASS. A typical session follows: R: 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 S: USER jdoe R: 255 USER jdoe requires PASS [10.1.1.10] S: PASS R: 256 PASS command accepted. S: DATA . . . S: QUIT Within the 255 return code, the IP address listed is the IP address of the mail client. This can be the internal or the external IP address and is subject to the IPv6 drafts. The Username / Password sequence can authenticate against any one of the publicly available authentication sources including, but not limited to: Windows Active Directory Novell LDAP NIS Etc. In addition, the User / Pass command can use encrypted sequences as defined by the various vendors. For instance, the User command can pass a token. The Pass command can pass a MD5 or 3DES algorithm. Options on the Server console can be made available on a vendor by vendor basis. Microsoft might choose Active Directory and NT5 algorithms. Oracle might choose MD5. In addition, other security measures can be taken, such as SecureID. This would actually further the security goals by ensuring that only certain mail clients can send using SSMTP using that mail server. 2.2 X-SOURCEIP Server-based generated SMTP Extension. All mail transported over SSMTP must contain the X-SOURCEIP. The X-SOURCEIP is a server-generated extension included at the end of the SMTP DATA set. The X-SOURCEIP would include the source IP address as discovered by the initial session generated during the authentication session. As an example: Message Headers: To: "John Doe" Return-Path: janedoe@somewhereelse.com X-OriginalArrivalTime: 11 Jun 2002 22:26:51.0011 (UTC) FILETIME=[1503F530:01C21197] X-SOURCEIP: 10.1.1.10 This X-SOURCEIP is a critical component of message verification. 2.3 X-USER Server-based generated SMTP Extension. All mail transported over SSMTP must contain the X-USER. The X-USER is a server-generated token included at the end of the SMTP DATA set. The X-USER would include the user token object as generated by the server during the authentication session. As an example: Message Headers: Message-ID: <34E09E608C610A4195974ED54E58F45303A2442@somewherelse.com> To: "John Doe" Return-Path: janedoe@somewhereelse.com X-OriginalArrivalTime: 11 Jun 2002 22:26:51.0011 (UTC) FILETIME=[1503F530:01C21197] X-SOURCEIP: 10.1.1.10 X-USER: 5ab240dec4 The X-USER can contain alphanumeric characters. On a Windows platform, this could be the SID, or any other hashed token. On a NIS platform, this could be the ID of the user. The X-USER is another critical component of message verification. 2.4 Error Message additions Should the user not authenticate successfully to the server, the following error message would be generated: 550 User not authenticated. 3.0 Server to Server communications using SSMTP The SMTP protocol would be extended by implementing some additional verification functions. 3.1 Authentication The Source mail server would inform the destination mail server that it has mail to be sent to the server by performing a helo and a domain name. The source mail server would then open up a session to the mail server by performing an MX lookup on the domain name, then connecting to the mail server over the standard SMTP ports. An example session follows: Source Mail Server: 1. Performs an MX lookup, then connects to the IP address over port 25 2. After receiving a 220, issues a SHLO followed by a domain name. Destination Mail Server: 1. After receiving a SHLO from the source mail server performs an MX lookup, then connects to the IP address over port 25 2. After receiving a 220, issues a X-RECEIVEMAIL command Source Mail Server 1. After receiving an X-RECEIVEMAIL command continues with the mail transport functions. A sample session follows: Source Mail Server origination: 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 SHLO somedomain.com 221 somedomain.com commencing SSMTP. Destination Mail Server origination: 220 mail.somedomain.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 X-RECEIVEMAIL 222 SSMTP verified. Commencing message transport. During the DATA session, the X-USER and X-SOURCEIP would be passed. 3.2 Message Verification error messages In the event that one or more of these processes fail, one of the following error messages would be issued: 550 SSMTP failed. No originating session. 550 SSMTP failed. Source session failed to receive destination response. 550 SSMTP failed. No X-USER included with the message. 550 SSMTP failed. No X-SOURCEIP included with the message. 4.0 Mail client to source mail server communications In order to verify that the message is real, the mail client needs to verify against the source mail server whether or not this mail is real. This can be done at the server level (such as an Exchange, Notes, Groupwise or AOL server), or at the client level (using Eudora, Outlook or Netscape mail). 4.1 Client verification The mail client would inform the source mail server of a verification request via issuing an X-VERIFY command. The X-VERIFY command has three required fields, separated by commas: MessageID û the message ID as generated by the source mail server. X-USER û the user ID as generated by the source mail server. X-SOURCEIP û the source IP address as generated by the source mail server. A sample session would flow as follows: 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 X-VERIFY 34E09E608C610A4195974ED54E58F45303A2442@somewherelse.com, 5ab240dec4, 10.1.1.10 250 Message Verified. In the event of a failure, the sample session would flow as follows: 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 X-VERIFY 34E09E608C610A4195974ED54E58F45303A2442@somewherelse.com, 5ab240dec4, 10.1.1.10 550 Message Not Verified. In this event, the destination mail server would immediately delete the message. 4.2 Verification Exceptions In the event that a mail server could not be reached, because the DNS record is invalid, the message would be immediately deleted. In the event that the DNS record is valid, but the verification server could not be reached, the message would remain in the client's unverified message queue until either the message is verified, or the TTL period expires (based on the DNS MX record). 4.3 Validating the Verification Service Periodically, a mail client could verify that a mail server is issuing false verifies by issuing a bogus verify command. For instance: 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 X-VERIFY 34E09E608C610A4195974@somewherelse.com, 5ab240dec4, 10.1.1.10 550 Message Not Verified. 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 X-VERIFY 34E09E608C610A4195974ED54E58F45303A2442@somewherelse.com, 5ab240dec4, 10.1.1.10 250 Message Verified. Would guarantee that the Verification Service is functioning properly and the message is verified. 5.0 References [1] Klensin, J., "Simple Mail Transport Protocol", RFC 2821, April 2001 URL: http://www.ietf.org/rfc/rfc2821.txt?number=2821 Author Address ============== Jefferson Nunn Internet Solution Group, Inc. 2535 Townsgate Road Suite 310 Westlake Village, CA 91361 Jefferson@removetoemail.isgca.com END Full Copyright Statement Copyright (C) The Internet Society 2002. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.