idnits 2.17.1 draft-hutzler-spamops-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 529. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 8, 2007) is 6109 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2554 (Obsoleted by RFC 4954) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SMTP C. Hutzler 3 Internet-Draft 4 Intended status: Best Current D. Crocker 5 Practice Brandenburg InternetWorking 6 Expires: January 9, 2008 P. Resnick 7 QUALCOMM Incorporated 8 E. Allman 9 Sendmail, Inc. 10 T. Finch 11 University of Cambridge Computing 12 Service 13 July 8, 2007 15 Email Submission Operations: Access and Accountability Requirements 16 draft-hutzler-spamops-08 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 9, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 Email has become a popular distribution service for a variety of 50 socially unacceptable, mass-effect purposes. The most obvious ones 51 include spam and worms. This note recommends conventions for the 52 operation of email submission and transport services between 53 independent operators, such as enterprises and Internet Service 54 Providers. Its goal is to improve lines of accountability for 55 controlling abusive uses of the Internet mail service. To this end 56 the document offers recommendations for constructive operational 57 policies between independent operators of email submission and 58 transmission services. 60 Email authentication technologies are aimed at providing assurances 61 and traceability between internetworked networks. In many email 62 services, the weakest link in the chain of assurances is initial 63 submission of a message. This document offers recommendations for 64 constructive operational policies for this first step of email 65 sending, the submission (or posting) of email into the transmission 66 network. Relaying and delivery entail policies that occur subsequent 67 to submission and are outside the scope of this document. 69 The document seeks BCP status. Comments and discussion of this 70 document should be addressed to the ietf-smtp@imc.org mailing list. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Submission, Relaying, Delivery . . . . . . . . . . . . . . . . 5 77 3.1. Best Practices for Submission Operation . . . . . . . . . 6 78 3.2. Transitioning to Submission Port . . . . . . . . . . . . . 7 79 4. External Submission . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. Best Practices for Support of External Submissions . . . . 8 81 5. Message Submission Authentication/Authorization 82 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 6. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 10 84 6.1. Security Considerations . . . . . . . . . . . . . . . . . 10 85 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 7.1. References -- Normative . . . . . . . . . . . . . . . . . 10 88 7.2. References -- Informative . . . . . . . . . . . . . . . . 11 89 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 91 Intellectual Property and Copyright Statements . . . . . . . . . . 13 93 1. Introduction 95 The very characteristics that make email such a convenient 96 communications medium -- its near ubiquity, rapid delivery, low cost 97 and support for exchanges without prior arrangement -- have made it a 98 fertile ground for the distribution of unwanted or malicious content. 99 Spam, fraud and worms have become a serious problem, threatening the 100 viability of email and costing end users and providers millions of 101 dollars in damages and lost productivity. In recent years, 102 independent operators including enterprises and ISPs have turned to a 103 number of different technologies and procedures, in an attempt to 104 combat these problems. They have had varying effect and vastly 105 different impacts on users and on the Internet mail infrastructure. 107 En route to its final destination, email will often travel between 108 multiple independent providers of email transmission services. These 109 services will generally have no prior arrangement with one another 110 and may employ different rules on the transmission. It is therefore 111 difficult both to debug problems that occur in mail transmission and 112 to assign accountability if undesired or malicious mail is injected 113 into the Internet mail infrastructure. 115 Many email authentication technologies exist. They provide some 116 accountability and traceability between disparate networks. This 117 document aims to build upon the availability of these technologies by 118 exploring best practices for authenticating and authorizing the first 119 step of an email's delivery, from a Mail User Agent (MUA) to a Mail 120 Submission Agent (MSA), known as submission. Without strong 121 practices on email submission, the use of authentication technologies 122 elsewhere in the service provides limited benefit. 124 This document specifies operational policies to be used for the first 125 step of email sending, the submission -- or posting from an MUA to an 126 MSA as defined below -- of email into the transmission service. 127 These policies will permit continued, smooth operation of Internet 128 email, with controls added to improve accountability. Relaying and 129 delivering employ policies that occur after submission and are 130 outside the scope of this document. The policies listed here are 131 appropriate for operators of all sizes of networks and may be 132 implemented by operators independently, without regard for whether 133 the other side of an email exchange has implemented them. 135 It is important to note that the adoption of these policies alone 136 will not solve the problems of spam and other undesirable email. 137 However they provide a useful step in clarifying lines of 138 accountability and interoperability between operators. This helps 139 raise the bar against abusers, and provides a foundation for 140 additional tools to preserve the utility of the Internet email 141 infrastructure. 143 NOTE: This document does not delve into other anti-spam operational 144 issues such as standards for rejection of email. The authors note 145 that this could be a valuable effort to undertake and encourage 146 its pursuit. 148 2. Terminology 150 The Internet email architecture distinguishes four message-handling 151 components: 153 o Mail User Agents (MUAs) 155 o Mail Submission Agents (MSAs) 157 o Mail Transfer Agents (MTAs) 159 o Mail Delivery Agents (MDAs) 161 At the origination end, an MUA works on behalf of end users to create 162 a message and perform initial "submission" into the transmission 163 infrastructure, via an MSA. An MSA accepts the message submission, 164 performs any necessary preprocessing on the message and relays the 165 message to an MTA for transmission. MTAs "relay" messages to other 166 MTAs, in a sequence reaching a destination MDA that, in turn, 167 "delivers" the email to the recipient's inbox. The inbox is part of 168 the recipient-side MUA that works on behalf of the end-user to 169 process received mail. 171 These architectural components are often compressed, such as having 172 the same software do MSA, MTA and MDA functions. However the 173 requirements for each of these components of the architecture are 174 becoming more extensive, so that their software and even physical 175 platform separation is increasingly common. 177 Normative Terms: The key words "MUST", "MUST NOT", "REQUIRED", 178 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 179 "MAY", and "OPTIONAL" in this document are to be interpreted as 180 described in [RFC2119]. 182 3. Submission, Relaying, Delivery 184 Originally the MSA, MTA and MDA architectural components were 185 considered to be a single unit. This was reflected the practice of 186 having MSA, MTA and MDA transfers all be performed with SMTP 188 [RFC2821] [RFC0821], over TCP Port 25. Internet mail permits email 189 to be exchanged without prior arrangement and without sender 190 authentication. That is, the confirmed identity of the originator of 191 the message is not necessarily known by the relaying MTAs or the MDA. 193 It is important to distinguish MUA-to-MSA email submission, versus 194 MTA relaying, versus the final MTA-to-MDA transition. Submission 195 typically does entail a pre-established relationship between the user 196 of the client and operator of the server; equally, the MDA is 197 performing final delivery and can determine that it has an existing 198 relationship with the recipient. That is, MSAs and MDAs can take 199 advantage of having prior relationships with users, in order to 200 constrain their transfer activities. 202 Specifically, an MSA can choose to reject all postings from MUAs for 203 which it has no existing relationship. Similarly, an MDA can choose 204 to reject all mail to recipients for which that MDA has no 205 arrangement to perform delivery. Indeed, both of these policies are 206 already in common practice. 208 3.1. Best Practices for Submission Operation 210 Submission Port Availability: 212 If external submissions are supported -- that is, from outside 213 a site's administrative domain -- then the domain's MSAs MUST 214 support the SUBMISSION port 587 [RFC4409]. Operators MAY 215 standardize on the SUBMISSION port for both external AND LOCAL 216 users; this can significantly simplify submission operations. 218 Submission Port Use: 220 MUAs SHOULD use the SUBMISSION port for message submission. 222 Submission Authentication: 224 MSAs MUST perform authentication on the identity asserted 225 during all mail transactions on the SUBMISSION port, even for a 226 message having a RCPT TO address that would not cause the 227 message to be relayed outside of the local administrative 228 environment. 230 Submission Authorization: 232 An operator of an MSA MUST ensure that the authenticated 233 identity is authorized to submit email, based on an existing 234 relationship between the submitting entity and the operator. 235 This requirement applies to all mail submission mechanisms (MUA 236 to MSA). 238 Submission Accountability after Submission: 240 For a reasonable period of time after submission, the message 241 SHOULD be traceable by the MSA operator to the authenticated 242 identity of the user who sent the message. Such tracing MAY be 243 based on transactional identifiers stored in the headers 244 (received lines, etc) or other fields in the message, on audit 245 data stored elsewhere, or on any other mechanism that supports 246 sufficient post-submission accountability. The specific length 247 of time, after message submission, that traceability is 248 supported is not specified here. However issues regarding 249 transit often occur as much as one week after submission. 251 Note that [RFC3848] defines a means of recording submission- 252 time information in Received header fields. This component 253 mechanism can be useful for accountability assessment by 254 receive-side analysis software to identify senders' MSAs and 255 therefore apply appropriate policies to the various hops of a 256 message transmission. 258 3.2. Transitioning to Submission Port 260 In order to promote transition of initial message submission from 261 port 25 to port 587, MSAs MUST listen on port 587 by default and 262 SHOULD have the ability to listen on other ports. MSAs MUST require 263 authentication on port 587 and SHOULD require authentication on any 264 other port used for submission. MSAs MAY also listen on other ports. 265 Regardless of the ports on which messages are accepted, MSAs MUST NOT 266 permit relaying of unauthenticated messages to other domains. That 267 is, they must not be open relays. 269 As a default, MUAs SHOULD attempt to find the best possible 270 submission port from a list of alternatives. The ordering of that 271 list SHOULD try the SUBMISSION port 587 first. Since most MUAs 272 available today do not permit falling back to alternate ports, sites 273 SHOULD pre-configure or encourage their users to connect on the 274 SUBMISSION port 587, assuming that site supports that port. 276 4. External Submission 278 An MUA might need to submit mail across the Internet, rather than to 279 a local MSA, in order to obtain particular services from its home 280 site. Examples include active privacy protection against third-party 281 content monitoring, timely processing, and being subject to the most 282 appropriate authentication and accountability protocols. Further the 283 privacy requirement might reasonably include protection against 284 monitoring by the operator of the MUA's access network. This 285 requirement creates a challenge for the provider operating the IP 286 network through which the MUA gains access. It makes that provider 287 an involuntary recruit to the task of solving mass-effect email 288 problems: When the MUA participates in a problem that affects large 289 numbers of Internet users, the provider is expected to effect 290 remedies and is often expected to prevent such occurrences. 292 A proactive technique used by some providers is to block all use of 293 Port 25 SMTP for mail that is being sent outbound, or to 294 automatically redirect this traffic through a local SMTP proxy, 295 except for hosts that are explicitly authorized. This can be 296 problematic for some users, notably legitimate mobile users 297 attempting to use their "home" MSA, even though those users might 298 already employ legitimate, Port 25-based authentication. 300 This document offers no recommendation concerning the blocking of 301 SMTP Port 25 or similar practices for controlling abuse of the 302 standard anonymous mail transfer port. Rather, it pursues the 303 mutually constructive benefit of using the official SUBMISSION Port 304 587 [RFC4409]. 306 NOTE: Many established practices for controlling abuse of port 25, 307 for mail that is being sent outbound, currently do exist. These 308 include the proxy of smtp traffic to local hosts for screening 309 combined with various forms of rate limits. The authors suggest 310 that a separate document on this topic would benefit the email 311 operations community. 313 4.1. Best Practices for Support of External Submissions 315 Open Submission Port: 317 Access Providers MUST NOT block users from accessing the 318 external Internet using the SUBMISSION port 587 [RFC4409]. 320 Traffic Identification -- External Posting (MSA) Versus Relaying 321 (MX): 323 When receiving email from outside their local operational 324 environment, email service providers MUST distinguish between 325 unauthenticated email addressed to local domains (MX traffic) 326 versus submission-related authenticated email that can be 327 addressed anywhere (MSA traffic). This allows the MTA to 328 restrict relaying operations, and thereby prevent "open" 329 relays. Note that there are situations where this may not 330 apply, such as secondary MXs and related implementations 331 internal to an operator's network and within their control. 333 Figure 1 depicts a local user (MUA.l) submitting a message to an MSA 334 (MSA). It also shows a remote user (MUA.r), such as might be in a 335 coffee shop offering "hotspot" wireless access, submitting a message 336 to their "home" MSA via an Authenticated Port 587 transaction. 338 HOME NETWORK DESTINATION 339 +-------+ 340 | MUA.l | 341 +---+---+ 342 port | port port port 343 587/25 V 25 25 -------- 25 344 +-----+ +-----+ ****** / \ ****** +-----+ +-----+ 345 | MSA |->| MTA |->* AP *->| |->* AP *->| MTA |->| MDA | 346 +--^--+ +-----+ ****** | INTERNET | ****** +-----+ +-----+ 347 | | | 348 +-------<--------------|----+ | 349 \ | / 350 ---^---- 351 | 352 ****** 353 AP = Access Provider * AP * 354 ****** 355 | Port 587 356 +---+----+ 357 | MUA.r | 358 +--------+ 359 HOTSPOT 360 Within the MSA's network, the alternative of using Port 587 or Port 361 25 is shown. This document makes no recommendations about the use of 362 Port 25 for submission. The diagram merely seeks to note that it is 363 in common use and to acknowledge that this can be accomplished with 364 sufficient accountability within an organization's network. 366 Figure 1: Example of Port 587 Usage Via Internet 368 5. Message Submission Authentication/Authorization Technologies 370 There are many competent technologies and standards for 371 authenticating message submissions. Two component mechanisms that 372 have been standardized include SMTP AUTH [RFC2554] and TLS [RFC3207]. 373 Depending upon the environment, different mechanisms can be more or 374 less effective and convenient. Mechanisms might also have to be used 375 in combination with each other to make a secure system. 376 Organizations SHOULD choose the most secure approaches that are 377 practical. 379 This document does not provide recommendations on specific security 380 implementations. It simply provides a warning that transmitting user 381 credentials in clear text over insecure networks SHOULD be avoided in 382 all scenarios as this could allow attackers to listen for this 383 traffic and steal account data. In these cases, it is strongly 384 suggested that an appropriate security technology MUST be used. 386 6. Consideration 388 6.1. Security Considerations 390 Email transfer between independent administrations can be the source 391 of large volumes of unwanted email and email containing malicious 392 content designed to attack the recipient's system. This document 393 addresses the requirements and procedures to permit such exchanges 394 while reducing the likelihood that malicious mail will be 395 transmitted. 397 6.2. IANA Considerations 399 This document has no actions for IANA. 401 7. References 403 7.1. References -- Normative 405 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 406 April 2001. 408 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 409 RFC 4409, April 2006. 411 7.2. References -- Informative 413 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 414 RFC 821, August 1982. 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC2554] Myers, J., "SMTP Service Extension for Authentication", 420 March . 422 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 423 Transport Layer Security", February 2002. 425 [RFC3848] Sun Microsystems, "ESMTP and LMTP Transmission Types 426 Registration", RFC 3848, July 2005. 428 Appendix A. Acknowledgments 430 These recommendations were first formulated during informal 431 discussions among members of Anti-Spam Technical Alliance (ASTA) and 432 some participants from the Internet Research Task Force's Anti-Spam 433 Research Group (ASRG). 435 Later reviews and suggestions were provided by: M. Allman, L.H. 436 Aestrand, N. Borenstein, S. Bortzmeyer, K. Chon, R. Clayton, B. Cole, 437 W. Dnes, V. Duchovni, E. Edelstein, F. Ellermann, M. Elvey, J.D. 438 Falk, N. Freed, J. Glube, A. Herzberg, J. Klensin, J. Levine, S. 439 Moonesamy, K. Moore, R. Nelson, C. Newman, C. O'Malley, S. 440 Ramasubramanian, R. Rognlie, J. St. Sauver, W. Schlitt, B. Shein, B. 441 Sullivan. 443 Authors' Addresses 445 C. Hutzler 446 2512 Freetown Drive 447 Reston, VA 20191 449 Phone: 703-915-6862 450 Email: cdhutzler@aol.com 451 URI: http://carlhutzler.com/blog/ 452 D. Crocker 453 Brandenburg InternetWorking 454 675 Spruce Dr. 455 Sunnyvale, CA 94086 456 USA 458 Phone: +1.408.246.8253 459 Email: dcrocker@bbiw.net 460 URI: http://bbiw.net 462 P. Resnick 463 QUALCOMM Incorporated 464 5775 Morehouse Drive 465 San Diego, CA 92121-1714 466 USA 468 Phone: +1 858 651 4478 469 Email: presnick@qualcomm.com 470 URI: http://www.qualcomm.com/~presnick/ 472 E. Allman 473 Sendmail, Inc. 474 Emeryville, CA 475 USA 477 Phone: +1 510 594 5501 478 Email: eric+ietf-smtp@sendmail.org 480 T. Finch 481 University of Cambridge Computing Service 482 New Museums Site 483 Pembroke Street 484 Cambridge CB2 3QH 485 ENGLAND 487 Phone: +44 797 040 1426 488 Email: dot@dotat.at 489 URI: http://dotat.at/ 491 Full Copyright Statement 493 Copyright (C) The IETF Trust (2007). 495 This document is subject to the rights, licenses and restrictions 496 contained in BCP 78, and except as set forth therein, the authors 497 retain all their rights. 499 This document and the information contained herein are provided on an 500 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 501 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 502 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 503 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 504 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 505 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 507 Intellectual Property 509 The IETF takes no position regarding the validity or scope of any 510 Intellectual Property Rights or other rights that might be claimed to 511 pertain to the implementation or use of the technology described in 512 this document or the extent to which any license under such rights 513 might or might not be available; nor does it represent that it has 514 made any independent effort to identify any such rights. Information 515 on the procedures with respect to rights in RFC documents can be 516 found in BCP 78 and BCP 79. 518 Copies of IPR disclosures made to the IETF Secretariat and any 519 assurances of licenses to be made available, or the result of an 520 attempt made to obtain a general license or permission for the use of 521 such proprietary rights by implementers or users of this 522 specification can be obtained from the IETF on-line IPR repository at 523 http://www.ietf.org/ipr. 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights that may cover technology that may be required to implement 528 this standard. Please address the information to the IETF at 529 ietf-ipr@ietf.org. 531 Acknowledgment 533 Funding for the RFC Editor function is provided by the IETF 534 Administrative Support Activity (IASA).