idnits 2.17.1 draft-ietf-marid-mailfrom-00.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 474. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (September 15, 2004) is 7134 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 (Obsoleted by RFC 5321) -- Possible downref: Normative reference to a draft: ref. 'Protocol' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MARID M. Lentczner 2 Internet-Draft M. Wong 3 Expires: March 16, 2005 September 15, 2004 5 Authorizing Use of Domains in MAIL FROM 6 draft-ietf-marid-mailfrom-00 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 16, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 Mail on the Internet can be forged in a number of ways. In 42 particular, existing protocols place no restriction in what a sending 43 host can use as the reverse-path of a message. This document 44 describes a protocol whereby a domain can explicitly authorize the 45 hosts that are allowed to use its domain name in a reverse-path, and 46 a way for receiving hosts to check such authorization. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1 The Mail From Identity . . . . . . . . . . . . . . . . . . 3 54 2.2 Publishing Authorization . . . . . . . . . . . . . . . . . 4 55 2.3 Checking Authorization . . . . . . . . . . . . . . . . . . 4 56 2.4 Interpreting the Result . . . . . . . . . . . . . . . . . 5 57 2.4.1 Neutral . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.4.2 Pass . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4.3 Fail . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.4.4 SoftFail . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.4.5 None . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.4.6 TempError . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4.7 PermError . . . . . . . . . . . . . . . . . . . . . . 7 64 3. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1 Sending Domains . . . . . . . . . . . . . . . . . . . . . 7 66 3.2 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 7 67 3.3 Forwarding Services . . . . . . . . . . . . . . . . . . . 8 68 3.4 Mail Services . . . . . . . . . . . . . . . . . . . . . . 8 69 3.5 MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 74 Intellectual Property and Copyright Statements . . . . . . . . 11 76 1. Introduction 78 The current e-mail infrastructure has the property that any host 79 injecting mail into the mail system can identify itself as any domain 80 name it wants. Hosts can do this at a variety of levels: in 81 particular, the session, the envelope, and the mail headers. While 82 this feature is desirable in some circumstances, it is a major 83 obstacle to reducing end-user unwanted e-mail (or "spam"). 84 Furthermore, many domain name holders are understandably concerned 85 about the ease with which other entities may make use of their domain 86 names, often with intent to impersonate. 88 This document defines a protocol by which hosts my be authorized by 89 domains to use the domain name in the envelope "Mail From" identity. 90 Compliant domain name holders publish SPF records about which hosts 91 are permitted to use their names, and compliant mail receivers use 92 the published SPF records to test the authorization of hosts using a 93 given "Mail From" identity during a mail transaction. 95 An additional benefit to mail receivers is that when the use of an 96 identity is verified, then local policy decisions about the mail can 97 be made on the basis of the domain, rather than the host's IP 98 address. This is advantageous because reputation of domain names is 99 likely to be more accurate than reputation of host IP addresses. 100 Furthermore, if a claimed identity fails verification, then local 101 policy can take stronger action against such e-mail, such as 102 rejecting it. 104 1.1 Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 This document is concerned with a portion of a mail message commonly 111 called "envelope sender", "return path", "reverse path", "bounce 112 address", "2821 from", or "mail from". Since these terms are either 113 not well defined, or often used casually, this document defines the 114 "Mail From" identity in Section 2.1. Note that other terms, that may 115 superficially look like the common terms, such as "reverse-path" or 116 "Return-Path" are used only with the defined meanings from normative 117 documents. 119 2. Operation 121 2.1 The Mail From Identity 123 The "Mail From" identity derives from the SMTP MAIL command (see 125 [RFC2821].) This command supplies the "reverse-path" for a message, 126 which generally consists of the sender mailbox, and is the mailbox to 127 which notification messages are sent if there are problems delivering 128 the message. 130 This document defines the "Mail From" identity to be mailbox portion 131 of the path of the reverse-path as defined in [RFC2821], Section 132 4.1.2. when it is non-null. 134 [RFC2821] allows the reverse-path to be null (see Section 4.5.5.) In 135 this case, there is no explicit sender mailbox, and such a message 136 can be assumed to be a notification message from the mail system 137 itself. When the reverse-path is null, this document defines the 138 "Mail From" identity to be the mailbox composed of the localpart 139 "postmaster" and the domain supplied with the SMTP EHLO or HELO 140 command. Note that requirements for the domain presented in the EHLO 141 and HELO commands are not strict, and software must be prepared for a 142 "Mail From" identity so constructed to be ill formed. 144 Generally, software that checks the authorization checks described 145 below does so during a SMTP transaction, and so readily has the 146 information required at hand. However, software could perform these 147 checks at a different time, and if so, may extract the reverse-path 148 from the "Return-path" header as described in [RFC2821]. However, it 149 must be noted that while required, not all software complies with 150 inserting such headers. Furthermore, in these cases, if the 151 reverse-path is null, there may not be a reliable way to determine 152 the corresponding EHLO or HELO domain from the "Received:" headers. 154 2.2 Publishing Authorization 156 To authorize hosts to use a domain name in the "Mail From" identity, 157 those domains MUST publish SPF records for the domain name as 158 described in [Protocol]. SPF records used for the "Mail From" 159 identity use the "mfrom" scope identifier. 161 Domains SHOULD publish SPF records that end in "-all", or redirect to 162 other records that do, so that a definitive determination of 163 authorization can be made. 165 2.3 Checking Authorization 167 A mail server receiving mail can test the authorization of a client 168 host to inject mail with a given "Mail From" identity. To make the 169 test, the mail receiver MUST evaluate the check_host() function as 170 defined in [Protocol] with the arguments set as follows: 172 - the "mfrom" scope identifier 173 - the IP address of the client host that is injecting the 174 mail 175 - the domain portion of the "Mail From" identity 176 - the "Mail From" identity 178 Note that the argument may not be a well formed domain name. 179 For example, if the reverse-path was null, then the EHLO or HELO 180 domain is used, and that can be an address literal or entirely 181 malformed in a valid SMTP transaction. In these cases, check_host() 182 is defined in [Protocol], Section 3.3, "Initial Processing" to return 183 a Fail result. 185 Software SHOULD perform this authorization check during the 186 processing of the SMTP transaction that injects the mail. This 187 allows errors to be returned directly to the injecting server by way 188 of SMTP replies. Software can perform the check as early as the MAIL 189 command, though it may be easier to delay the check to some later 190 stage of the transaction. 192 Software can perform the authorization after the corresponding SMTP 193 transaction has completed. There are two problems with this 194 approach: 1) As described above, it may not be possible to 195 reconstruct the "Mail From" identity. 2) If the authorization fails, 196 then generating a nondelivery notification to the alleged sender is 197 problematic as such an action would go against the explicit wishes of 198 that sender. 200 2.4 Interpreting the Result 202 The check_host() function returns one of seven results, some with 203 additional information. This section describes how software that 204 performs the authorization must interpret the results. If the check 205 is being performed during the SMTP mail transaction, it also 206 describes how to respond. 208 2.4.1 Neutral 210 A Neutral result MUST be treated exactly like a None result. 212 2.4.2 Pass 214 A Pass result means that the client is authorized to inject mail with 215 the given "Mail From" identity. Further policy checks, such as 216 reputation, or black and/or white listing, can now proceed with 217 confidence based on the "Mail From" identity. 219 2.4.3 Fail 221 A Fail result is an explicit statement that the client is not 222 authorized to use the domain in the "Mail From" identity. The 223 checking software can choose to mark the mail based on this, or to 224 reject the mail outright. 226 If the checking software chooses to reject the mail during the SMTP 227 transaction, then it MUST use a 550 reply code with an appropriate 228 message. The Fail result includes a reason. The reason can be used 229 to construct an appropriate message. If the reason is "Not 230 Permitted", then an explanation string is also returned. This 231 explanation string comes from the domain that published the SPF 232 records and may contain a URL. Since that information doesn't 233 originate with the checking software, the checking software will want 234 to make it clear that text is not trusted. Example reply messages 235 for rejecting are: 237 550 SPF Mail From check failed: Malformed Domain 239 550 SPF Mail From check failed: Domain Does Not Exist 241 550-SPF Mail From check failed: Not Permitted 242 550-The domain example.com said: 243 550 Please see http://www.example.com/mailpolicy.html 245 2.4.4 SoftFail 247 A SoftFail result should be treated as somewhere between a Fail and a 248 Neutral. This value is used by domains as an intermediate state 249 during roll-out of publishing records. The domain believes the host 250 isn't authorized but isn't willing to make that strong of a 251 statement. Receiving software SHOULD NOT reject the message based on 252 this result, but MAY subject the message to closer scrutiny. 254 2.4.5 None 256 A result of None means that no records were published by the domain. 257 The checking software cannot ascertain if the client host is 258 authorized or not. 260 2.4.6 TempError 262 A TempError result means that the receiving server encountered a 263 transient error when performing the check. Checking software can 264 choose to accept or temporarily reject the message. If the message 265 is rejected during the SMTP transaction for this reason, the software 266 MUST use a 450 reply code. 268 2.4.7 PermError 270 A PermError result means that the domain's published records couldn't 271 be correctly interpreted for this "Mail From" identity. Checking 272 software SHOULD reject the message. If rejecting during SMTP 273 transaction time, a 550 reply MUST be used. 275 3. Implications 277 This section outlines the major implications that adoption of this 278 document will have on various entities involved in Internet e-mail. 279 It is intended to make clear to the reader where this document 280 knowingly affects the operation of such entities. This section is 281 not a "how-to" manual, nor a "best practices" document, and is not a 282 comprehensive list of what such entities should do in light of this 283 document. 285 This section is non-normative. 287 3.1 Sending Domains 289 Domains that wish to be compliant with this specification will need 290 to determine the list hosts that they allow to use their domain name 291 in the "Mail From" identity. It is recognized that forming such a 292 list is not just a simple technical exercise, but involves policy 293 decisions with both technical and administrative considerations. 295 3.2 Mailing Lists 297 Mailing lists must be aware of how they re-inject mail that is sent 298 to the list. If the list re-injects mail with the same reverse-path 299 that the mail had when it was received, then that mail may fail the 300 authorization tests defined in this document. In particular, they 301 will fail when the domain of the reverse-path publishes SPF records 302 for the "Mail From" identity, those records do not authorize the 303 mailing list host, and a receiver of the mailing list performs the 304 authorization test. 306 Almost all mailing list software in use for public mailing lists uses 307 a reverse-path with the mailing list's own domain so that the 308 software can receive mail bounces and assist in the administration of 309 the list. Lists that use such software, configured to operate this 310 way will require only one modest change in light of this document: 311 The mailing list host needs to be authorized by the mailing list 312 domain's own SPF record, if the domain publishes one. 314 Mailing lists based on simple alias expansion, or other software that 315 doesn't manage bounces directly, may or may not encounter problems 316 depending on how access to the list is restricted. Such lists that 317 are entirely internal to a domain (only people in the domain can send 318 to or receive from the list) are not affected. 320 3.3 Forwarding Services 322 Forwarding services take mail that is received at a mailbox and 323 direct it to some external mailbox. At the time of this writing, the 324 near-universal practice of such services is to use the original 325 reverse-path of a message when re-injecting it for delivery to the 326 external mailbox. This means the external mailbox's MTA sees all 327 such mail in a connection from a host of the forwarding service, and 328 so the "Mail From" identity will not in general pass authorization. 330 There are several possible ways that this authorization failure can 331 be ameliorated. If the owner of the external mailbox wishes to trust 332 the forwarding service, they can direct the external mailbox's MTA to 333 skip such tests when the client host belongs to the forwarding 334 service. Tests against some other identity may also be used to 335 override the test against the "Mail From" identity. 337 For larger domains, it may not be possible to have a complete or 338 accurate list of forwarding services used by the owners of the 339 domain's mailboxes. In such cases, white lists of generally 340 recognized forwarding services could be employed. 342 Forwarding services could also skirt the issue by using reverse-paths 343 that contain their own domain. This means that mail bounced from the 344 external mailbox will have to be re-bounced by the forwarding 345 service. Various schemes to do this exist though they vary widely in 346 complexity and resource requirements on the part of the forwarding 347 service. 349 3.4 Mail Services 351 Entities that offer mail services to other domains such as sending of 352 bulk mail will may have to alter their mail in light of the 353 authorization check in this document. If the reverse-path used for 354 such e-mail uses the domain of the mail service provider, then the 355 provider needs only to ensure that their sending host is authorized 356 by their own SPF record, if any. 358 If the reverse-path does not use the mail service provider's domain, 359 then extra care must be taken. The SPF record format has several 360 options for authorizing the sending MTAs of another domain (the 361 service provider's) (see [Protocol].) 363 3.5 MTA Relays 365 The authorization check generally precludes the use of arbitrary MTA 366 relays between sender of receiver of an e-mail message. However, the 367 use of open MTA relays on the Internet has long been noted as a 368 security problem. Most sites do not run open relays and many refuse 369 e-mail from known open relays. 371 Within an organization, MTA relays can be effectively deployed. 372 However, for purposes of this document, such relays are effectively 373 invisible. The "Mail From" identity authorization check is a check 374 between border MTAs. 376 For mail senders, this means that published SPF records must 377 authorized any MTAs that actually send across the Internet. Usually, 378 this is just the border MTAs as internal MTAs simply forward mail to 379 these MTAs for delivery. 381 Mail receivers will generally want to perform the authorization check 382 at the border MTAs. This allows mail that fails to be rejected 383 during the SMTP session rather than bounced. Internal MTAs then do 384 not perform the authorization test To perform the authorization test 385 other than at the border, the host that first transferred the message 386 to the organization must be determined, which can be difficult to 387 extract from headers. Testing other than at the border is not 388 recommended. 390 4. Security Considerations 392 Most of the security considerations introduced by the authorization 393 check are due to the SPF record format and the operation of the 394 check_host() function. These considerations are described in 395 [Protocol], Section 8, "Security Considerations". 397 The "Mail From" identity authorization must not be construed to 398 provide more assurance than it does. It is entirely possible for a 399 malicious sender to inject a message with a reverse-path that uses 400 their own domain, to have that domain's SPF record authorize the 401 sending host, and yet the message content can easily claim other 402 identities in the headers. Unless the user, or the MUA takes care to 403 note that the authorized "Mail From" identity does not match the 404 other, more commonly presented identities (such as the From: header), 405 the user may be lulled into a false sense of security. 407 When the authorization check fails with the code "Not Permitted", an 408 explanation string may be included in the reject response. Both the 409 sender and the rejecting receiver need to be aware that the 410 explanation was determined by the publisher of the SPF record 411 checked, and is in general not the receiver. The explanation may 412 contain URLs that may be malicious, and/or offensive or misleading 413 text. This is probably less of a concern than it may seem since such 414 messages are returned to the sender, and their source is the SPF 415 record published by the domain in the "Mail From" identity claimed by 416 that very sender. To put it another way, the only people who see 417 malicious explanation strings are people who's messages claim to be 418 from domains that publish such strings in their SPF records. 420 5. IANA Considerations 422 None. 424 6 Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 430 April 2001. 432 [Protocol] 433 Wong, M. and M. Lentczner, "The Sender-ID Record: Format 434 and Interpretation", draft-ietf-marid-protocol-03 (work in 435 progress), September 2004. 437 Authors' Addresses 439 Mark Lentczner 440 1209 Villa Street 441 Mountain View, CA 94041 442 United States of America 444 EMail: markl@glyphic.com 445 URI: http://www.ozonehouse.com/mark/ 447 Meng Weng Wong 448 Singapore 450 EMail: mengwong+spf@pobox.com 452 Intellectual Property Statement 454 The IETF takes no position regarding the validity or scope of any 455 Intellectual Property Rights or other rights that might be claimed to 456 pertain to the implementation or use of the technology described in 457 this document or the extent to which any license under such rights 458 might or might not be available; nor does it represent that it has 459 made any independent effort to identify any such rights. Information 460 on the procedures with respect to rights in RFC documents can be 461 found in BCP 78 and BCP 79. 463 Copies of IPR disclosures made to the IETF Secretariat and any 464 assurances of licenses to be made available, or the result of an 465 attempt made to obtain a general license or permission for the use of 466 such proprietary rights by implementers or users of this 467 specification can be obtained from the IETF on-line IPR repository at 468 http://www.ietf.org/ipr. 470 The IETF invites any interested party to bring to its attention any 471 copyrights, patents or patent applications, or other proprietary 472 rights that may cover technology that may be required to implement 473 this standard. Please address the information to the IETF at 474 ietf-ipr@ietf.org. 476 Disclaimer of Validity 478 This document and the information contained herein are provided on an 479 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 480 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 481 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 482 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 483 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 484 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 486 Copyright Statement 488 Copyright (C) The Internet Society (2004). This document is subject 489 to the rights, licenses and restrictions contained in BCP 78, and 490 except as set forth therein, the authors retain all their rights. 492 Acknowledgment 494 Funding for the RFC Editor function is currently provided by the 495 Internet Society.