INTERNET-DRAFT Gunnar Lindberg draft-lindberg-anti-spam-mta-02.txt Chalmers University Expires July, 1998 of Technology 6 Feb 1998 Anti-Spam Requirements on an SMTP MTA Abstract This memo gives a number of technical requirement on SMTP [1] MTAs (Mail Transfer Agents, e.g. sendmail) to make them more capable of reducing the impact of spam(*). The intent is that these requirements will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these requirements were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. Some ideas are presented in the Future Work section. A brief summary of this memo is: o Stop unauthorized mail relaying. o Spammers then have to operate in the open; deal with them. o Design a mail system that can handle spam. Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Comments on this draft should be sent to . Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 1] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 1. Introduction This memo is intended to become a Best Current Practice (BCP) RFC. As such it should be used as a guideline for SMTP MTA vendors to make their products more capable of preventing/handling spam. 1.1. Background Mass unsolicited electronic mail, often known as spam(*), has increased considerably during a short period of time and has become a serious threat to the Internet email community as a whole. Something needs to be done fairly quickly. The problem has several components: o It is high volume, i.e. people get a lot of such mail in their mailboxes. o It is completely "blind", i.e. there is no correlation between the receivers' areas of interest and the actual mail sent out (at least if one assumes that not everybody on the Internet is interested in porno pictures and spam programs...). o It costs real money for the receivers. Since many receivers pay for the time to transfer the mailbox from the (dialup) ISP to their computer they in reality pay real money for this. o It costs real money for the ISPs. Assume one 10 Kbyte message sent to 10 000 users with their mailboxes at one ISP host; that means an unsolicited, unexpected, storage of 100 Mbytes. State of the art disks, 4 Gbyte, can take 40 such message floods before they are filled. It is almost impossible to plan ahead for such "storms". o Several of the senders are anything but serious, e.g hide behind false addresses or mail hosts that refuse to receive. In fact many of the spam-programs show a pride in adding false info that will "make the ISPs scratch their heads". It is not uncommon that people who send in protests (often according to the instructions in the mail) find their mail addresses added to more lists and sold to other parties. o It is quite common practice to make use of third party hosts as relays to get the spam mail sent out to the receivers. This is almost certainly illegal in all countries, but with the original sender in the US, the (innocent) relay in Sweden and Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 2] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 the list of receivers back in the US the legal aspects become almost overhelming. 1.2. Scope This memo has no intent to be the final solution to the spam problem. If, however, enough Internet MTAs did implement enough of the rules described below (especially the Non-Relay rules), we would get the spammers out in the open, where they could be taken care of. Either pure legal actions would help, or we can block them technically using other rules described below (since the Non-Relay rules now make them appear openly, with their own hosts and domains, we can apply various access filters against them). In reality, a combination of legal and technical methods is likely to give the best result. This way, the spam problem could be reduced enough to allow the Internet community to design and deploy a real and general solution. 1.3. Terminology Throughout this memo we will use the terminology of RFC2119, [4]: o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement. o "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. o "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 1.4. Using DNS information In the memo we sometimes suggest use of host or domain names, FQN, rather than IP addresses. This is because FQN are intuitively much easier to use. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 3] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 However, all such usage depends heavily on DNS and .IN-ADDR.ARPA information. Since it is fairly easy to forge that, either by false cache information injected in DNS servers or spammers running their own DNS, host and domain names must be used with care, e.g. verify that the translation address->name corresponds to name->address. 1.5. SMTP Return Codes Our basic assumption is that refuse/accept is handled at the SMTP layer and that an MTA that decides to refuse a message should do so while still in the SMTP dialogue. First, this means that we do not have to store a copy of a message we later decide to refuse and second, our responsibility for that message is low or none - since we have not yet read it we leave it to the sender to handle the error. SMTP has several classes of Return Codes, see [1] for a discussion: o 5xx is a Fatal Error and results in the mail transfer being terminated and the mail returned to sender. For some events, like "Denied - you're on the spammer's list", this is probably the correct response and the right thing to say. A mistake in configuration, however, may cause valid mail to bounce back to the sender, which may be quite unfortunate. o 4xx is a Temporary Error and results in the mail transfer being put back on queue again and a new attempt being made later. Therefore, configuration mistakes are much less fatal and you may correct them before any real damage is done. A 4xx response also makes the spammer's host re-queue the mail and if it really is his own host who gets to do this, it is probably a good thing. If, on the other hand, he is using someone else as Relay Host, all the mail being queued is a fairly strong evidence that something illegal is going on and should cause attention at the Relay Host. 4xx, Temporary Error, is almost always the recommended Return Code, since it both allows us to correct our mistakes and keeps the spam mail in the mail queue at the sender for a longer period of time. However, 4xx Temporary Errors may have unexpected interaction with MX-records. If the receiving domain has several MX records and the lowest preference MX-host refuses to receive mail from a certain "MAIL From" domain with a "451" Response Code, the sending host may choose to - and often will - use the next host on the MX list. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 4] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 If that next MX host does not have the same refuse-list, it will of course accept the mail, only to find that the final host still refuses to receive that piece of mail ("MAIL From"). I.e. our intent was to make the offending mail stay at the offending sender's host and fill up his mqueue disk, but it all ended up at our friend, the next lowest preference MX-host. 2. Requirements Here we first give a brief list of requirements, followed by a more thorough discussion of each of them. 1) MUST be able to restrict unauthorized use as Mail Relay. 2) MUST provide "Received:" lines with enough information to make it possible to trace the mail path, despite spammers use forged host names in HELO statements etc. 3) MUST provide local log information that makes it possible to trace the event afterwards. 4) SHOULD log all occurrences of anti-relay/anti-spam actions. 5) SHOULD be able to refuse mail from a host / a group of hosts. 6a) SHOULD be able to refuse mail from a specific "MAIL From" user, . 6b) SHOULD be able to refuse mail from an entire "MAIL From" domain <.*@domain.example>. 7) SHOULD be able to limit ("rate control") mail flow. 8) SHOULD be able to verify "MAIL From" domain (using DNS or using other means). 9) SHOULD be able to verify in outgoing mail. 10) MUST be able to configure for different Return Codes for different rules (e.g. 451 Temp Fail vs 551 Fatal Error). 11) SHOULD be able to authorize mailing list usage. The discussion below often ends up in a need to do various forms of pattern matching, on domain/host names and on IP addresses/subnets. It is RECOMMENDED that the data/template for doing so may be supplied outside of the MTA, e.g. that the pattern matching rules be included in the MTA but that the actual patterns may be in an external file. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 5] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 It is also RECOMMENDED that the pattern matching rules (external file) may contain regular expressions, to give maximum flexibility. Of course all string matching on domain/host names MUST be non case sensitive. Since may be case sensitive it may be natural to keep that here. However, since and is most probably the same user and since the string compares are used to refuse his messages, we suggest that be compared non case sensitive too. 2.1. Restricting unauthorized Mail Relay usage Unauthorized usage of a host as Mail Relay means theft of the relay's resources and puts the owner's reputation at risk. It also makes it impossible to filter out or block spam without at the same time blocking legitimate mail. Therefore, the MTA MUST be able to control/refuse such Relay usage. In an SMTP session we have 3 elements, with a varying degree of trust: 1) "MAIL From:" Easily and often forged. 2) "RCPT To:" Correct, or at least intended. 3) "SMTP Caller" (host) IP.src addr OK, FQN may be OK. Since 1) is so easily and often forged, we cannot depend on that at all to authorize usage of our host as Mail Relay. Instead, the MTA MUST be able to authorize Mail Relay usage based on a combination of: o "RCPT To" address (domain). o "SMTP Caller" FQN hostname. o "SMTP Caller" IP address. The suggested algorithm is: a) If "RCPT To" is one of "our" domains, local or a domain that we accept to forward to (alternate MX), then accept to Relay. b) If "SMTP Caller" is authorized, either its IP.src or its FQN (depending on if you trust the DNS), then accept to Relay. c) Else refuse to Relay. When doing a) you have to make sure all kinds of SMTP source routing (both the official [@a,@b:u@c] and the '%' hack) is either removed Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 6] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 completely before the test, or is at least not taken into account. In all cases the configuration MUST support wild cards for FQNs and classful IP addresses and SHOULD support "address/mask" for classless IP addresses, e.g. domain.example and *.domain.example; 10.11.*.*, 192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23. The configuration SHOULD allow for the decision/template data to be supplied by an external source, e.g. text file or dbm database. The decision/template SHOULD be allowed to contain regular expressions. 2.2. Received: lines The MTA MUST prepend a "Received:" line in the mail (as described in RFC822, [2], and required in RFC1123, [3]). This "Received:" line MUST contain enough information to make it possible to trace the mail path back to the sender. We have two cases: 2.2.1. Direct MTA-to-MTA connections Internet mail was designed such that the sending host connects directly to the recipient as described by MX records (there may be several MX hosts on a priority list). To assure traceability back to the sending host (which may be a firewall/gateway, as described later) each MTA along the path, including the final MTA, MUST prepend a "Received:" line. Such a "Received:" line MUST contain: o The IP address of the caller. o The 'date-time' as described in RFC822, [2], pp 18. It SHOULD contain: o The FQN corresponding to the callers IP address. o The argument given in the "HELO" statement. It is suggested that most other "Received:" fields described in RFC822 be included in the "Received:" lines. These requirements are deliberately stronger than RFC1123, [3], and are there to assure that mail sent directly from a spammer's host to a recipient can be traced with enough accuracy; a typical example is when a spammer uses a dialup account and the ISP needs to have his IP address at the 'date-time' to be able to take action against him. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 7] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 2.2.2. Firewall/gateway type devices Organizations with a policy to hide their internal network structure must still be allowed and able to do so. They usually make their internal MTAs prepend "Received:" lines with a very limited amount of information, or prepend none at all. They then send out the mail through some kind of firewall/gateway device, which may even remove all the internal MTAs' "Received:" lines before it prepends its own "Received:" line (as required in RFC1123, [3]). By doing so they take on the full responsibility to trace spammers that send from inside their organization. It is REQUIRED that the information provided in their outgoing mail is sufficient for them to perform such traces. 2.3. Event logs The MTA MUST provide enough local log information to make it possible to trace the event. This includes most of the information put into the "Received:" lines, see above. 2.4. Log anti-relay/anti-spam actions The MTA SHOULD log all anti-relay/anti-spam actions. The log entries SHOULD contain at least: o Time information. o Refuse information, i.e. why the request was refused ("Mail From", "Relaying Denied", "Spam User", "Spam Host", etc). o "RCPT To" addresses (domains). o Offending host's IP address. o Offending host's FQN hostname. o Other relevant information (e.g. given during the SMTP dialogue, before we decided to refuse the request). 2.5. Refuse mail based on SMTP Caller address The MTA SHOULD be able to accept or refuse mail from a specific host or from a group of hosts. Here we mean the IP.src address or the FQN that its .IN-ADDR.ARPA resolves to (depending on whether your trust the DNS). This functionality could be implemented at a firewall, but since the MTA should be able to "defend itself" we require it here. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 8] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 It is RECOMMENDED that the MTA decide based on FQN hostnames (host.domain.example), on wild card domain names (*.domain.example), on individual IP addresses (10.11.12.13) or on IP addresses with a prefix length (10.0.0.0/8, 192.168.1.0/24). It is also RECOMMENDED that these decision rules can be combined to form a flexible list of accept/refuse/accept/refuse, e.g: accept host.domain.example refuse *.domain.example accept 10.11.12.13 accept 192.168.1.0/24 refuse 10.0.0.0/8 IP-address/length is RECOMMENDED. However, implementations with wild cards, e.g. 10.11.12.* (classful networks on byte boundaries only) are of course much better then those without. To improve filtering even more, the MTA MAY provide complete regular expressions to be used for hostnames; possibly also for IP addresses. 2.6. Refuse based on "MAIL From" The MTA SHOULD be able to refuse to receive mail from a specific "MAIL From" user (foo@domain.example) or from an entire "MAIL From" domain (domain.example). In general this kind of rules are easily overcome by the spammers changing "MAIL From" every so often, but the ability to block a certain user or a certain domain is quite helpful while an attack has just been discovered and is ongoing. 2.7. Rate Control The MTA SHOULD provide tools for the mail host to control the rate with which mail is sent or received. The idea is twofold: 1) If we happen to have an legitimate mail user with an existing legitimate account and this user sends out spam, we may want to reduce the speed with which he sends it out. This is not without controversy and must be used with extreme care, but it may protect the rest of the Internet from him. 2) If we are under a spam attack it may help us considerably just being able to slow down the incoming mail rate for that particular user/host. For sending mail, this has to be done by throttling the TCP connection to set the acceptable output data rate, e.g. reduce the "write()" frequency. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 9] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 For receiving mail, we could use basically the same technique, e.g. reduce the "read()" frequency, or we could signal with a 4xx Return Code that we cannot receive. It is RECOMMENDED that the decision to take such action be based on "MAIL From" user, "MAIL From" domain, "SMTP Caller" (name/address) or a combination of all these. 2.8. Verify "MAIL From" The MTA SHOULD be able to perform a simple "sanity check" of the "MAIL From" domain and refuse to receive mail if that domain is nonexistent. To overcome temporary errors/problems in the DNS, 4xx Return Codes are strongly recommended; however the MTA MAY allow for Return Codes that show real DNS state - 4xx for temporary problems and 5xx for NonExistent domain. In all honesty, please note that this requirement and ability is a mixed blessing and should be used with extreme care. For early versions of spam spam software it does provide quite some relief, since that software generates mail with completely bogus "MAIL From" that will never even get into the system. On the other hand, sites with weak DNS connectivity may find their legitimate mail having problems reaching destinations due to DNS timeouts. However, since DNS information is handled asynchronously and is cached even though the initial requester has given up, chances are high that the necessary information is there at a later attempt. For later versions of spam software, a check of "MAIL From" is much less likely to help, since that software evolves too and will start using existing mail addresses (whether or not that is legal is beyond the scope of this memo). But, at least the Internet will benefit from the side effect that this test stops typos and misconfigured UAs. 2.9. Verify The MTA SHOULD allow outgoing mail to have its verified so that the sender name is a real user or an existing alias. This is basically to protect the rest of the Internet from various "typos" MAIL From: and/or malicious users MAIL From: As always this can be overcome by spammers really wanting to do so, but with more strict rules for relaying it becomes harder and harder. In fact, catching "typos" at the initial (and official) mail relay is in itself enough motivation for this requirement. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 10] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 2.10. Return Codes The MTA MUST be configurable to use different Return Codes for different rules (e.g. 451 Temporary Failure vs 551 Fatal Error). Please refer to the previous section on SMTP Return Codes. 2.11. Mailing Lists An MTA that also has the ability to handle mailing lists and expand that to a number of recipients, SHOULD be able to authorize senders. Despite "MAIL From" is very easy to forge we have no alternative, so authorization will have to be based on "MAIL From". The following options are suggested: o Allow all members in the list. o Allow all members and an additional list of senders. Violations could be handled in different ways (combinations of): o A "5xx" error code and information in a log file. o Forwarding the violating mail to the list owner. o Forwarding the violating mail to some other address. 3. Future work 3.1. Impact on SMTP UAs and end users Despite this memo is about MTAs and the requirements put on them, some of what is done here falls back to the UAs (User Agents, the "ordinary mail programs"). A UA does two things: 1) Reads mail from a mailbox and prints on the screen. This typically uses a protocol like POP, IMAP or NFS. 2) Reads text from the keyboard and hands that over to the mailbox MTA for delivery as a piece of mail. This typically uses the SMTP protocol, i.e. the same protocol that is used between MTAs. When MTAs now start to implement various anti-relay filters as described above, a UA on a portable laptop host may get a response like "Relaying Denied" just because it happens to use IP addresses Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 11] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 within an unknown range or that resolve to unknown FQNs. The typical victim of this "Relaying Denied" response is a salesman carrying a laptop on a business trip, or even an IETF delegate at a meeting hotel. The salesman will probably dial his nearest ISP and will get an IP address from that dialup pool; the IETF delegate will use an IP address for the terminal room. In both cases their laptop mail program (the UA; e.g. pine, Netscape, Eudora) will try to send out mail via their home MTA, e.g. SMTP-SERVER=mail.home.example, but unless mail.home.example has been updated to accept that (temporary) IP address it will respond "Relaying Denied" and refuse. To get around this problem we could simply add the terminal room's or the dialup pool's IP network to the list of accepted networks at mail.home.example. This does open up some minimal risk of spammers using that host as their Mail Relay: If they use the same ISP's dialup pool and they configure to use mail.home.example at the same time as our salesman is on his trip, then the spammers will be authorized to relay their spam through mail.home.example. However, this is not extremely likely and as long as we do not open up for the entire world all the time and we keep the log files under close observation and we stop relaying at once we find we're being used, this solution is probably good enough. Antoher way around is that our salesman uses a Mail Relay provided by the current dialup ISP, if that service exists. To do so he has to modify SMTP-SERVER= in his UA, which may or may not be reasonable. The correct way to handle this situation, though, is by some other mail-sending protocol between the UA and the MTA. Although not officially standardized, one such protocol is the "XTND XMIT" extensions to POP3 [6]. Or, we could note that when the SMTP Authentication work is all in place, it will allow for Authenticated SMTP to serve as The Protocol between the UAs and the home MTA (whether that should be considered a new protocol or "the same old SMTP" is irrelevant here). This adds one item to the suggested Relay algorithm: + If "SMTP Authenticated" then accept to Relay. 3.2. Personal anti-spam filters Since all users are individuals, there is little hope that any central anti-spam action will suit them all - in fact one could argue about Freedom of Speech if some central set of anti-spam rules is enforced without the users' approval (one could of course also argue Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 12] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 whether spam really adds anything to anyone, but that must be up to each individual user rather than centrally decided). Therefore the only reasonable extension is to allow for personal anti-spam filters, i.e. anti-spam filters like the ones described earlier in this memo, but available and configurable on a per user basis. Since most users will not have a strong opinion (except that they want to avoid spam) the mail system should provide a system default and give each user the ability to override or modify that. In a UNIX based environment one could think of /etc/mail/rc.spam ~/.spamrc and rules on how the latter can interfere with the former. All of this opens up quite a number of unresolved issues, e.g. whether each user himself really should be allowed to decide on SMTP Return Codes (and how it should be described so he understands enough of the implications) and how existing mail systems will deal with different per user responses, especially how they will deal with a mix of 5xx and 4xx codes: C MAIL From: S 250 ... Sender ok C RCTP To: S 250 ... Recipient ok C RCTP To: S 451 ... Denied due to spam list C RCTP To: S 551 ... Denied due to spam list Of course one could decide on either "250 OK" or "551 Denied" with no other alternatives for the individual user, but this too has to be explained enough that an ordinary user understands the implications of "Refuse 'MAIL From: <.*@spam.example>'" and that it can do away with, or block out, mail he actually wanted. 3.3. SMTP Authentication SMTP Authentication has already been mentioned as a method to authorize Mail relaying, but of course there is much more to it than that. When that infrastructure and functionality is all in place, spammers will have a much harder time forging addresses and hiding. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 13] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 3.4. SMTP ContentType A lot of the problem with spam is actually that it is so completely "blind", without any relation to the receivers' personal interest and that there is no easy way to say No Thank You. One way things could evolve is that spam is taken care of by legal means, e.g. making it illegal to send unsolicited commercial email and make that happen world wide. Not very likely, but anyway. Another way would be to accept that spam/UCE will continue to exist, accept it legally (just like we accept the pile of paper mail that clutters up the paper mail mailbox) but require it be tagged as UCE. This would then go along the lines of personal anti-spam filters (~/.spamrc) where each user could define what kind of UCE he is willing to accept and then have an "SMTP ContentType" code that could match his areas of interest, e.g: S 220 host.domain.example Ready C HELO host.uce.example S 250 host.domain.example Hello host.uce.example C SMTP ContentType: UCE; money, porno S 250 ContentType accepted C MAIL From: S 250 ... Sender ok C RCPT To: S 250 ... Recipient ok C RCPT To: S 551 ... No thanks, not for me Besides all issues of entering more functionality into SMTP, a major problem with this idea is how to handle people claiming SMTP ContentType: mail; personal although it is really spam/UCE. This is a non technical issue that must be resolved, although that may be hard or even impossible. 4. Security Considerations The grassfire-like increase of spam raises several security issues which, in fact, puts the entire Internet mail community at risk: o People may fail to find important mail in their flooded mailboxes. Or, they may delete it while cleaning up. o ISPs get mailbox hosts overloaded and disk filled. Cleaning up and helping customers requires a lot of human resources. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 14] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 o While disks are unaccessible, either due to being filled or due to "mail quota", important mail may be delayed or lost. Normally this would not happen without notice, but if both the sender and receiver hosts have their disk flooded, the mail being returned may also fail, i.e. the email service may become less trustworthy then before. o Hosts used as unauthorized Mail Relays get overloaded. Besides the technical implications, this too requires a lot of human resources, cleaning up mail queues and taking care of furious external users that were spammed through the Relay. o The fight against spammers include blocking their hosts (which is described in this memo). However, there is a great risk that Mail Relay hosts be blocked too, despite they are also victims. In the long run, this may deteriorate Internet mail. o The common use of forged "MAIL From" and "From:" addresses puts the blame on innocent persons/hosts/organizations. This is bad for reputation and may affect business relations. 5. Acknowledgements This memo is the result of discussions in an ad hoc group of Swedish ISPs and Universities. Without hope to mention everyone we simply give the domain names here: algonet.se, global-ip.net, pi.se, swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, and uu.se. We want to acknowledge valuable input and suggestions from Andras Salamon, John Myers, Bob Flandrena, Dave Presotto and Dave Kristol. 6. References [1] Jonathan B. Postel "Simple Mail Transfer Protocol; RFC821", August 1982. Available via anonymous ftp at ftp://ds.internic.net/rfc/rfc821.txt [2] David H. Crocker "Standard for the format of ARPA Internet text messages; RFC822", August 1982. Available via anonymous ftp at ftp://ds.internic.net/rfc/rfc822.txt [3] R.T. Braden "Requirements for Internet hosts - application and support; RFC1123", Oct-01-1989. Available via anonymous ftp at ftp://ds.internic.net/rfc/rfc1123.txt Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 15] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 [4] S. Bradner "Key words for use in RFCs to Indicate Requirement Level; RFC2119", March 1997. Available via anonymous ftp at ftp://ds.internic.net/rfc/rfc2119.txt [5] sendmail Home Page. http://www.sendmail.org [6] POP3 extensions http://musicm.mcgill.ca/~MSI/HTTP/pop3xtndxmit.html * spam (R) is a registered trademark of a meat product made by Hormel. Use of the term spam in the Internet community comes from a Monty Python sketch and is almost Internet folklore. The term spam is usually meant negative, however this is not in any way intended to describe the Hormel product. Editor's Address Gunnar Lindberg Computer Communications Group Chalmers University of Technology S-412 96 Gothenburg, SWEDEN, Phone +46 31 772 5913 FAX +46 31 772 5922 lindberg@cdg.chalmers.se Appendix A1. sendmail example The main purpose of the memo is to define a set of requirements that will help reduce spam. It is not intended to describe how to do that for any particular MTA. However, many of us use and are familiar with sendmail [5] and therefore we provide some hints; these require late versions of sendmail-8.8.* (when this was written, 6 Feb 1998, sendmail-8.8.8 was the latest). The example neither makes a claim to solve the problem nor to be correct and you use it at your own risk. These examples all use Return Code "451", Temp Fail. Please read that section above once more and verify that you will not hit your friends, your next lowest preference MX-hosts, that may have different rules. Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 16] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 (NB sendmail makes a difference between and used as separators; if you use cut-and-paste from this memo you are likely to get everywhere). ################################################################## # Deny spammers, single users or entire domains Kspammers dbm -o /etc/mail/spammers.db # ### # In "class S" you enter hosts you consider to be spammers, either # FQN (if you trust the DNS) or IP addresses (better). Since FQN # and IP addresses do not look the same, we keep them both here. # We use simple pattern matching and thus IP addresses only match # on byte boundaries, i.e. /24 prefixes. # # If you want to make the test "recursive" and to do so you just # remove the comments at the "Rec" lines below. # # FS/etc/mail/sendmail.cS CS # Scheck_mail # check for valid domain name (name exists within DNS) R<$* .> $: <$1> Drop fake trailing '.' R$* . $: $1 Drop fake trailing '.' R$* $: $>3 $1 ifdef(`_NO_CANONIFY_', ` # pass to name server to make hostname canonical # (done here if we have "nocanonify", in S3-S96 otherwise) R$* < @ $* $~P > $* $: $1 < @ $[ $2 $3 $] > $4 ') R$* < @ $*domain.com .> $: $1<@$2domain.com> sigh R$* < @ $+ . > $: <$1@$2> OK R$* < @ $+ > $#error $: 451 Domain must resolve # #R$* $@ OK return from here if you # have no spammers check ### # check user@dom.ain and dom.ain versus spammers database R<$* @ $+> $: $1<@$2> re-focus # user@dom.ain R$* < @ $+ > $: $1<@$2><$(spammers $1@$2 $:OK $)> R$* < @ $+ > $: $1<@$2> R$* < @ $+ ><$* @ $+> $#error $: 451 Denied due to spam-list # dom.ain R$* < @ $+ > $: $1<@$2><$(spammers $2 $:OK $)> R$* < @ $+ > $: $1<@$2> R$* < @ $+ ><$+> $#error $: 451 Denied due to spam-list Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 17] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 ### # get sender's host name R$* $: $(dequote "" $&{client_name} $) R$=S $@ $#error $: 451 Denied $1 #R$+.$=S $@ $#error $: 451 Denied $1.$2 Rec ### # get sender's IP address R$* $: $(dequote "" $&{client_addr} $) R$=S $#error $: 451 Denied $1 #R$=S.$- $#error $: 451 Denied $1.$2 Rec #R$=S.$-.$- $#error $: 451 Denied $1.$2.$3 Rec #R$=S.$-.$-.$- $#error $: 451 Denied $1.$2.$3.$4 Rec ### R$* $@ OK ################################################################## Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 18] draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 In the example below we use "CD" ("$=D") dual purpose, both for the domains (subdomains) we accept to relay into and the hosts that we accept use us as their Mail Relay. It is of course trivial to split that into two different classes, if needed. ################################################################## # In "class D" you enter domains and hosts for two purposes # 1) You accept to relay mail TO them (MX). # 2) You accept to relay mail FROM them (SmartHost). # In both cases, this is "recursive", i.e. foo.se -> *.foo.se #FD/etc/mail/sendmail.cD CD # # In "class B" you enter the "exceptionally bad guys", i.e. hosts # that you want to deny relay from regardless - this may be hosts # that do not have enough filters or any other reason. Be careful. # FB/etc/mail/sendmail.cB CB # Scheck_rcpt # first get rid of a%b@c type addresses R< $+ % $+ > < $1 @ $2 > R< $+ @ $+ @ $+ > < $1 @ $2 > # "RCPT To" that terminates locally is OK R< $+ @ $=w > $@ OK R< $+ @ $=w . > $@ OK R<$-> $@ OK # "RCPT To" for accepted domains is OK R< $+ @ $=D > $@ OK R< $+ @ $=D . > $@ OK R< $+ @ $+ . $=D > $@ OK R< $+ @ $+ . $=D . > $@ OK # get sender host's name R$* $: $(dequote "" $&{client_name} $) # if it's me it's OK R$=w $@ OK R$@ $@ OK # exceptionally bad guys... R$=B $#error $:"451 Relaying Denied, " $1 # do this in case you want "bad with recursion" #R$+$=B $#error $:"451 Relaying Denied, " $1$2 # an accepted host is OK (with "recursion") R$=D $@ OK R$+$=D $@ OK # anything else is bogus R$* $#error $:"451 Relaying Denied, " $1 ################################################################## Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 19]