idnits 2.17.1 draft-lindberg-anti-spam-mta-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 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: ---------------------------------------------------------------------------- == Line 501 has weird spacing: '... accept host...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (9 June 1998) is 9453 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 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2065 (ref. '5') (Obsoleted by RFC 2535) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-12) exists of draft-gellens-submit-08 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Gunnar Lindberg 2 draft-lindberg-anti-spam-mta-04.txt Chalmers University 3 Expires December, 1998 of Technology 4 9 June 1998 6 Anti-Spam Recommendations for SMTP MTAs 8 Abstract 10 This memo gives a number of implementation recommendations for SMTP 11 [1] MTAs (Mail Transfer Agents, e.g. sendmail [6]) to make them more 12 capable of reducing the impact of spam(*). 14 The intent is that these recommendations will help clean up the spam 15 situation, if applied on enough SMTP MTAs on the Internet, and that 16 they should be used as guidelines for the various MTA vendors. We are 17 fully aware that this is not the final solution, but if these 18 recommendations were included, and used, on all Internet SMTP MTAs, 19 things would improve considerably and give time to design a more long 20 term solution. Some ideas are presented in the Future Work section. 22 A brief summary of this memo is: 24 o Stop unauthorized mail relaying. 25 o Spammers then have to operate in the open; deal with them. 26 o Design a mail system that can handle spam. 28 Status of This Memo 30 This document is an Internet-Draft. Internet-Drafts are working 31 documents of the Internet Engineering Task Force (IETF), its areas, 32 and its working groups. Note that other groups may also distribute 33 working documents as Internet-Drafts. Comments on this draft should 34 be sent to . 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 To view the entire list of current Internet-Drafts, please check the 42 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 43 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 44 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 45 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 47 1. Introduction 49 This memo is intended to become a Best Current Practice (BCP) RFC. 50 As such it should be used as a guideline for SMTP MTA implementors to 51 make their products more capable of preventing/handling spam. 52 Despite this being its primary goal, an intended side effect is to 53 suggest to the sysadmin/Postmaster community which "anti spam knobs" 54 an SMTP MTA is expected to have. 56 However, this memo is not generally intended as a description on how 57 to operate an SMTP MTA - which "knobs" to turn and how to configure 58 the options. If suggestions are provided, they will be clearly marked 59 and they should be read as such. 61 1.1. Background 63 Mass unsolicited electronic mail, often known as spam(*), has 64 increased considerably during a short period of time and has become a 65 serious threat to the Internet email community as a whole. Something 66 needs to be done fairly quickly. 68 The problem has several components: 70 o It is high volume, i.e. people get a lot of such mail in their 71 mailboxes. 73 o It is completely "blind", i.e. there is no correlation between 74 the receivers' areas of interest and the actual mail sent out 75 (at least if one assumes that not everybody on the Internet is 76 interested in porno pictures and spam programs...). 78 o It costs real money for the receivers. Since many receivers 79 pay for the time to transfer the mailbox from the (dialup) ISP 80 to their computer they in reality pay real money for this. 82 o It costs real money for the ISPs. Assume one 10 Kbyte message 83 sent to 10 000 users with their mailboxes at one ISP host; 84 that means an unsolicited, unexpected, storage of 100 Mbytes. 85 State of the art disks, 4 Gbyte, can take 40 such message 86 floods before they are filled. It is almost impossible to 87 plan ahead for such "storms". 89 o Most of the senders of spam are dishonest, e.g. hide behind 90 false return addresses, deliberately write messages to look 91 like they were between two individuals so the spam recipient 92 will think it was just misdelivered to them, say the message 93 is "material you requested" when you never asked for it, and 94 generally do everything they can without regard to honesty or 95 ethics, to try to get a few more people to look at their 96 message". 98 In fact many of the spam-programs show a pride in adding 99 false info that will "make the ISPs scratch their heads". 101 It is usually the case that people who send in protests (often 102 according to the instructions in the mail) find their mail 103 addresses added to more lists and sold to other parties. 105 o It is quite common practice to make use of third party hosts 106 as relays to get the spam mail sent out to the receivers. This 107 theft of service is illegal in most - if not all - countries 108 (at least in the US spammers have been successfully sued). 109 However, with the original sender in the US, the (innocent) 110 relay in Sweden and the list of receivers back in the US, the 111 legal process of getting damages from the spammers becomes 112 extremely difficult 114 1.2. Scope 116 This memo has no intent to be the final solution to the spam problem. 118 If, however, enough Internet MTAs did implement enough of the rules 119 described below (especially the Non-Relay rules), we would get the 120 spammers out in the open, where they could be taken care of. Either 121 pure legal actions would help, or we can block them technically using 122 other rules described below (since the Non-Relay rules now make them 123 appear openly, with their own hosts and domains, we can apply various 124 access filters against them). In reality, a combination of legal and 125 technical methods is likely to give the best result. 127 This way, the spam problem could be reduced enough to allow the 128 Internet community to design and deploy a real and general solution. 130 But, please note: 132 The Non-Relay rules are not in themselves enough to stop spam. 133 Even of 99% of the SMTP MTAs implemented them from Day 1, 134 spammers would still find the remaining 1% and use them. Or, 135 spammers would just switch gear and connect directly to each 136 and every recipient host; that will be to a higher cost for 137 the spammer, but is still quite likely. 139 Despite IPv6 deployment may be near in time, the spam problem is here 140 already and thus this memo restricts itself to the current IPv4. 142 1.3. Terminology 144 Throughout this memo we will use the terminology of RFC2119, [4]: 146 o "MUST" 148 This word or the adjective "REQUIRED" means that the item is 149 an absolute requirement. 151 o "SHOULD" 153 This word or the adjective "RECOMMENDED" means that there may 154 exist valid reasons in particular circumstances to ignore 155 this item, but the full implications should be understood and 156 the case carefully weighed before choosing a different course. 158 o "MAY" 160 This word or the adjective "OPTIONAL" means that this item is 161 truly optional. One vendor may choose to include the item 162 because a particular marketplace requires it or because it 163 enhances the product, for example; another vendor may omit 164 the same item. 166 1.4. Using DNS information 168 In the memo we sometimes use the term "host name" or "domain name" 169 which should be interpreted as a Fully Qualified Domain Name, FQDN. 170 By this we mean the name returned from the DNS in response to a PTR 171 query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a 172 name, or we mean a name with a DNS A or MX record associated to it. 174 When we suggest use of FQDNs rather than IP addresses this is because 175 FQDNs are intuitively much easier to use. However, all such usage 176 depends heavily on DNS and .IN-ADDR.ARPA (PTR) information. Since it 177 is fairly easy to forge that, either by false cache information 178 injected in DNS servers or spammers running their own DNS with false 179 information in them, host and domain names must be used with care, 180 e.g. verified so that the translation address->name corresponds to 181 name->address. With Secure DNS, RFC2065, [5], things will improve, 182 since spoofing of .IN-ADDR.ARPA will no longer be possible. 184 One of the recommendations is about verifying "MAIL From:" domains 185 with the DNS (assure that appropriate DNS information exists for the 186 domain). When making use of this capability there are a few things to 187 consider: 189 For early versions of spam software it does provide quite some 190 relief, since that software generates mail with completely bogus 191 "MAIL From:" that will never get into the system if verified with 192 the DNS. This is in active use at many installations today and it 193 does reduce spam. 195 On the other hand, sites with weak DNS connectivity may find their 196 legitimate mail having problems reaching destinations due to DNS 197 timeouts when the receivers verify their "MAIL From:". However, since 198 DNS information is handled asynchronously and is cached even though 199 the initial requester has given up, chances are high that the 200 necessary information is there at a later attempt. 202 For later versions of spam software, a check of "MAIL From:" is much 203 less likely to help, since spam software evolves too and will start 204 using existing mail addresses (whether or not that is legal is beyond 205 the scope of this memo). But, at least the Internet will benefit from 206 the side effect that this test stops typos and misconfigured UAs. 208 1.5. Where to block spam, in SMTP, in RFC822 or in the UA 210 Our basic assumption is that refuse/accept is handled at the SMTP 211 layer and that an MTA that decides to refuse a message should do so 212 while still in the SMTP dialogue. First, this means that we do not 213 have to store a copy of a message we later decide to refuse and 214 second, our responsibility for that message is low or none - since we 215 have not yet read it in, we leave it to the sender to handle the 216 error. 218 1.6. SMTP Return Codes 220 SMTP has several classes of Return Codes, see [1] for a discussion: 222 o 5xx 223 is a Permanent Negative Completion reply (Fatal Error) and 224 results in the mail transfer being terminated and the mail 225 returned to sender. 227 o 4xx 228 is a Transient Negative Completion reply (Temporary Error) and 229 results in the mail transfer being put back on queue again and 230 a new attempt being made later. 232 o 2xx 233 is a Positive Completion reply and indicates that the MTA now 234 has taken responsibility for the delivery of the mail. 236 When making use of the options/"knobs" described in this memo there 237 are a few things to consider: 239 For some events, like "Denied - you're on the spammer's list", 5xx 240 may be the correct Return Code, since it terminates the session at 241 once and we are done with it (assuming that the spammer plays by the 242 SMTP rules, which he may decide not to do - in fact he can put the 243 mail back on queue or turn to some other host, regardless of Return 244 Code). However, a 5xx mistake in a configuration may cause legitimate 245 mail to bounce, which may be quite unfortunate. 247 Therefore, we suggest 4xx as the Return Code for most cases. Since 248 that is a non fatal error, the mail gets re-queued at the sender and 249 we have at least some time to discover and correct configuration 250 errors, rather than have mail bounce (typically this is when we 251 refuse to Relay for domains that we actually should accept since we 252 are on their MX list). 254 A 4xx response also makes the spammer's host re-queue the mail and if 255 it really is his own host who gets to do this, it is probably a good 256 thing - fill up his disks with his own spam. If, on the other hand, 257 he is using someone else as Relay Host, all the spam mail being 258 queued is a fairly strong evidence that something bad is going on and 259 should cause attention at that Relay Host. 261 However, 4xx Temporary Errors may have unexpected interaction with 262 MX-records. If the receiving domain has several MX records and the 263 lowest preference MX-host refuses to receive mail with a "451" 264 Response Code, the sending host may choose to - and often will - use 265 the next host on the MX list. 267 If that next MX host does not have the same refuse-list, it will of 268 course accept the mail, only to find that the final host still 269 refuses to receive that piece of mail ("MAIL From:"). I.e. our intent 270 was to make the offending mail stay at the offending sender's host 271 and fill up his mqueue disk, but it all ended up at our friend, the 272 next lowest preference MX-host. 274 Finally, it has been suggested that one may use a 2xx Return Code but 275 nevertheless decide not to forward or receive the spam mail; typical 276 alternatives are to store it elsewhere (e.g. /dev/null). This clearly 277 violates the intent of RFC821 and should not be done without careful 278 consideration - instead of blindly dropping the mail one could re- 279 queue it and manually (or automagically) inspect whether it is spam 280 or legitimate mail and whether it should be dropped or forwarded. 282 1.7. Mailing Lists 284 An MTA that also has the ability to handle mailing lists and expand 285 that to a number of recipients, needs to be able to authorize senders 286 and protect its lists from spam. The mechanisms for this may be very 287 different from those for ordinary mail and ordinary users and are not 288 covered in this memo. 290 2. Recommendations 292 Here we first give a brief list of recommendations, followed by a 293 more thorough discussion of each of them. We will also give 294 recommendations on things NOT to do, things that may seem natural in 295 the spam fight (and might even work so far) but that might wreak 296 havoc on Internet mail and thus may cause more damage than good. 298 1) MUST be able to restrict unauthorized use as Mail Relay. 300 2) MUST be able to provide "Received:" lines with enough 301 information to make it possible to trace the mail path, despite 302 spammers use forged host names in HELO statements etc. 304 3) MUST be able to provide local log information that makes it 305 possible to trace the event afterwards. 307 4) SHOULD be able to log all occurrences of anti-relay/anti-spam 308 actions. 310 5) SHOULD be able to refuse mail from a host or a group of hosts. 312 6a) MUST NOT refuse "MAIL From: <>". 314 6b) MUST NOT refuse "MAIL From: ". 316 7a) SHOULD be able to refuse mail from a specific "MAIL From:" 317 user, . 319 7b) SHOULD be able to refuse mail from an entire "MAIL From:" 320 domain <.*@domain.example>. 322 8) SHOULD be able to limit ("Rate Control") mail flow. 324 9) SHOULD be able to verify "MAIL From:" domain (using DNS or 325 using other means). 327 10) SHOULD be able to verify in outgoing mail. 329 11) SHOULD be able to control SMTP VRFY and EXPN. 331 12) SHOULD be able to control SMTP ETRN. 333 13) MUST be able to configure to provide different Return Codes 334 for different rules (e.g. 451 Temp Fail vs 550 Fatal Error). 336 The discussion below often ends up in a need to do various forms of 337 pattern matching, on domain/host names and on IP addresses/subnets. 338 It is RECOMMENDED that the data/template for doing so may be supplied 339 outside of the MTA, e.g. that the pattern matching rules be included 340 in the MTA but that the actual patterns may be in an external file. 341 It is also RECOMMENDED that the pattern matching rules (external 342 file) may contain regular expressions, to give maximum flexibility. 344 Of course all string matching on domain/host names MUST be non case 345 sensitive. Since may be case sensitive it may be natural 346 to keep that here. However, since and 347 is most probably the same user and since the 348 string compares are used to refuse his messages, we suggest that 349 be compared non case sensitive too. 351 The interpretation that should apply to all these recommendations is 352 flexibility - regardless of how well we design anti-spam rules today, 353 spammers will find ways around them and a well designed MTA should be 354 flexible enough to meet those new threats. 356 2.1. Restricting unauthorized Mail Relay usage 358 Unauthorized usage of a host as Mail Relay means theft of the relay's 359 resources and puts the owner's reputation at risk. It also makes it 360 impossible to filter out or block spam without at the same time 361 blocking legitimate mail. 363 Therefore, the MTA MUST be able to control/refuse such Relay usage. 365 In an SMTP session we have 4 elements, with a varying degree of 366 trust: 368 1) "HELO Hostname" Easily and often forged. 369 2) "MAIL From:" Easily and often forged. 370 3) "RCPT To:" Correct, or at least intended. 371 4) SMTP_Caller (host) IP.src addr OK, FQDN may be OK. 373 Since 1) and 2) are so easily and often forged, we cannot depend on 374 them at all to authorize usage of our host as Mail Relay. 376 Instead, the MTA MUST be able to authorize Mail Relay usage based on 377 a combination of: 379 o "RCPT To:" address (domain). 380 o SMTP_Caller FQDN hostname. 381 o SMTP_Caller IP address. 383 The suggested algorithm is: 385 a) If "RCPT To:" is one of "our" domains, local or a domain that 386 we accept to forward to (alternate MX), then accept to Relay. 388 b) If SMTP_Caller is authorized, either its IP.src or its FQDN 389 (depending on if you trust the DNS), then accept to Relay. 391 c) Else refuse to Relay. 393 When doing a) you have to make sure all kinds of SMTP source routing 394 (both the official [@a,@b:u@c], the '%' hack and uucp-style '!' path) 395 is either removed completely before the test, or is at least not 396 taken into account. 398 In all cases the configuration MUST support wild cards for FQDNs and 399 classful IP addresses and SHOULD support "address/mask" for classless 400 IP addresses, e.g. domain.example and *.domain.example; 10.11.*.*, 401 192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23. 403 The configuration SHOULD allow for the decision/template data to be 404 supplied by an external source, e.g. text file or dbm database. The 405 decision/template SHOULD be allowed to contain regular expressions. 407 2.2. Received: lines 409 The MTA MUST prepend a "Received:" line in the mail (as described in 410 RFC822, [2], and required in RFC1123, [3]). This "Received:" line 411 MUST contain enough information to make it possible to trace the mail 412 path back to the sender. We have two cases: 414 2.2.1. Direct MTA-to-MTA connections 416 Internet mail was designed such that the sending host connects 417 directly to the recipient as described by MX records (there may be 418 several MX hosts on a priority list). To assure traceability back to 419 the sending host (which may be a firewall/gateway, as described 420 later) each MTA along the path, including the final MTA, MUST prepend 421 a "Received:" line. For such a "Received:" line we have: 423 It MUST contain: 425 o The IP address of the caller. 427 o The 'date-time' as described in RFC822, [2], pp 18. 429 It SHOULD contain: 431 o The FQDN corresponding to the callers IP address. 433 o The argument given in the "HELO" statement. 435 It is suggested that most other "Received:" fields described in 436 RFC822 be included in the "Received:" lines. 438 These recommendations are deliberately stronger than RFC1123, [3], 439 and are there to assure that mail sent directly from a spammer's host 440 to a recipient can be traced with enough accuracy; a typical example 441 is when a spammer uses a dialup account and the ISP needs to have his 442 IP address at the 'date-time' to be able to take action against him. 444 2.2.2. Firewall/gateway type devices 446 Organizations with a policy to hide their internal network structure 447 must still be allowed and able to do so. They usually make their 448 internal MTAs prepend "Received:" lines with a very limited amount of 449 information, or prepend none at all. Then they send out the mail 450 through some kind of firewall/gateway device, which may even remove 451 all the internal MTAs' "Received:" lines before it prepends its own 452 "Received:" line (as required in RFC1123, [3]). 454 By doing so they take on the full responsibility to trace spammers 455 that send from inside their organization or they accept to be held 456 responsible for those spammers' activities. It is REQUIRED that the 457 information provided in their outgoing mail is sufficient for them to 458 perform necessary traces. 460 2.3. Event logs 462 The MTA MUST be able to provide enough local log information to make 463 it possible to trace the event. This includes most of the information 464 put into the "Received:" lines, see above. 466 2.4. Log anti-relay/anti-spam actions 468 The MTA SHOULD be able to log all anti-relay/anti-spam actions. The 469 log entries SHOULD contain at least: 471 o Time information. 473 o Refuse information, i.e. why the request was refused ("Mail 474 From", "Relaying Denied", "Spam User", "Spam Host", etc). 476 o "RCPT To:" addresses (domains). 478 o Offending host's IP address. 480 o Offending host's FQDN hostname. 482 o Other relevant information (e.g. given during the SMTP 483 dialogue, before we decided to refuse the request). 485 2.5. Refuse mail based on SMTP_Caller address 487 The MTA SHOULD be able to accept or refuse mail from a specific host 488 or from a group of hosts. Here we mean the IP.src address or the FQDN 489 that its .IN-ADDR.ARPA resolves to (depending on whether your trust 490 the DNS). This functionality could be implemented at a firewall, but 491 since the MTA should be able to "defend itself" we recommend it here. 493 It is RECOMMENDED that the MTA decide based on FQDN hostnames 494 (host.domain.example), on wild card domain names (*.domain.example), 495 on individual IP addresses (10.11.12.13) or on IP addresses with a 496 prefix length (10.0.0.0/8, 192.168.1.0/24). 498 It is also RECOMMENDED that these decision rules can be combined to 499 form a flexible list of accept/refuse/accept/refuse, e.g: 501 accept host.domain.example 502 refuse *.domain.example 503 accept 10.11.12.13 504 accept 192.168.1.0/24 505 refuse 10.0.0.0/8 507 The list is searched until first match and the accept/refuse action 508 is based on that. 510 IP-address/length is RECOMMENDED. However, implementations with wild 511 cards, e.g. 10.11.12.* (classful networks on byte boundaries only) 512 are of course much better then those without. 514 To improve filtering even more, the MTA MAY provide complete regular 515 expressions to be used for hostnames; possibly also for IP addresses. 517 2.6. "MAIL From: <>" and "MAIL From: " 519 Although the fight against spammers is important it must never be 520 done in a way that violates existing email standards. Since spammers 521 often forge "MAIL From:" addresses it is tempting to put general 522 restrictions on that, especially for some "obvious" addresses. This 523 may, however, wreak more havoc to the mail community than spam does. 525 When there is a need to refuse mail from a particular host or site 526 our recommendation is to use other methods mentioned in this memo, 527 e.g. refuse mail based on SMTP_Caller address (or name), regardless 528 of what "MAIL From:" was used. 530 2.6.1. "MAIL From: <>" 532 The MTA MUST NOT refuse to receive "MAIL From: <>". 534 The "MAIL From: <>" address is used in error messages from the mail 535 system itself, e.g. when a legitimate mail relay is used and forwards 536 an error message back to the user. Refusing to receive such mail 537 means that users may not be notified of errors in their outgong mail, 538 e.g. "User unknown", which will no doubt wreak more havoc to the 539 mail community than spam does. 541 The most common case of legitimate such "MAIL From: <>" is to one 542 recipient, i.e. an error message returned to one single individual. 543 Since spammers have used "MAIL From: <>" to send to many recipients, 544 it is tempting to either reject such mail completely or to reject all 545 but the first recipient. However, there are legitimate causes for an 546 error mail to go to multiple recipients, e.g. a list with several 547 list owners, all located at the same remote site, and thus the MTA 548 MUST NOT refuse "MAIL From: <>" even in this case. 550 However, the MTA MAY throttle down the TCP connection ("read()" 551 frequency) if there are more than one "RCPT To:" and that way slow 552 down spammers using "MAIL From: <>". 554 2.6.2. "MAIL From: " 556 The MTA MUST NOT refuse "MAIL From: ". 558 By "my.local.dom.ain" we mean the domain name(s) that are treated as 559 local and result in local delivery. At first thought it may seem like 560 noone else will need to use "MAIL From: " and 561 that restrictions on who may use that would reduce the risk of fraud 562 and thus reduce spam. While this may be true in the (very) short 563 term, it also does away with at least two legitimate usages: 565 o Aliases (.forward files). 566 sends to and 567 that mail gets forwarded back to , e.g. 568 since has moved to my.local.dom.ain and has a .forward 569 file at external.example. 571 o Mailing lists. 572 RFC1123, [3], gives a clear requirement that "MAIL From:" for 573 mail from a mailing list should reflect the owner of the list, 574 rather then the individual sender. However, not all lists are 575 that well maintained (not even all IETF lists) and thus we will 576 have to fall back to the principle of "Be strict in what you 577 send and liberal in what you receive". 579 If "MAIL From: " is rejected, both these 580 cases will result in failure to deliver legitimate mail. 582 2.7. Refuse based on "MAIL From:" 584 The MTA SHOULD be able to refuse to receive mail from a specific 585 "MAIL From:" user (foo@domain.example) or from an entire "MAIL From:" 586 domain (domain.example). In general this kind of rules are easily 587 overcome by the spammers changing "MAIL From:" every so often, but 588 the ability to block a certain user or a certain domain is quite 589 helpful while an attack has just been discovered and is ongoing. 591 Please note that 593 "MAIL From: <>" 594 and 595 "MAIL From: " 597 MUST NOT be refused (see above). 599 2.8. Rate Control 601 The MTA SHOULD provide tools for the mail host to control the rate 602 with which mail is sent or received. The idea is twofold: 604 1) If we happen to have an legitimate mail user with an existing 605 legitimate account and this user sends out spam, we may want 606 to reduce the speed with which he sends it out. This is not 607 without controversy and must be used with extreme care, but it 608 may protect the rest of the Internet from him. 610 2) If we are under a spam attack it may help us considerably just 611 being able to slow down the incoming mail rate for that 612 particular user/host. 614 For sending mail, this has to be done by throttling the TCP 615 connection to set the acceptable output data rate, e.g. reduce the 616 "write()" frequency. 618 For receiving mail, we could use basically the same technique, e.g. 619 reduce the "read()" frequency, or we could signal with a 4xx Return 620 Code that we cannot receive. It is RECOMMENDED that the decision to 621 take such action be based on "MAIL From:" user, "MAIL From:" domain, 622 SMTP_Caller (name/address) or a combination of all these. 624 2.9. Verify "MAIL From:" 626 The MTA SHOULD be able to perform a simple "sanity check" of the 627 "MAIL From:" domain and refuse to receive mail if that domain is 628 nonexistent (i.e. does not resolve to having an MX or an A record). 629 If the DNS error is temporary, TempFail, the MTA MUST return a 4xx 630 Return Code (Temporary Error). If the DNS error is an Authoritative 631 NXdomain (host/domain unknown) the MTA SHOULD still return a 4xx 632 Return Code (since this may just be primary and secondary DNS not 633 being in sync) but it MAY allow for an 5xx Return Code (as configured 634 by the sysadmin). 636 2.10. Verify 638 The MTA SHOULD allow outgoing mail to have its verified 639 so that the sender name is a real user or an existing alias. This is 640 basically to protect the rest of the Internet from various "typos" 641 MAIL From: 642 and/or malicious users 643 MAIL From: 645 As always this can be overcome by spammers really wanting to do so, 646 but with more strict rules for relaying it becomes harder and harder. 647 In fact, catching "typos" at the initial (and official) mail relay is 648 in itself enough motivation for this recommendation. 650 2.11. SMTP VRFY and EXPN 652 Both SMTP VRFY and EXPN provide means for a potential spammer to test 653 whether the addresses on his list are valid (VRFY) and even get more 654 addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed 655 to issue these commands. This may be "on/off" or it may use access 656 lists similar to those mentioned previously. Default for both should 657 be "off". 659 2.12. SMTP ETRN 661 SMTP ETRN means that the MTA will re-run its mail queue, which may be 662 quite costly and open for Denial of Service attacks. Therefore, the 663 MTA SHOULD control who is is allowed to issue the ETRN command. This 664 may be "on/off" or it may use access lists similar to those mentioned 665 previously. Default should be "off". 667 2.13. Return Codes 669 The primary issue here is flexibility - it is simply not possible to 670 define in a document how to make tradeoffs between returning 5xx and 671 make legitimate mail fail at once due to a configuration mistake and 672 returning 4xx and be able to catch such configuration mistakes via 673 log file inspection. 675 Therefore, the MTA MUST be configurable to provide different Return 676 Codes, 5xx / 4xx / 2xx, for different rules or policies. 678 However, when the response is the result of a DNS lookup and the DNS 679 system returned TempFail, a temporary error, the MTA MUST reflect 680 this and provide a 4xx return code. If the DNS response is an 681 Authoritative NXdomain (host or domain unknown) the MTA MAY reflect 682 this by a 5xx Return Code. 684 Please refer to the previous discussion on SMTP Return Codes. 686 2.13.1. The importance of flexibility - an example 688 At Chalmers University of Technology our DNS contains 690 cdg.chalmers.se. IN MX 0 mail.cdg.chalmers.se. 691 IN MX 100 mail.chalmers.se. 693 and similarly for most subdomains, i.e. a second host to store mail 694 to each subdomain, should their mail host be down. This means that 695 mail.chalmers.se must be prepared to act as Mail Relay for the 696 subdomains ("RCPT To:") it serves and that those subdomains' mail 697 hosts have to accept SMTP connections from mail.chalmers.se. Late 698 versions of spam software make use of this fact by always using 699 mail.chalmers.se to get their mail delivered to our subdomains and by 700 doing so they still get Mail Relaying done for them and they prevent 701 recipient hosts from refusing SMTP connections based on the sending 702 host's FQDN or IP-address. 704 As long as we keep our design with a secondary MX host we cannot 705 really have mail.chalmers.se refuse Mail Relay, at least not with a 706 5xx return code. However, it has been fairly straight forward to 707 identify the hosts/domains/networks that make use of this possibility 708 and refuse to act as Mail Relay for them them - and only them - and 709 do so with a 4xx return code. Legitimate mail from them may be 710 delayed if the final recipient host is down but will eventually be 711 delivered when it gets up again (4xx Return Code) and this is no 712 worse then if we changed our MX design. Spam now faces a "Denied" 713 response and have to connect to each and every one of the recipients, 714 who may decide to refuse the SMTP connection. 716 The bottom line is that this is made possible because of 1) enough 717 flexibility in the Relay Authorization code and 2) enough flexibility 718 in assigning Return Codes - an MTA with a 5xx Return Code carved in 719 stone would have made this absolutely impossible. 721 3. Future work 723 3.1. Impact on SMTP UAs and end users 725 Despite this memo is about MTAs and recommendations for them, some of 726 what is done here falls back to the UAs (User Agents, the "ordinary 727 mail programs"). 729 A UA does two things: 731 1) Reads mail from a mailbox and prints on the screen. 732 This typically uses a protocol like POP, IMAP or NFS. 734 2) Reads text from the keyboard and hands that over to the 735 mailbox MTA for delivery as a piece of mail. This typically 736 uses the SMTP protocol, i.e. the same protocol that is used 737 between MTAs. 739 When MTAs now start to implement various anti-relay filters as 740 described above, a UA on a portable laptop host may get a response 741 like "Relaying Denied" just because it happens to use IP addresses 742 within an unknown range or that resolve to unknown FQDNs. 744 The typical victim of this "Relaying Denied" response is a salesman 745 carrying a laptop on a business trip, or even an IETF delegate at a 746 meeting hotel. The salesman will probably dial his nearest ISP and 747 will get an IP address from that dialup pool; the IETF delegate will 748 use an IP address for the terminal room. In both cases their laptop 749 mail program (the UA; e.g. pine, Netscape, Eudora) will try to send 750 out mail via their home MTA, e.g. SMTP-SERVER=mail.home.example, but 751 unless mail.home.example has been updated to accept that (temporary) 752 IP address it will respond "Relaying Denied" and refuse. 754 To get around this problem we could simply add the terminal room's or 755 the dialup pool's IP network to the list of accepted networks at 756 mail.home.example. This does open up some minimal risk of spammers 757 using that host as their Mail Relay: If they use the same ISP's 758 dialup pool and they configure to use mail.home.example at the same 759 time as our salesman is on his trip, then the spammers will be 760 authorized to relay their spam through mail.home.example. However, 761 this is not extremely likely and as long as we do not open up for the 762 entire world all the time and we keep the log files under close 763 observation and we stop relaying at once we find we're being used, 764 this solution is probably good enough. 766 Another way around is that our salesman uses a Mail Relay provided by 767 the current dialup ISP, if that service exists. To do so he has to 768 modify SMTP-SERVER= in his UA, which may or may not be reasonable. 770 The correct way to handle this situation, though, is by some other 771 mail-sending protocol between the UA and the MTA. Although not 772 officially standardized, there are the "XTND XMIT" extensions to POP3 773 [7] and the "Message Submission" IETF draft [8]. 775 Or, we could note that when the SMTP Authentication work is all in 776 place, it will allow for Authenticated SMTP to serve as The Protocol 777 between the UAs and the home MTA (whether that should be considered a 778 new protocol or "the same old SMTP" is irrelevant here). 780 This adds one item to the suggested Relay algorithm: 782 + If "SMTP Authenticated" then accept to Relay. 784 3.2. Personal anti-spam filters 786 Since all users are individuals, there is little hope that any 787 central anti-spam action will suit them all - in fact one could argue 788 about Freedom of Speech if some central set of anti-spam rules is 789 enforced without the users' approval (one could of course also argue 790 whether spam really adds anything to anyone, but that must be up to 791 each individual user rather than centrally decided). 793 Therefore the only reasonable extension is to allow for personal 794 anti-spam filters, i.e. anti-spam filters like the ones described 795 earlier in this memo, but available and configurable on a per user 796 basis. Since most users will not have a strong opinion (except that 797 they want to avoid spam) the mail system should provide a system 798 default and give each user the ability to override or modify that. 799 In a UNIX based environment one could think of 801 /etc/mail/rc.spam 802 ~/.spamrc 804 and rules on how the latter can interfere with the former. 806 All of this opens up quite a number of unresolved issues, e.g. 807 whether each user himself really should be allowed to decide on SMTP 808 Return Codes (and how it should be described so he understands enough 809 of the implications) and how existing mail systems will deal with 810 different per user responses, especially how they will deal with a 811 mix of 5xx and 4xx codes: 813 C MAIL From: 814 S 250 ... Sender ok 815 C RCPT To: 816 S 250 ... Recipient ok 817 C RCPT To: 818 S 451 ... Denied due to spam list 819 C RCPT To: 820 S 550 ... Denied due to spam list 822 Of course one could decide on either "250 OK" or "550 Denied" with no 823 other alternatives for the individual user, but this too has to be 824 explained enough that an ordinary user understands the implications 825 of "Refuse 'MAIL From: <.*@spam.example>'" and that it can do away 826 with, or block out, mail he actually wanted. 828 3.3. SMTP Authentication 830 SMTP Authentication has already been mentioned as a method to 831 authorize Mail Relaying, but of course there is much more to it than 832 that. When that infrastructure and functionality is all in place, 833 spammers will have a much harder time forging addresses and hiding. 835 3.4. SMTP Label 837 A lot of the problem with spam is actually that it is so completely 838 "blind", without any relation to the receivers' personal interest and 839 that there is no easy way to say "No Thank You". 841 One way things could evolve is that spam is taken care of by legal 842 means, e.g. making it illegal to send unsolicited commercial email 843 and make that happen world wide. Not very likely, but anyway. 845 Another way would be to accept that spam/UCE will continue to exist, 846 accept it legally (just like we accept the pile of paper mail that 847 clutters up the paper mail mailbox) but require it be tagged as UCE. 848 This would then go along the lines of personal anti-spam filters 849 (~/.spamrc) where each user could define what kind of UCE he is 850 willing to accept and then have an "SMTP Label" code that could match 851 his areas of interest. This also goes quite well with the various 852 rules and regulations used by International Telemarketing. The SMTP 853 dialogue would then be: 855 S 220 host.domain.example Ready 856 C HELO host.uce.example 857 S 250 host.domain.example Hello host.uce.example 858 C SMTP Label: UCE; money, porno 859 S 250 Label accepted 860 C MAIL From: 861 S 250 ... Sender ok 862 C RCPT To: 863 S 250 ... Recipient ok 864 C RCPT To: 865 S 550 ... No thanks, not for me 867 Having the test at the SMTP layer means we may not need to receive a 868 copy of the mail in question - if all potential receivers say "550" 869 the SMTP session is terminated without data copy. 871 This requires adding more functionality to (E)SMTP, which is IETF 872 controlled. It also needs some legal support to handle the case 874 SMTP Label: mail; personal 876 although it is really spam/UCE. This can be done on a legal basis 877 (which may be hard in the international context, but is still much 878 easier than making spam per se illegal). Or, it can be put into the 879 ISP's contract with its customers, just like most ISPs today have 880 contracts against customers sending spam. 882 3.5. Spam and NATs 884 With the increased use of NATs, Network Address Translators, may come 885 a need for additional information in log files. As long as there is 886 an 1:1 mapping between the addresses inside the NAT and the addresses 887 used outside it everything is OK, but if the NAT box also translates 888 port numbers (to combine many internal hosts into one external 889 address) we will need to log not only the IP addresses of spam hosts 890 but also the port numbers. Otherwise we will not be able to identify 891 the individual host inside the NAT. 893 4. Security Considerations 895 The grassfire-like increase of spam raises several security issues 896 which, in fact, puts the entire Internet mail community at risk: 898 o People may fail to find important mail in their flooded 899 mailboxes. Or, they may delete it while cleaning up. 901 o ISPs get mailbox hosts overloaded and disk filled. Cleaning 902 up and helping customers requires a lot of human resources. 903 In fact, ISP mail servers have crashed by too much mail. 905 o While disks are unaccessible, either due to being filled or 906 due to "mail quota", important mail may be delayed or lost. 907 Normally this would not happen without notice, but if both 908 the sender and receiver hosts have their disk flooded, the 909 mail being returned may also fail, i.e. the email service may 910 become less trustworthy then before. 912 o Hosts used as unauthorized Mail Relays get overloaded. Besides 913 the technical implications, this too requires a lot of human 914 resources, cleaning up mail queues and taking care of furious 915 external users that were spammed through the Relay. 917 o The fight against spammers include blocking their hosts (which 918 is described in this memo). However, there is a great risk 919 that Mail Relay hosts be blocked too, despite they are also 920 victims. In the long run, this may deteriorate Internet mail. 922 o The common use of forged "MAIL From:" and "From:" addresses 923 puts the blame on innocent persons/hosts/organizations. This 924 is bad for reputation and may affect business relations. 926 5. Acknowledgements 928 This memo is the result of discussions in an ad hoc group of Swedish 929 ISPs and Universities. Without hope to mention everyone we simply 930 give the domain names here: algonet.se, global-ip.net, pi.se, 931 swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, and 932 uu.se. 934 We want to acknowledge valuable input and suggestions from Andras 935 Salamon, John Myers, Bob Flandrena, Dave Presotto, Dave Kristol, 936 Donald Eastlake, Ned Freed, Keith Moore and Paul Hoffman. 938 Finally many thanks to Harald Alvestrand for support and guidance 939 through the IETF process. 941 6. References 943 [1] RFC 821 944 Jonathan B. Postel "Simple Mail Transfer Protocol", August 1982. 946 [2] RFC 822 947 David H. Crocker "Standard for the format of ARPA Internet 948 text messages", August 1982. 950 [3] RFC 1123 951 R.T. Braden "Requirements for Internet hosts - application 952 and support", Oct-01-1989. 954 [4] RFC 2119 955 S. Bradner "Key words for use in RFCs to Indicate Requirement 956 Level", March 1997. 958 [5] RFC 2065 959 D. Eastlake, 3rd, C. Kaufman "Domain Name System Security 960 Extensions", January 1997. 962 [6] sendmail Home Page. 963 http://www.sendmail.org 965 [7] POP3 extensions 966 http://musicm.mcgill.ca/~MSI/HTTP/pop3xtndxmit.html 968 [8] R. Gellens, J. Klensin "Message Submission", 2 June 1998. 969 Internet Draft: draft-gellens-submit-08.txt 971 * spam (R) is a registered trademark of a meat product made by 972 Hormel. Use of the term spam in the Internet community comes 973 from a Monty Python sketch and is almost Internet folklore. 974 The term spam is usually meant negative, however this is not 975 in any way intended to describe the Hormel product. 977 Editor's Address 979 Gunnar Lindberg 980 Computer Communications Group 981 Chalmers University of Technology 982 S-412 96 Gothenburg, SWEDEN, 983 Phone +46 31 772 5913 984 FAX +46 31 772 5922 985 lindberg@cdg.chalmers.se