idnits 2.17.1 draft-nunn-ssmtp-00.txt: -(85): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(294): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 389 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 54 instances of too long lines in the document, the longest one being 160 characters in excess of 72. ** There are 199 instances of lines with control characters in the document. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 2002) is 7988 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2821 (ref. '1') (Obsoleted by RFC 5321) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jefferson Nunn 2 draft-nunn-ssmtp-00.txt Internet Solution Group, Inc. 3 June 12, 2002 5 Secure Simple Mail Transport Protocol 7 Status of this Memo 8 =================== 9 This document is an Internet-Draft and is subject to all 10 provisions of Section 10 of RFC2026 except that the right 11 to produce derivative works is not granted. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsolete by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 29 ======== 30 The Simple Mail Transport Protocol currently doesn't verify the 31 authenticity of the message such that it allows spammers and scammers 32 to exist without fear of retribution. This is due in part to the fact 33 that almost all data contained within the DATA section of an SMTP 34 mail transport can be spoofed. The SSMTP protocol would alleviate much 35 of this concern. 37 Revision Notes 38 ============== 39 Rev. 0 June 11, 2002 40 Initial draft. Stuff that needs checking: 41 * Mail Server Response Codes (e.g. 250, 255, etc.) 42 * References to SMTP commands in references section. 43 * Table of Contents 44 Rev. 1 June 12, 2002 08:45a 45 Added: 46 * 2.1 - Expanded the description of the mail client verification sequence 47 * 4.2 - Added a set TTL logic on mail client message verification. 48 * 4.3 - Detection of false verification servers. 49 Stuff that still needs checking: 50 * Mail Server Response Codes (e.g. 250, 255, etc.) 51 * References to SMTP commands in references section. 52 * Table of Contents 53 Rev. 2 - June 12, 2002 54 * Verified Response Codes based on RFC 0821. 55 * Added a reference to RFC2821. 56 * Table of Contents (without pagination...hmmm.) 57 Stuff that still needs doing: 58 * Figure out the pagination thingie. 59 * Refine the references 60 * Add some additional tables for easy reviewing (error codes, transport diagrams) 62 TABLE OF CONTENTS 63 ================= 64 1.0 Introduction 65 2.0 Client to Server communications 66 2.1 SSMTP Client to Server Authentication 67 2.2 X-SOURCEIP Server-based generated SMTP Extension. 68 2.3 X-USER Server-based generated SMTP Extension. 69 2.4 Error Message additions 70 3.0 Server to Server communications using SSMTP 71 3.1 Authentication 72 3.2 Message Verification error messages 73 4.0 Mail client to source mail server communications 74 4.1 Client verification 75 4.2 Verification Exceptions 76 4.3 Validating the Verification Service 77 5.0 References 79 1.0 Introduction 81 Presently, the SMTP protocol, as implemented, doesn�t support any sort 82 of verification process which would allow for the authenticity of a message 83 to be verified. This creates a series of problems which spammers and scammers 84 routinely exploit. Present-day proposals for blocking these types of activities, 85 including Open Relay Databases (ORDB) doesn�t stem the tide of spasm. The 86 typical user receives, on average, 50 to 100 spam messages per day. The typical 87 spammer can exploit this vulnerability, and launch a serious information warfare 88 attack, for less than $50. ORDB does little to protect against this, since it 89 can actually be used as a source database for a spammer. Persons that subscribe 90 to the ORDB frequently complain about not receiving messages, such that 91 business people force technicians to undo the ORDB protection. In addition, 92 anyone, today, with very little money can spoof an email address without fear 93 of retribution. 95 A much more secure protocol is required such that it can be phased in, over 96 time, and eventually become a standard. It needs to support tracing and 97 verification activity in order to ensure that the person that actually sent 98 the message was the person that actually sent the message. SSMTP (Secure Simple 99 Mail Transport Protocol) is comprised of three parts and is an extension of the 100 SMTP protocol. 102 * Client to Server communications 103 This is used to send the message using a mail server. 105 * Server to Server communications 106 This is used to transport the message from the source mail server to 107 the destination mail server. 109 * Client to Source Server communications 110 This is used to verify the message received against the source mail 111 server. 113 By implementing these standards, a typical spammer would expect to incur a 114 greater cost in order to spam messages. In addition, their location would be 115 known and law enforcement personnel could take additional actions against a 116 scammer. 118 2.0 Client to Server communications 120 The SMTP [1] protocol would be extended by implementing additional functions: 121 * Authentication 122 * X-SOURCEIP 123 * X-USERTOKEN 125 2.1 SSMTP Client to Server Authentication 127 The Mail client must authenticate to a mail server before it can deliver 128 a message. This ensures that the user is authorized to use the mail 129 server. The Mail Server Administrator can incorporate the enterprise 130 based authentication scheme of his/her choice, as the authentication 131 sequence must be verified against a local authentication server. 133 Using Port 25 as a �wake up� port, the mail server would initiate a 134 reverse path over one of the additional ports (such as 1024 to 65535) 135 to the requesting IP. In the event that the reverse path fails, the 136 server closes the session. 138 Over this path, the following commands are made available: 140 HELO 141 EHLO 142 USER 143 PASS 144 VERIFY 146 A mail client would first authenticate to the mail server using USER 147 and PASS. A typical session follows: 149 R: 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 150 S: USER jdoe 151 R: 255 USER jdoe requires PASS [10.1.1.10] 152 S: PASS 153 R: 256 PASS command accepted. 154 S: DATA 155 . 156 . 157 . 158 S: QUIT 160 Within the 255 return code, the IP address listed is the IP address 161 of the mail client. This can be the internal or the external IP address 162 and is subject to the IPv6 drafts. 164 The Username / Password sequence can authenticate against any one of 165 the publicly available authentication sources including, but not limited 166 to: 168 Windows 169 Active Directory 170 Novell 171 LDAP 172 NIS 173 Etc. 175 In addition, the User / Pass command can use encrypted sequences as 176 defined by the various vendors. For instance, the User command can pass 177 a token. The Pass command can pass a MD5 or 3DES algorithm. Options on 178 the Server console can be made available on a vendor by vendor basis. 179 Microsoft might choose Active Directory and NT5 algorithms. Oracle might 180 choose MD5. In addition, other security measures can be taken, such as 181 SecureID. This would actually further the security goals by ensuring 182 that only certain mail clients can send using SSMTP using that mail server. 184 2.2 X-SOURCEIP Server-based generated SMTP Extension. 186 All mail transported over SSMTP must contain the X-SOURCEIP. The X-SOURCEIP is 187 a server-generated extension included at the end of the SMTP DATA set. The 188 X-SOURCEIP would include the source IP address as discovered by the initial 189 session generated during the authentication session. As an example: 191 Message Headers: 192 To: "John Doe" 193 Return-Path: janedoe@somewhereelse.com 194 X-OriginalArrivalTime: 11 Jun 2002 22:26:51.0011 (UTC) FILETIME=[1503F530:01C21197] 195 X-SOURCEIP: 10.1.1.10 197 This X-SOURCEIP is a critical component of message verification. 199 2.3 X-USER Server-based generated SMTP Extension. 201 All mail transported over SSMTP must contain the X-USER. The X-USER is a 202 server-generated token included at the end of the SMTP DATA set. The X-USER 203 would include the user token object as generated by the server during the 204 authentication session. As an example: 206 Message Headers: 207 Message-ID: <34E09E608C610A4195974ED54E58F45303A2442@somewherelse.com> 208 To: "John Doe" 209 Return-Path: janedoe@somewhereelse.com 210 X-OriginalArrivalTime: 11 Jun 2002 22:26:51.0011 (UTC) FILETIME=[1503F530:01C21197] 211 X-SOURCEIP: 10.1.1.10 212 X-USER: 5ab240dec4 214 The X-USER can contain alphanumeric characters. On a Windows platform, this 215 could be the SID, or any other hashed token. On a NIS platform, this could be 216 the ID of the user. 218 The X-USER is another critical component of message verification. 220 2.4 Error Message additions 222 Should the user not authenticate successfully to the server, the 223 following error message would be generated: 225 550 User not authenticated. 227 3.0 Server to Server communications using SSMTP 229 The SMTP protocol would be extended by implementing some additional verification functions. 231 3.1 Authentication 233 The Source mail server would inform the destination mail server 234 that it has mail to be sent to the server by performing a helo and a 235 domain name. The source mail server would then open up a session to the 236 mail server by performing an MX lookup on the domain name, then 237 connecting to the mail server over the standard SMTP ports. An example 238 session follows: 240 Source Mail Server: 242 1. Performs an MX lookup, then connects to the IP address over port 25 243 2. After receiving a 220, issues a SHLO followed by a domain name. 245 Destination Mail Server: 247 1. After receiving a SHLO from the source mail server performs an MX 248 lookup, then connects to the IP address over port 25 249 2. After receiving a 220, issues a X-RECEIVEMAIL command 251 Source Mail Server 253 1. After receiving an X-RECEIVEMAIL command continues with the mail 254 transport functions. 256 A sample session follows: 258 Source Mail Server origination: 259 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 260 SHLO somedomain.com 261 221 somedomain.com commencing SSMTP. 262 264 Destination Mail Server origination: 265 220 mail.somedomain.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 266 X-RECEIVEMAIL 267 222 SSMTP verified. Commencing message transport. 269 During the DATA session, the X-USER and X-SOURCEIP would be passed. 271 3.2 Message Verification error messages 273 In the event that one or more of these processes fail, one of the 274 following error messages would be issued: 276 550 SSMTP failed. No originating session. 277 550 SSMTP failed. Source session failed to receive destination response. 278 550 SSMTP failed. No X-USER included with the message. 279 550 SSMTP failed. No X-SOURCEIP included with the message. 281 4.0 Mail client to source mail server communications 283 In order to verify that the message is real, the mail client needs 284 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). 286 4.1 Client verification 288 The mail client would inform the source mail server of a verification 289 request via issuing an X-VERIFY command. The X-VERIFY command has three 290 required fields, separated by commas: 292 MessageID � the message ID as generated by the source mail server. 293 X-USER � the user ID as generated by the source mail server. 294 X-SOURCEIP � the source IP address as generated by the source mail server. 296 A sample session would flow as follows: 298 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 299 X-VERIFY 34E09E608C610A4195974ED54E58F45303A2442@somewherelse.com, 5ab240dec4, 10.1.1.10 300 250 Message Verified. 301 303 In the event of a failure, the sample session would flow as follows: 305 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 306 X-VERIFY 34E09E608C610A4195974ED54E58F45303A2442@somewherelse.com, 5ab240dec4, 10.1.1.10 307 550 Message Not Verified. 308 310 In this event, the destination mail server would immediately delete the message. 312 4.2 Verification Exceptions 314 In the event that a mail server could not be reached, because the DNS record is 315 invalid, the message would be immediately deleted. 317 In the event that the DNS record is valid, but the verification server could not be 318 reached, the message would remain in the client's unverified message queue until 319 either the message is verified, or the TTL period expires (based on the DNS MX 320 record). 322 4.3 Validating the Verification Service 324 Periodically, a mail client could verify that a mail server is issuing false verifies 325 by issuing a bogus verify command. For instance: 327 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 328 X-VERIFY 34E09E608C610A4195974@somewherelse.com, 5ab240dec4, 10.1.1.10 329 550 Message Not Verified. 330 332 220 mail.somewhere.com Mail server ready at Tue, 11 Jun 2002 16:21:39 -0700 333 X-VERIFY 34E09E608C610A4195974ED54E58F45303A2442@somewherelse.com, 5ab240dec4, 10.1.1.10 334 250 Message Verified. 335 337 Would guarantee that the Verification Service is functioning properly and the 338 message is verified. 340 5.0 References 342 [1] Klensin, J., "Simple Mail Transport Protocol", RFC 2821, April 2001 343 URL: http://www.ietf.org/rfc/rfc2821.txt?number=2821 345 Author Address 346 ============== 347 Jefferson Nunn 348 Internet Solution Group, Inc. 349 2535 Townsgate Road Suite 310 350 Westlake Village, CA 91361 351 Jefferson@removetoemail.isgca.com 353 END 355 Full Copyright Statement 357 Copyright (C) The Internet Society 2002. All Rights Reserved. 359 This document and translations of it may be copied and furnished to 360 others, and derivative works that comment on or otherwise explain it or 361 assist in its implementation may be prepared, copied, published and 362 distributed, in whole or in part, without restriction of any kind, 363 provided that the above copyright notice and this paragraph are 364 included on all such copies and derivative works. However, this 365 document itself may not be modified in any way, such as by removing the 366 copyright notice or references to the Internet Society or other 367 Internet organizations, except as needed for the purpose of developing 368 Internet standards in which case the procedures for copyrights defined 369 in the Internet Standards process must be followed, or as required to 370 translate it into languages other than English. 372 The limited permissions granted above are perpetual and will not be 373 revoked by the Internet Society or its successors or assigns. 375 This document and the information contained herein is provided on an 376 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 377 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 378 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 379 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 380 FITNESS FOR A PARTICULAR PURPOSE.