7Network Working Group G. Lindberg
8Request for Comments: 2505 Chalmers University of Technology
10Category: Best Current Practice
13 Anti-Spam Recommendations for SMTP MTAs
17 This document specifies an Internet Best Current Practices for the
18 Internet Community, and requests discussion and suggestions for
19 improvements. Distribution of this memo is unlimited.
23 Copyright (C) The Internet Society (1999). All Rights Reserved.
27 This memo gives a number of implementation recommendations for SMTP,
28 [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them
29 more capable of reducing the impact of spam(*).
31 The intent is that these recommendations will help clean up the spam
32 situation, if applied on enough SMTP MTAs on the Internet, and that
33 they should be used as guidelines for the various MTA vendors. We are
34 fully aware that this is not the final solution, but if these
35 recommendations were included, and used, on all Internet SMTP MTAs,
36 things would improve considerably and give time to design a more long
37 term solution. The Future Work section suggests some ideas that may
38 be part of such a long term solution. It might, though, very well be
39 the case that the ultimate solution is social, political, or legal,
40 rather than technical in nature.
42 The implementor should be aware of the increased risk of denial of
43 service attacks that several of the proposed methods might lead to.
44 For example, increased number of queries to DNS servers and increased
45 size of logfiles might both lead to overloaded systems and system
46 crashes during an attack.
48 A brief summary of this memo is:
50 o Stop unauthorized mail relaying.
51 o Spammers then have to operate in the open; deal with them.
52 o Design a mail system that can handle spam.
58Lindberg Best Current Practice [Page 1]
60RFC 2505 Anti-Spam Recommendations February 1999
65 This memo is a Best Current Practice (BCP) RFC. As such it should be
66 used as a guideline for SMTP MTA implementors to make their products
67 more capable of preventing/handling spam. Despite this being its
68 primary goal, an intended side effect is to suggest to the
69 sysadmin/Postmaster community which "anti spam knobs" an SMTP MTA is
72 However, this memo is not generally intended as a description on how
73 to operate an SMTP MTA - which "knobs" to turn and how to configure
74 the options. If suggestions are provided, they will be clearly marked
75 and they should be read as such.
79 Mass unsolicited electronic mail, often known as spam(*), has
80 increased considerably during a short period of time and has become a
81 serious threat to the Internet email community as a whole. Something
82 needs to be done fairly quickly.
84 The problem has several components:
86 o It is high volume, i.e. people get a lot of such mail in their
89 o It is completely "blind", i.e. there is no correlation between
90 the receivers' areas of interest and the actual mail sent out (at
91 least if one assumes that not everybody on the Internet is
92 interested in porno pictures and spam programs...).
94 o It costs real money for the receivers. Since many receivers pay
95 for the time to transfer the mailbox from the (dialup) ISP to
96 their computer they in reality pay real money for this.
98 o It costs real money for the ISPs. Assume one 10 Kbyte message
99 sent to 10 000 users with their mailboxes at one ISP host; that
100 means an unsolicited, unexpected, storage of 100 Mbytes. State
101 of the art disks, 4 Gbyte, can take 40 such message floods before
102 they are filled. It is almost impossible to plan ahead for such
105 o Many of the senders of spam are dishonest, e.g. hide behind false
106 return addresses, deliberately write messages to look like they
107 were between two individuals so the spam recipient will think it
108 was just misdelivered to them, say the message is "material you
114Lindberg Best Current Practice [Page 2]
116RFC 2505 Anti-Spam Recommendations February 1999
119 requested" when you never asked for it, and generally do
120 everything they can without regard to honesty or ethics, to try
121 to get a few more people to look at their message.
123 In fact some of the spam-programs take a pride in adding false
124 info that will "make the ISPs scratch their heads".
126 It is usually the case that people who send in protests (often
127 according to the instructions in the mail) find their mail
128 addresses added to more lists and sold to other parties.
130 o It is quite common practice to make use of third party hosts as
131 relays to get the spam mail sent out to the receivers. This theft
132 of service is illegal in most - if not all - countries (at least
133 in the US spammers have been successfully sued). However, with
134 the original sender in the US, the (innocent) relay in Sweden and
135 the list of receivers back in the US, the legal process of
136 getting damages from the spammers becomes extremely difficult.
140 This memo has no intention of being the final solution to the spam
143 If, however, enough Internet MTAs did implement enough of the rules
144 described below (especially the Non-Relay rules), we would get the
145 spammers out in the open, where they could be taken care of. Either
146 pure legal actions would help, or we can block them technically using
147 other rules described below (since the Non-Relay rules now make them
148 appear openly, with their own hosts and domains, we can apply various
149 access filters against them). In reality, a combination of legal and
150 technical methods is likely to give the best result.
152 This way, the spam problem could be reduced enough to allow the
153 Internet community to design and deploy a real and general solution.
157 The Non-Relay rules are not in themselves enough to stop spam.
158 Even if 99% of the SMTP MTAs implemented them from Day 1,
159 spammers would still find the remaining 1% and use them. Or
160 spammers would just switch gear and connect directly to each and
161 every recipient host; that will be to a higher cost for the
162 spammer, but is still quite likely.
164 Even though IPv6 deployment may be near, the spam problem is here
165 already and thus this memo restricts itself to the current IPv4.
170Lindberg Best Current Practice [Page 3]
172RFC 2505 Anti-Spam Recommendations February 1999
177 Throughout this memo we will use the terminology of RFC2119, [4]:
181 This word or the adjective "REQUIRED" means that the item is an
182 absolute requirement.
186 This word or the adjective "RECOMMENDED" means that there may
187 exist valid reasons in particular circumstances to ignore this
188 item, but the full implications should be understood and the case
189 carefully weighed before choosing a different course.
193 This word or the adjective "OPTIONAL" means that this item is
194 truly optional. One vendor may choose to include the item because
195 a particular marketplace requires it or because it enhances the
196 product, for example; another vendor may omit the same item.
1981.4. Using DNS information
200 In the memo we sometimes use the term "host name" or "domain name"
201 which should be interpreted as a Fully Qualified Domain Name, FQDN.
202 By this we mean the name returned from the DNS in response to a PTR
203 query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a
204 name, or we mean a name with a DNS A or MX record associated to it
205 RFC1034, [5], and RFC1035, [6].
207 When we suggest use of FQDNs rather than IP addresses this is because
208 FQDNs are intuitively much easier to use. However, all such usage
209 depends heavily on DNS and .IN-ADDR.ARPA (PTR) information. Since it
210 is fairly easy to forge that, either by false cache information
211 injected in DNS servers or spammers running their own DNS with false
212 information in them, host and domain names must be used with care,
213 e.g. verified so that the translation address->name corresponds to
214 name->address. With Secure DNS, RFC2065, [7], things will improve,
215 since spoofing of .IN-ADDR.ARPA will no longer be possible.
217 One of the recommendations is about verifying "MAIL From:" (envelope
218 originator) domains with the DNS (assure that appropriate DNS
219 information exists for the domain). When making use of this
220 capability there are a few things to consider:
226Lindberg Best Current Practice [Page 4]
228RFC 2505 Anti-Spam Recommendations February 1999
231 (1) One must not forget the increased amount of DNS queries which
232 might result in problems for the DNS server itself to cope with
233 the load. This itself can result in a denial of service attack
234 against the DNS server just by sending email to a site.
236 (2) It should be noted that with negative caching in the DNS, forged
237 DNS responses can be used to mount denial of service attacks.
238 For example, if a site is known to implement a FQDN validity
239 check on addresses in SMTP "MAIL From:" commands, an attacker may
240 be able to use negative DNS responses to effectively block
241 acceptance of mail from one or more origins. Because of this, one
242 should carefully check the DNS server in use, e.g. how it
243 verifies that incoming responses correspond to outstanding
244 queries, to minimize the risk for such attacks.
246 (3) For early versions of spam software FQDN checks provide quite
247 some relief, since that software generates mail with completely
248 bogus "MAIL From:" that will never get into the system if
249 verified with the DNS. This is in active use at many
250 installations today and it does reduce spam.
252 On the other hand, sites with weak DNS connectivity may find their
253 legitimate mail having problems reaching destinations due to DNS
254 timeouts when the receivers verify their "MAIL From:". However, since
255 DNS information is handled asynchronously and is cached even though
256 the initial requester has given up, chances are high that the
257 necessary information is there at a later attempt.
259 For later versions of spam software, a check of "MAIL From:" is much
260 less likely to help, since spam software evolves too and will start
261 using existing mail addresses (whether or not that is legal is beyond
262 the scope of this memo). But, at least the Internet will benefit from
263 the side effect that this test stops typos and misconfigured UAs.
2651.5. Where to block spam, in SMTP, in RFC822 or in the UA
267 Our basic assumption is that refuse/accept is handled at the SMTP
268 layer and that an MTA that decides to refuse a message should do so
269 while still in the SMTP dialogue. First, this means that we do not
270 have to store a copy of a message we later decide to refuse and
271 second, our responsibility for that message is low or none - since we
272 have not yet read it in, we leave it to the sender to handle the
282Lindberg Best Current Practice [Page 5]
284RFC 2505 Anti-Spam Recommendations February 1999
2871.6. SMTP Return Codes
289 SMTP has several classes of Return Codes, see [1] for a discussion:
292 is a Permanent Negative Completion reply (Fatal Error) and
293 results in the mail transfer being terminated and the mail
297 is a Transient Negative Completion reply (Temporary Error) and
298 results in the mail transfer being put back on queue again and a
299 new attempt being made later.
302 is a Positive Completion reply and indicates that the MTA now has
303 taken responsibility for the delivery of the mail.
305 When making use of the options/"knobs" described in this memo there
306 are a few things to consider:
308 For some events, like "Denied - you're on the spammer's list", 5xx
309 may be the correct Return Code, since it terminates the session at
310 once and we are done with it (assuming that the spammer plays by the
311 SMTP rules, which he may decide not to do - in fact he can put the
312 mail back on queue or turn to some other host, regardless of Return
313 Code). However, a 5xx mistake in a configuration may cause legitimate
314 mail to bounce, which may be quite unfortunate.
316 Therefore, we suggest 4xx as the Return Code for most cases. Since
317 that is a non fatal error, the mail gets re-queued at the sender and
318 we have at least some time to discover and correct configuration
319 errors, rather than have mail bounce (typically this is when we
320 refuse to Relay for domains that we actually should accept since we
321 are on their MX list).
323 A 4xx response also makes the spammer's host re-queue the mail and if
324 it really is his own host who gets to do this it is probably a good
325 thing - fill up his disks with his own spam. If, on the other hand,
326 he is using someone else as Relay Host, all the spam mail being
327 queued is a fairly strong evidence that something bad is going on and
328 should cause attention at that Relay Host.
330 However, 4xx Temporary Errors may have unexpected interaction with
331 MX-records. If the receiving domain has several MX records and the
332 lowest preference MX-host refuses to receive mail with a "451"
333 Response Code, the sending host may choose to - and often will - use
334 the next host on the MX list.
338Lindberg Best Current Practice [Page 6]
340RFC 2505 Anti-Spam Recommendations February 1999
343 If that next MX host does not have the same refuse-list, it will of
344 course accept the mail, only to find that the final host still
345 refuses to receive that piece of mail ("MAIL From:"). Our intent was
346 to make the offending mail stay at the offending sender's host and
347 fill up his mqueue disk, but it all ended up at our friend, the next
348 lowest preference MX-host.
350 Finally, it has been suggested that one may use a 2xx Return Code but
351 nevertheless decide not to forward or receive the spam mail; typical
352 alternatives are to store it elsewhere (e.g. /dev/null). This clearly
353 violates the intent of RFC821 and should not be done without careful
354 consideration - instead of blindly dropping the mail one could re-
355 queue it and manually (or automagically) inspect whether it is spam
356 or legitimate mail and whether it should be dropped or forwarded.
360 An MTA that also has the ability to handle mailing lists and expand
361 that to a number of recipients, needs to be able to authorize senders
362 and protect its lists from spam. The mechanisms for this may be very
363 different from those for ordinary mail and ordinary users and are not
364 covered in this memo.
368 Here we first give a brief list of recommendations, followed by a
369 more thorough discussion of each of them. We will also give
370 recommendations on things NOT to do, things that may seem natural in
371 the spam fight (and might even work so far) but that might wreak
372 havoc on Internet mail and thus may cause more damage than good.
374 1) MUST be able to restrict unauthorized use as Mail Relay.
376 2) MUST be able to provide "Received:" lines with enough
377 information to make it possible to trace the mail path, despite
378 spammers use forged host names in HELO statements etc.
380 3) MUST be able to provide local log information that makes it
381 possible to trace the event afterwards.
383 4) SHOULD be able to log all occurrences of anti-relay/anti-spam
386 5) SHOULD be able to refuse mail from a host or a group of hosts.
388 6a) MUST NOT refuse "MAIL From: <>".
390 6b) MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
394Lindberg Best Current Practice [Page 7]
396RFC 2505 Anti-Spam Recommendations February 1999
399 7a) SHOULD be able to refuse mail from a specific "MAIL From:"
400 user, <foo@domain.example>.
402 7b) SHOULD be able to refuse mail from an entire "MAIL From:" domain
405 8) SHOULD be able to limit ("Rate Control") mail flow.
407 9) SHOULD be able to verify "MAIL From:" domain (using DNS or
410 10) SHOULD be able to verify <local-part> in outgoing mail.
412 11) SHOULD be able to control SMTP VRFY and EXPN.
414 12) SHOULD be able to control SMTP ETRN.
416 13) MUST be able to configure to provide different Return Codes
417 for different rules (e.g. 451 Temp Fail vs 550 Fatal Error).
419 The discussion below often ends up with a need to do various forms of
420 pattern matching on domain/host names and IP addresses/subnets. It
421 is RECOMMENDED that the data/template for doing so may be supplied
422 outside of the MTA, e.g. that the pattern matching rules be included
423 in the MTA but that the actual patterns may be in an external file.
424 It is also RECOMMENDED that the pattern matching rules (external
425 file) may contain regular expressions, to give maximum flexibility.
427 Of course string matching on domain/host names MUST NOT be case
428 sensitive. Since <local-part> may be case sensitive it may be natural
429 to keep that here. However, since <sPAmMeR@domain.example> and
430 <spammer@domain.example> is most probably the same user and since the
431 string compares are used to refuse his messages, we suggest that
432 <local-part> comparisons be case insensitive too.
434 The interpretation that should apply to all these recommendations is
435 flexibility - regardless of how well we design anti-spam rules today,
436 spammers will find ways around them and a well designed MTA should be
437 flexible enough to meet those new threats.
4392.1. Restricting unauthorized Mail Relay usage
441 Unauthorized usage of a host as Mail Relay means theft of the relay's
442 resources and puts the relay owner's reputation at risk. It also
443 makes it impossible to filter out or block spam without at the same
444 time blocking legitimate mail.
446 Therefore, the MTA MUST be able to control/refuse such Relay usage.
450Lindberg Best Current Practice [Page 8]
452RFC 2505 Anti-Spam Recommendations February 1999
455 In an SMTP session we have 4 elements, each with a varying degree of
458 1) "HELO Hostname" Easily and often forged.
459 2) "MAIL From:" Easily and often forged.
460 3) "RCPT To:" Correct, or at least intended.
461 4) SMTP_Caller (host) IP.src addr OK, FQDN may be OK.
463 Since 1) and 2) are so easily and often forged, we cannot depend on
464 them at all to authorize usage of our host as Mail Relay.
466 Instead, the MTA MUST be able to authorize Mail Relay usage based on
469 o "RCPT To:" address (domain).
470 o SMTP_Caller FQDN hostname.
471 o SMTP_Caller IP address.
473 The suggested algorithm is:
475 a) If "RCPT To:" is one of "our" domains, local or a domain that
476 we accept to forward to (alternate MX), then accept to Relay.
478 b) If SMTP_Caller is authorized, either its IP.src or its FQDN
479 (depending on if you trust the DNS), then accept to Relay.
481 c) Else refuse to Relay.
483 When doing a) you have to make sure all kinds of SMTP source routing
484 (both the official [@a,@b:u@c], the '%' hack and uucp-style '!' path)
485 is either removed completely before the test, or at least is
488 A site implementing this requirement must also be aware that they
489 might block correctly addressed messages, especially such originating
490 or terminating in a gateway to a different mail system than SMTP.
491 Before implementing such a policy, a careful inventory should be done
492 to make sure all routing algorithms used, either by other mail
493 systems or ad-hoc, are known. Each one of such systems must be taken
494 care of on a case-by-case basis.
496 Examples of such mail systems, and their addressing schemes are X.400
497 with an address of the type:
499 "/c=us/admd= /prmd=xyz/dd.rfc-822=user(a)final/"@x400-gateway
501 Another example involves DECnet MAIL-11, which can have addresses in
506Lindberg Best Current Practice [Page 9]
508RFC 2505 Anti-Spam Recommendations February 1999
511 "gateway::smtp%\"user@final\""@mail-11-gateway
513 In all cases the configuration MUST support wild cards for FQDNs and
514 classful IP addresses and SHOULD support "address/mask" for classless
515 IP addresses, e.g. domain.example and *.domain.example; 10.11.*.*,
516 192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23.
518 The configuration SHOULD allow for the decision/template data to be
519 supplied by an external source, e.g. text file or dbm database. The
520 decision/template SHOULD be allowed to contain regular expressions.
524 The MTA MUST prepend a "Received:" line in the mail (as described in
525 RFC822, [2], and required in RFC1123, [3]). This "Received:" line
526 MUST contain enough information to make it possible to trace the mail
527 path back to the sender. We have two cases:
5292.2.1. Direct MTA-to-MTA connections
531 Internet mail was designed such that the sending host connects
532 directly to the recipient as described by MX records (there may be
533 several MX hosts on a priority list). To assure traceability back to
534 the sending host (which may be a firewall/gateway, as described
535 later) each MTA along the path, including the final MTA, MUST prepend
536 a "Received:" line. For such a "Received:" line we have:
540 o The IP address of the caller.
542 o The 'date-time' as described in RFC822, [2], pp 18.
546 o The FQDN corresponding to the callers IP address.
548 o The argument given in the "HELO" statement.
550 o Authentication information, if an authenticated connection
551 was used for the transmission / submission.
553 It is suggested that most other "Received:" fields described in
554 RFC822 be included in the "Received:" lines.
556 Basically, any information that can help tracing the message can and
557 should be added to the "Received:" line. It is true even when the
558 initial submission is non-SMTP, for example submission via a web-based
562Lindberg Best Current Practice [Page 10]
564RFC 2505 Anti-Spam Recommendations February 1999
567 mail client where http is used between the web client and server, a
568 "Received:" line can be used to identify that connection stating what
569 IP-address was used when connecting to the http server where the mail
572 These recommendations are deliberately stronger than RFC1123, [3],
573 and are there to assure that mail sent directly from a spammer's host
574 to a recipient can be traced with enough accuracy; a typical example
575 is when a spammer uses a dialup account and the ISP needs to have his
576 IP address at the 'date-time' to be able to take action against him.
5782.2.2. Firewall/gateway type devices
580 Organizations with a policy of hiding their internal network structure
581 must still be allowed and able to do so. They usually make their
582 internal MTAs prepend "Received:" lines with a very limited amount of
583 information, or prepend none at all. Then they send out the mail
584 through some kind of firewall/gateway device, which may even remove
585 all the internal MTAs' "Received:" lines before it prepends its own
586 "Received:" line (as required in RFC1123, [3]).
588 By doing so they take on the full responsibility to trace spammers
589 that send from inside their organization or they accept to be held
590 responsible for those spammers' activities. It is REQUIRED that the
591 information provided in their outgoing mail is sufficient for them to
592 perform any necessary traces.
594 In the case of incoming mail to an organization, the "Received:"
595 lines MUST be kept intact to make sure that users receiving mail on
596 the inside can give information needed to trace incoming messages to
599 Generally, a gateway SHOULD NOT change or delete "Received:" lines
600 unless it is a security requirement to do so. Changing the content
601 of existing "Received:" lines to make sure they "make sense" when
602 passing a mail gateway of some kind most often destroys and deletes
603 information needed to make a message traceable. Care must be taken to
604 preserve the information in "Received:" lines, either in the message
605 itself, the mail that the receiver gets, or if that is impossible, in
610 The MTA MUST be able to provide enough local log information to make
611 it possible to trace the event. This includes most of the information
612 put into the "Received:" lines; see above.
618Lindberg Best Current Practice [Page 11]
620RFC 2505 Anti-Spam Recommendations February 1999
6232.4. Log anti-relay/anti-spam actions
625 The MTA SHOULD be able to log all anti-relay/anti-spam actions. The
626 log entries SHOULD contain at least:
630 o Refusal information, i.e. why the request was refused ("Mail
631 From", "Relaying Denied", "Spam User", "Spam Host", etc).
633 o "RCPT To:" addresses (domains).
634 (If the connection was disallowed at an earlier stage, e.g.
635 by checking the SMTP_Caller IP address, the "RCPT To:"
636 address is unknown and therefore cannot be logged).
638 o Offending host's IP address.
640 o Offending host's FQDN hostname.
642 o Other relevant information (e.g. given during the SMTP
643 dialogue, before we decided to refuse the request).
645 It should be noted that by logging more events, especially denied
646 email, one opens the possibility for denial of service attacks, for
647 example by filling logs by having a very large amount of "RCPT To:"
648 commands. An implementation that implements increased logging
649 according to this description must be aware of the fact that the size
650 of the logfiles increases, especially during attacks.
6522.5. Refuse mail based on SMTP_Caller address
654 The MTA SHOULD be able to accept or refuse mail from a specific host
655 or from a group of hosts. Here we mean the IP.src address or the FQDN
656 that its .IN-ADDR.ARPA resolves to (depending on whether you trust
657 the DNS). This functionality could be implemented at a firewall, but
658 since the MTA should be able to "defend itself" we recommend it be able
661 It is RECOMMENDED that the MTA be able to decide based on FQDN hostnames
662 (host.domain.example), on wild card domain names (*.domain.example),
663 on individual IP addresses (10.11.12.13) or on IP addresses with a
664 prefix length (10.0.0.0/8, 192.168.1.0/24).
666 It is also RECOMMENDED that these decision rules can be combined to
667 form a flexible list of accept/refuse/accept/refuse, e.g:
674Lindberg Best Current Practice [Page 12]
676RFC 2505 Anti-Spam Recommendations February 1999
679 accept host.domain.example
680 refuse *.domain.example
682 accept 192.168.1.0/24
685 The list is searched until first match and the accept/refuse action
688 IP-address/length is RECOMMENDED. However, implementations with wild
689 cards, e.g. 10.11.12.* (classful networks on byte boundaries only)
690 are of course much better than those without.
692 To improve filtering even more, the MTA MAY provide complete regular
693 expressions to be used for hostnames; possibly also for IP addresses.
6952.6. "MAIL From: <>" and "MAIL From: <user@my.local.dom.ain>"
697 Although the fight against spammers is important it must never be
698 done in a way that violates existing email standards. Since spammers
699 often forge "MAIL From:" addresses it is tempting to put general
700 restrictions on that, especially for some "obvious" addresses. This
701 may, however, wreak more havoc to the mail community than spam does.
703 When there is a need to refuse mail from a particular host or site
704 our recommendation is to use other methods mentioned in this memo,
705 e.g. refuse mail based on SMTP_Caller address (or name), regardless
706 of what "MAIL From:" was used.
7082.6.1. "MAIL From: <>"
710 The MTA MUST NOT refuse to receive "MAIL From: <>".
712 The "MAIL From: <>" address is used in error messages from the mail
713 system itself, e.g. when a legitimate mail relay is used and forwards
714 an error message back to the user. Refusing to receive such mail
715 means that users may not be notified of errors in their outgong mail,
716 e.g. "User unknown", which will no doubt wreak more havoc to the
717 mail community than spam does.
719 The most common case of such legitimate "MAIL From: <>" is to one
720 recipient, i.e. an error message returned to one single individual.
721 Since spammers have used "MAIL From: <>" to send to many recipients,
722 it is tempting to either reject such mail completely or to reject all
723 but the first recipient. However, there are legitimate causes for an
724 error mail to go to multiple recipients, e.g. a list with several
725 list owners, all located at the same remote site, and thus the MTA
726 MUST NOT refuse "MAIL From: <>" even in this case.
730Lindberg Best Current Practice [Page 13]
732RFC 2505 Anti-Spam Recommendations February 1999
735 However, the MTA MAY throttle down the TCP connection ("read()"
736 frequency) if there are more than one "RCPT To:" and that way slow
737 down spammers using "MAIL From: <>".
7392.6.2. "MAIL From: <user@my.local.dom.ain>"
741 The MTA MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
743 By "my.local.dom.ain" we mean the domain name(s) that are treated as
744 local and result in local delivery. At first thought it may seem like
745 noone else will need to use "MAIL From: <user@my.local.dom.ain>" and
746 that restrictions on who may use that would reduce the risk of fraud
747 and thus reduce spam. While this may be true in the (very) short
748 term, it also does away with at least two legitimate usages:
750 o Aliases (.forward files).
751 <user1@my.local.dom.ain> sends to <user2@external.example> and
752 that mail gets forwarded back to <user2@my.local.dom.ain>, e.g.
753 since <user2> has moved to my.local.dom.ain and has a .forward
754 file at external.example.
757 RFC1123, [3], gives a clear requirement that "MAIL From:" for
758 mail from a mailing list should reflect the owner of the list,
759 rather than the individual sender. Because of this fact, and the
760 fact that the owner of the list might not be in the same domain
761 as the list (list host) itself, mail may arrive to the list
762 owner's domain (mail host) from a foreign domain (from a host
763 serving a foreign domain) with the list owner's local domain in
764 the "Mail From:" command.
766 If "MAIL From: <user@my.local.dom.ain>" is rejected, both these cases
767 will result in failure to deliver legitimate mail.
7692.7. Refuse based on "MAIL From:"
771 The MTA SHOULD be able to refuse to receive mail from a specific
772 "MAIL From:" user (foo@domain.example) or from an entire "MAIL From:"
773 domain (domain.example). In general these kinds of rules are easily
774 overcome by the spammers changing "MAIL From:" every so often, but
775 the ability to block a certain user or a certain domain is quite
776 helpful while an attack has just been discovered and is ongoing.
782 "MAIL From: <user@my.local.dom.ain>"
786Lindberg Best Current Practice [Page 14]
788RFC 2505 Anti-Spam Recommendations February 1999
791 MUST NOT be refused (see above), except when other policies block the
792 connection, for example when the SMTP_Caller IP address of the peer
793 belongs to a network which is deliberately refused.
797 The MTA SHOULD provide tools for the mail host to control the rate
798 with which mail is sent or received. The idea is twofold:
800 1) If we happen to have an legitimate mail user with an existing
801 legitimate account and this user sends out spam, we may want to
802 reduce the speed with which he sends it out. This is not without
803 controversy and must be used with extreme care, but it may
804 protect the rest of the Internet from him.
806 2) If we are under a spam attack it may help us considerably just
807 being able to slow down the incoming mail rate for that
808 particular user/host.
810 For sending mail, this has to be done by throttling the TCP
811 connection to set the acceptable output data rate, e.g. reduce the
814 For receiving mail, we could use basically the same technique, e.g.
815 reduce the "read()" frequency, or we could signal with a 4xx Return
816 Code that we cannot receive. It is RECOMMENDED that the decision to
817 take such action be based on "MAIL From:" user, "MAIL From:" domain,
818 SMTP_Caller (name/address), "RCPT TO:", or a combination of all
8212.9. Verify "MAIL From:"
823 The MTA SHOULD be able to perform a simple "sanity check" of the
824 "MAIL From:" domain and refuse to receive mail if that domain is
825 nonexistent (i.e. does not resolve to having an MX or an A record).
826 If the DNS error is temporary, TempFail, the MTA MUST return a 4xx
827 Return Code (Temporary Error). If the DNS error is an Authoritative
828 NXdomain (host/domain unknown) the MTA SHOULD still return a 4xx
829 Return Code (since this may just be primary and secondary DNS not
830 being in sync) but it MAY allow for an 5xx Return Code (as configured
8332.10. Verify <local-part>
835 The MTA SHOULD allow outgoing mail to have its <local-part> verified
836 so that the sender name is a real user or an existing alias. This is
837 basically to protect the rest of the Internet from various "typos"
842Lindberg Best Current Practice [Page 15]
844RFC 2505 Anti-Spam Recommendations February 1999
847 MAIL From: <fo0bar@domain.example>
849 and/or malicious users
851 MAIL From: <I.am.unknown.to.you.he.he@domain.example>
853 As always this can be overcome by spammers really wanting to do so,
854 but with more strict rules for relaying it becomes harder and harder.
855 In fact, catching "typos" at the initial (and official) mail relay is
856 in itself enough motivation for this recommendation.
8582.11. SMTP VRFY and EXPN
860 Both SMTP VRFY and EXPN provide means for a potential spammer to test
861 whether the addresses on his list are valid (VRFY) and even get more
862 addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed
863 to issue these commands. This may be "on/off" or it may use access
864 lists similar to those mentioned previously.
866 Note that the "VRFY" command is required according to RFC821, [1].
867 The response can, though, be "252 Argument not checked" to represent
868 "off" or blocked via an access list. This should be the default.
870 Default for the "EXPN" command should be "off".
874 SMTP ETRN means that the MTA will re-run its mail queue, which may be
875 quite costly and open for Denial of Service attacks. Therefore, the
876 MTA SHOULD control who is is allowed to issue the ETRN command. This
877 may be "on/off" or it may use access lists similar to those mentioned
878 previously. Default should be "off".
882 The primary issue here is flexibility - it is simply not possible to
883 define in a document how to make tradeoffs between returning 5xx and
884 make legitimate mail fail at once due to a configuration mistake and
885 returning 4xx and be able to catch such configuration mistakes via
888 Therefore, the MTA MUST be configurable to provide "Success" (2xx),
889 "Temporary Failure" (4xx) or "Permanent Failure" (5xx) for different
890 rules or policies. The exact return codes, other than the first digit
891 (2, 4 or 5) should, however, not be configurable. This is because of
892 the ease of configuring the software in the wrong way, and the fact
898Lindberg Best Current Practice [Page 16]
900RFC 2505 Anti-Spam Recommendations February 1999
903 that the selection of exactly what error code to use is very subtle
904 and that many software implementations do check more than the first
905 digit (2, 4 or 5) in the return code.
907 However, when the response is the result of a DNS lookup and the DNS
908 system returned TempFail, a temporary error, the MTA MUST reflect
909 this and provide a 4xx return code. If the DNS response is an
910 Authoritative NXdomain (host or domain unknown) the MTA MAY reflect
911 this by a 5xx Return Code.
913 Please refer to the previous discussion on SMTP Return Codes for
914 additional information.
9162.13.1. The importance of flexibility - an example
918 At Chalmers University of Technology our DNS contains
920 cdg.chalmers.se. IN MX 0 mail.cdg.chalmers.se.
921 IN MX 100 mail.chalmers.se.
923 and similarly for most subdomains, i.e. a second host to store mail
924 to each subdomain, should their mail host be down. This means that
925 mail.chalmers.se must be prepared to act as Mail Relay for the
926 subdomains ("RCPT To:") it serves and that those subdomains' mail
927 hosts have to accept SMTP connections from mail.chalmers.se. Late
928 versions of spam software make use of this fact by always using
929 mail.chalmers.se to get their mail delivered to our subdomains and by
930 doing so they still get Mail Relaying done for them and they prevent
931 recipient hosts from refusing SMTP connections based on the sending
932 host's FQDN or IP-address.
934 As long as we keep our design with a secondary MX host we cannot
935 really have mail.chalmers.se refuse Mail Relay, at least not with a
936 5xx return code. However, it has been fairly straight forward to
937 identify the hosts/domains/networks that make use of this possibility
938 and refuse to act as Mail Relay for them them - and only them - and
939 do so with a 4xx return code. Legitimate mail from them may be
940 delayed if the final recipient host is down but will eventually be
941 delivered when it gets up again (4xx Return Code) and this is no
942 worse then if we changed our MX design. Spam now faces a "Denied"
943 response and have to connect to each and every one of the recipients,
944 who may decide to refuse the SMTP connection.
946 The bottom line is that this is made possible because of 1) enough
947 flexibility in the Relay Authorization code and 2) enough flexibility
948 in assigning Return Codes - an MTA with a 5xx Return Code carved in
949 stone would have made this absolutely impossible.
954Lindberg Best Current Practice [Page 17]
956RFC 2505 Anti-Spam Recommendations February 1999
9613.1. Impact on SMTP UAs and end users
963 Even though this memo is about MTAs and recommendations for them,
964 some of what is done here also impacts UAs (User Agents, the
965 "ordinary mail programs").
967 A UA does two things:
969 1) Reads mail from a mailbox and prints on the screen.
970 This typically uses a protocol like POP, IMAP or NFS.
972 2) Reads text from the keyboard and hands that over to the mailbox
973 MTA for delivery as a piece of mail. This typically uses the SMTP
974 protocol, i.e. the same protocol that is used between MTAs.
976 When MTAs now start to implement various anti-relay filters as
977 described above, a UA on a portable laptop host may get a response
978 like "Relaying Denied" just because it happens to use IP addresses
979 within an unknown range or that resolve to unknown FQDNs.
981 The typical victim of this "Relaying Denied" response is a salesman
982 carrying a laptop on a business trip, or even an IETF delegate at a
983 meeting hotel. The salesman will probably dial his nearest ISP and
984 will get an IP address from that dialup pool; the IETF delegate will
985 use an IP address from the terminal room. In both cases their laptop
986 mail program (the UA; e.g. pine, Netscape, Eudora) will try to send
987 out mail via their home MTA, e.g. SMTP-SERVER=mail.home.example, but
988 unless mail.home.example has been updated to accept that (temporary)
989 IP address it will respond "Relaying Denied" and refuse.
991 To get around this problem we could simply add the terminal room's or
992 the dialup pool's IP network to the list of accepted networks at
993 mail.home.example. This does open up some minimal risk of spammers
994 using that host as their Mail Relay: If they use the same ISP's
995 dialup pool and they configure to use mail.home.example at the same
996 time as our salesman is on his trip, then the spammers will be
997 authorized to relay their spam through mail.home.example. However,
998 this is not extremely likely and as long as we do not open up for the
999 entire world all the time and we keep the log files under close
1000 observation and we stop relaying at once we find we're being used,
1001 this solution is probably good enough.
1003 Another way around is that our salesman uses a Mail Relay provided by
1004 the current dialup ISP, if that service exists. To do so he has to
1005 modify SMTP-SERVER= in his UA, which may or may not be reasonable.
1010Lindberg Best Current Practice [Page 18]
1012RFC 2505 Anti-Spam Recommendations February 1999
1015 The correct way to handle this situation, though, is by some other
1016 mail-sending protocol between the UA and the MTA.
1018 Although a separate submission protocol does not exist, a profile of
1019 SMTP for this, the "Message Submission" specification, [9], has
1020 recently been defined.
1022 Or, we could note that when the SMTP Authentication work, [10], is
1023 all in place, it will allow for Authenticated SMTP to serve as The
1024 Protocol between the UAs and the home MTA (whether that should be
1025 considered a new protocol or "the same old SMTP" is irrelevant here).
1027 This adds one item to the suggested Relay algorithm in section 2.1:
1029 + If "SMTP Authenticated" then accept to Relay.
10313.2. Personal anti-spam filters
1033 Since all users are individuals, there is little hope that any
1034 central anti-spam action will suit them all - in fact people can and
1035 do argue about Freedom of Speech infringement if some central set of
1036 anti-spam rules is enforced without the users' approval. (One could
1037 of course also argue whether spam really adds anything to anyone, but
1038 that must be up to each individual user to decide, rather than being
1041 Therefore the only reasonable extension is to allow for personal
1042 anti-spam filters, i.e. anti-spam filters like the ones described
1043 earlier in this memo, but available and configurable on a per user
1044 basis. Since most users will not have a strong opinion (except that
1045 they want to avoid spam) the mail system should provide a system
1046 default and give each user the ability to override or modify that.
1047 In a UNIX based environment one could have something like
1052 and rules on how the latter can interfere with the former.
1054 All of this opens up quite a number of unresolved issues, e.g.
1055 whether each user himself really should be allowed to decide on SMTP
1056 Return Codes (and how it should be described so he understands enough
1057 of the implications) and how existing mail systems will deal with
1058 different per user responses, especially how they will deal with a
1059 mix of 5xx and 4xx codes:
1061 C MAIL From: <usr@spam.example>
1062 S 250 <usr@spam.example>... Sender ok
1066Lindberg Best Current Practice [Page 19]
1068RFC 2505 Anti-Spam Recommendations February 1999
1071 C RCPT To: <usr@domain.example>
1072 S 250 <usr@domain.example>... Recipient ok
1073 C RCPT To: <foo@domain.example>
1074 S 451 <foo@domain.example>... Denied due to spam list
1075 C RCPT To: <bar@domain.example>
1076 S 550 <bar@domain.example>... Denied due to spam list
1078 Of course one could decide on either "250 OK" or "550 Denied" with no
1079 other alternatives for the individual user, but this too has to be
1080 explained enough that an ordinary user understands the implications
1081 of "Refuse 'MAIL From: <.*@spam.example>'" and that it can do away
1082 with, or block out, mail he actually wanted.
10843.3. SMTP Authentication
1086 SMTP Authentication, [10], has already been mentioned as a method to
1087 authorize Mail Relaying, but of course there is much more to it than
1088 that. When that infrastructure and functionality is all in place,
1089 spammers will have a much harder time forging addresses and hiding.
1093 With the increased use of Network Address Translators (NATs) may come
1094 a need for additional information in log files. As long as there is a
1095 1:1 mapping between the addresses inside the NAT and the addresses
1096 used outside it everything is OK, but if the NAT box also translates
1097 port numbers (to combine many internal hosts into one external
1098 address) we will need to log not only the IP addresses of spam hosts
1099 but also the port numbers. Otherwise we will not be able to identify
1100 the individual host inside the NAT.
11024. Security Considerations
1104 The grassfire-like increase of spam raises several security issues
1105 which, in fact, puts the entire Internet mail community at risk:
1107 o People may fail to find important mail in their flooded
1108 mailboxes. Or, they may delete it while cleaning up.
1110 o ISPs get overloaded mailbox hosts and filled disk. Cleaning up
1111 and helping customers requires a lot of human resources. In
1112 fact, ISP mail servers have crashed by too much mail.
1114 o While disks are unaccessible, either due to being filled or due
1115 to "mail quota", important mail may be delayed or lost. Normally
1116 this would not happen without notice, but if both the sender and
1122Lindberg Best Current Practice [Page 20]
1124RFC 2505 Anti-Spam Recommendations February 1999
1127 receiver hosts have their disk flooded, the mail being returned
1128 may also fail, i.e. the email service may become less trustworthy
1131 o Hosts used as unauthorized Mail Relays become overloaded.
1132 Besides the technical implications, this too requires a lot of
1133 human resources, cleaning up mail queues and taking care of
1134 furious external users that were spammed through the Relay.
1136 o The fight against spammers includes blocking their hosts (which
1137 is described in this memo). However, there is a great risk that
1138 Mail Relay hosts may be blocked too, even though they are also
1139 victims. In the long run, this may cause Internet mail service to
1142 o The common use of forged "MAIL From:" and "From:" addresses puts
1143 the blame on innocent persons/hosts/organizations. This is bad
1144 for reputations and may affect business relations.
1146 Several of the methods described in this document increases the load
1147 on several support systems to the email system itself. Those support
1148 systems can be DNS, logging, databases with lists of local users,
1149 authentication mechanisms and others. Implementing the methods
1150 described in this document will, because of that, increase the risk
1151 of a denial of service attack against the support system by sending
1152 spam to a site. Logging facilities must for example be able to handle
1153 more logging (what happens when the logfiles fills the disk?). DNS
1154 servers and authentication mechanisms must be able to stand the load
1155 of more lookups etc.
1157 The functionality of the support systems during high load should be
1158 carefully studied before implementing the methods described in this
1161 The mail system should be carefully studied, e.g. how it behaves when
1162 one or more of the support systems needed for a specific method
1163 fails. A mail server MUST NOT respond with "Permanent Failure" (5xx)
1164 if there is a temporary problem with one of its support systems.
1168 This memo is the result of discussions in an ad hoc group of Swedish
1169 ISPs and Universities. Without any hope on mentioning everyone we
1170 simply give the domain names here: algonet.se, global-ip.net, pi.se,
1171 swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, and
1178Lindberg Best Current Practice [Page 21]
1180RFC 2505 Anti-Spam Recommendations February 1999
1183 We want to acknowledge valuable input and suggestions from Andras
1184 Salamon, John Myers, Bob Flandrena, Dave Presotto, Dave Kristol,
1185 Donald Eastlake, Ned Freed, Keith Moore and Paul Hoffman.
1187 Finally many thanks to Harald Alvestrand and Patrik Faltstrom, both
1188 for useful comments and for their support and guidance through the
1193 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
1196 [2] Crocker, D., "Standard for the format of ARPA Internet text
1197 messages", STD 11, RFC 822, August 1982.
1199 [3] Braden, R., "Requirements for Internet hosts - application and
1200 support", STD 3, RFC 1123, October 1989.
1202 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1203 Level", BCP 14, RFC 2119, March 1997.
1205 [5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
1206 13, RFC 1034, November 1987.
1208 [6] Mockapetris, P., "Domain Names - Implementation and
1209 Specifications", STD 13, RFC 1035, November 1987.
1211 [7] Eastlake, D. and C. Kaufman, "Domain Name System Security
1212 Extensions", RFC 2065, January 1997.
1214 [8] sendmail Home Page. http://www.sendmail.org
1216 [9] Gellens, R. and J. Klensin "Message Submission", RFC 2476,
1219 [10] Myers, J., "SMTP Service Extension for Authentication", Work in
1222 * Spam (R) (capitalized) is a registered trademark of a meat
1223 product made by Hormel. Use of the term spam (uncapitalized) in
1224 the Internet community comes from a Monty Python sketch and is
1225 almost Internet folklore. The term spam is usually pejorative,
1226 however this is not in any way intended to describe the Hormel
1234Lindberg Best Current Practice [Page 22]
1236RFC 2505 Anti-Spam Recommendations February 1999
1242 Computer Communications Group
1243 Chalmers University of Technology
1244 SE-412 96 Gothenburg, SWEDEN,
1246 Phone: +46 31 772 5913
1247 FAX: +46 31 772 5922
1248 EMail: lindberg@cdg.chalmers.se
1290Lindberg Best Current Practice [Page 23]
1292RFC 2505 Anti-Spam Recommendations February 1999
1295Full Copyright Statement
1297 Copyright (C) The Internet Society (1999). All Rights Reserved.
1299 This document and translations of it may be copied and furnished to
1300 others, and derivative works that comment on or otherwise explain it
1301 or assist in its implementation may be prepared, copied, published
1302 and distributed, in whole or in part, without restriction of any
1303 kind, provided that the above copyright notice and this paragraph are
1304 included on all such copies and derivative works. However, this
1305 document itself may not be modified in any way, such as by removing
1306 the copyright notice or references to the Internet Society or other
1307 Internet organizations, except as needed for the purpose of
1308 developing Internet standards in which case the procedures for
1309 copyrights defined in the Internet Standards process must be
1310 followed, or as required to translate it into languages other than
1313 The limited permissions granted above are perpetual and will not be
1314 revoked by the Internet Society or its successors or assigns.
1316 This document and the information contained herein is provided on an
1317 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1318 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1319 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1320 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1321 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1346Lindberg Best Current Practice [Page 24]