RFC 2505

Anti-Spam Recommendations for SMTP MTAs

📅 published February 1999, from ietf

RFC 2505: Anti-Spam Recommendations for SMTP MTAs 💌

Okay bestie, here's the title block 🎀 This one is BCP 30, a Best Current Practice, so it's a guideline and not a protocol spec. It's by G. Lindberg from Chalmers University of Technology, dated February 1999. The header doesn't list anything it obsoletes or updates, so it's a standalone doc 🦋

Status of This Memo ✨

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌸

Okay so this memo gives a bunch of implementation recommendations for SMTP, [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) so they can do a better job of reducing the impact of spam(*) 💅

The goal is that these recommendations help clean up the spam situation, if they get applied on enough SMTP MTAs on the Internet, and that MTA vendors use them as guidelines. We're fully aware this isn't the final solution 🙈 But if these recommendations were included and used on all Internet SMTP MTAs, things would improve a lot and give us time to design a more long term solution. The Future Work section has some ideas that could be part of that long term solution. It's honestly possible that the ultimate fix is social, political, or legal, rather than technical 🫶

Heads up, the implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, more queries to DNS servers and bigger logfiles could both overload systems and crash them during an attack. Scary, but important 💀

Here's the quick summary:

  • Stop unauthorized mail relaying.
  • Spammers then have to operate in the open; deal with them.
  • Design a mail system that can handle spam.

1. Introduction ✨

This memo is a Best Current Practice (BCP) RFC. As such it should be used as a guideline for SMTP MTA implementors to make their products more capable of preventing and handling spam 🎀 Even though that's its main goal, a side effect is that it helps the sysadmin/Postmaster community figure out which "anti spam knobs" an SMTP MTA is expected to have 🔥

That said, this memo isn't really meant to explain how to operate an SMTP MTA, meaning which "knobs" to turn and how to set the options. When suggestions do show up, they'll be clearly marked and should be read that way 🧚

1.1. Background 🍓

Mass unsolicited electronic mail, often called spam(*), has shot up in a short amount of time and has become a serious threat to the Internet email community as a whole. Something needs to happen fairly quickly 😭

The problem has several parts:

  • It's high volume, i.e. people get a lot of this mail in their mailboxes.
  • It's completely "blind", i.e. there's no connection between the receivers' interests and the mail that gets sent to them (at least if you assume not everyone on the Internet is into porno pictures and spam programs...) 🙈
  • It costs real money for the receivers. Lots of receivers pay for the time it takes to transfer their mailbox from their (dialup) ISP to their computer, so they're literally paying real money for this 💸
  • It costs real money for the ISPs. Say one 10 Kbyte message gets sent to 10 000 users with their mailboxes at one ISP host. That's an unsolicited, unexpected storage of 100 Mbytes. A state of the art 4 Gbyte disk can take 40 of these message floods before it's full. It's almost impossible to plan ahead for these "storms" 😵
  • A lot of spam senders are dishonest. They hide behind false return addresses, deliberately write messages to look like they were sent between two individuals so the recipient thinks it was just misdelivered to them, claim the message is "material you requested" when you never asked for it, and generally do everything they can, with no regard for honesty or ethics, to get a few more people to look at their message. Not iconic behaviour 💅

Some spam programs even take pride in adding false info that will "make the ISPs scratch their heads" 🤯

It's usually the case that people who send in protests (often following the instructions in the mail) find their mail addresses added to more lists and sold to other parties 😤

  • It's pretty common to use third party hosts as relays to get spam sent out to the receivers. This theft of service is illegal in most, if not all, countries (at least in the US, spammers have been successfully sued). However, when the original sender is in the US, the (innocent) relay is in Sweden, and the list of receivers is back in the US, the legal process of getting damages from the spammers becomes extremely difficult. Main character problems, honestly 🌍

1.2. Scope 🦋

This memo has no intention of being the final solution to the spam problem. It's not the endgame, bestie 🎀

If, however, enough Internet MTAs did implement enough of the rules described below (especially the Non-Relay rules), we'd 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 make them appear openly, with their own hosts and domains, we can apply various access filters against them.) Realistically, a mix of legal and technical methods is likely to give the best result ⭐

That way, the spam problem could be reduced enough to let the Internet community design and deploy a real, general solution 💜

But, please note 👀

The Non-Relay rules are not in themselves enough to stop spam. Even if 99% of the SMTP MTAs implemented them from Day 1, spammers would still find the remaining 1% and use them. Or spammers would just switch gear and connect directly to each and every recipient host; that will be to a higher cost for the spammer, but is still quite likely.

Even though IPv6 deployment may be near, the spam problem is already here, so this memo sticks to the current IPv4 🌈

1.3. Terminology 💅

Throughout this memo we'll use the terminology of RFC2119, [4]:

  • "MUST"

This word or the adjective "REQUIRED" means that the item is an absolute requirement.

  • "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.

  • "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 this memo we sometimes say "host name" or "domain name," which should be read as a Fully Qualified Domain Name, FQDN 🎀 We mean the name returned from DNS in response to a PTR query (.IN-ADDR.ARPA), i.e. when an IP address gets translated to a name. We also mean a name that has a DNS A or MX record attached to it, RFC1034, [5], and RFC1035, [6].

When we suggest using FQDNs instead of IP addresses, it's because FQDNs are way easier to use, intuitively. However, all that usage depends heavily on DNS and .IN-ADDR.ARPA (PTR) info. It's pretty easy to forge that, either through false cache info injected into DNS servers or through spammers running their own DNS with false info in it. So host and domain names have to be used with care, e.g. verified so the address-to-name translation matches the name-to-address one 🕵️‍♀️ With Secure DNS, RFC2065, [7], things will get better, since spoofing of .IN-ADDR.ARPA won't be possible anymore 🔥

One of the recommendations is about verifying MAIL From: (envelope originator) domains with DNS, i.e. making sure appropriate DNS info exists for the domain. When you use this capability there are a few things to think about:

(1) Don't forget about the increased number of DNS queries, which could be a problem for the DNS server itself to handle. This alone can lead to a denial of service attack against the DNS server, just by sending email to a site 😬

(2) Note that with negative caching in DNS, forged DNS responses can be used to mount denial of service attacks. For example, if a site is known to run a FQDN validity check on addresses in SMTP MAIL From: commands, an attacker may be able to use negative DNS responses to effectively block acceptance of mail from one or more origins. Because of this, you should carefully check the DNS server you're using, e.g. how it verifies that incoming responses match outstanding queries, to minimize the risk of these attacks 🛡️

(3) For early versions of spam software, FQDN checks give quite a lot of relief, since that software generates mail with completely bogus MAIL From: values that never get into the system if they're verified with DNS. This is in active use at many installations today, and it does reduce spam 🎉

On the other hand, sites with weak DNS connectivity may find their legit mail having trouble reaching destinations because of DNS timeouts when receivers verify their MAIL From:. However, since DNS info is handled asynchronously and gets cached even after the initial requester has given up, chances are high that the info is there at a later attempt 🙏

For later versions of spam software, checking MAIL From: is much less likely to help, since spam software evolves too and will start using existing mail addresses (whether or not that's legal is beyond the scope of this memo). But at least the Internet benefits from the side effect that this test stops typos and misconfigured UAs 🌸

1.5. Where to block spam, in SMTP, in RFC822 or in the UA 🚫

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. Here's why that's the move 💖 First, we don't have to store a copy of a message we later decide to refuse. Second, our responsibility for that message is low or none, since we haven't read it in yet, so we leave it to the sender to handle the error ✨

1.6. SMTP Return Codes ✨

okay so SMTP has a few classes of Return Codes, and [1] has the full tea if you want it 💅

  • 5xx is a Permanent Negative Completion reply (Fatal Error) 💀. It terminates the mail transfer and the mail gets returned to sender.
  • 4xx is a Transient Negative Completion reply (Temporary Error) ⏳. The mail transfer gets put back on queue and a new attempt is made later.
  • 2xx is a Positive Completion reply 🌸. It means the MTA has now taken responsibility for delivering the mail.

When you start using the options/"knobs" in this memo, there are a few things to keep in mind 🧠:

For stuff like "Denied - you're on the spammer's list", a 5xx might be the right move, bestie, because it ends the session right away and we're done 🙅‍♀️. (That's IF the spammer plays by the SMTP rules, which, spoiler, he might not! He can put the mail back on queue or just turn to some other host, no matter what Return Code he gets 🙄.) But a 5xx mistake in a config can make legit mail bounce, and that is lowkey a disaster 😭.

So we suggest 4xx as the Return Code for most cases 🎀. Since it's a non fatal error, the mail gets re-queued at the sender, and we get some time to find and fix config mistakes instead of the mail bouncing. (This usually happens when we refuse to Relay for domains we actually should accept, since we're on their MX list.)

A 4xx also makes the spammer's host re-queue the mail. If it's his own host doing that, honestly, it's probably a good thing: fill up his disks with his own spam 🤭. But if he's using someone else as Relay Host, all that queued spam is pretty strong evidence that something bad is going on, and it should get attention at that Relay Host 🚨.

BUT, 4xx Temporary Errors can cause unexpected drama with MX-records 🙃. If the receiving domain has several MX records and the lowest preference MX-host refuses mail with a "451" Response Code, the sending host may choose to (and often will!) use the next host on the MX list.

If that next MX host doesn't have the same refuse-list, it'll obviously accept the mail, only for us to find out the final host still refuses that piece of mail ("MAIL From:") 😩. The plan was to keep the offending mail stuck 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 🥲.

Finally, someone suggested you could send back a 2xx Return Code but still not forward or receive the spam, with typical alternatives like storing it elsewhere (e.g. /dev/null). Girl, this clearly violates the intent of RFC821 🚫, and you should not do it without careful consideration. Instead of blindly dropping the mail, you could re-queue it and manually (or automagically) inspect whether it's spam or legit, and whether it should be dropped or forwarded 🧐.

1.7. Mailing Lists

Okay, so an MTA that can also handle mailing lists (and expand them out to a bunch of recipients) needs to be able to authorize senders and protect its lists from spam 📬. The mechanisms for that may be very different from those for ordinary mail and ordinary users, and this memo doesn't cover them 🫶.

2. Recommendations

Here's the vibe: first a quick list of recommendations ✨, then a more thorough breakdown of each one. We'll also cover things NOT to do 🙅‍♀️, stuff that might feel natural in the spam fight (and might even work... so far) but could wreak havoc on Internet mail and cause more damage than good 💀.

  • 1) MUST be able to restrict unauthorized use as Mail Relay 🚧.
  • 2) MUST be able to provide "Received:" lines with enough information to make it possible to trace the mail path, despite spammers using forged host names in HELO statements etc.
  • 3) MUST be able to provide local log information that makes it possible to trace the event afterwards.
  • 4) SHOULD be able to log all occurrences of anti-relay/anti-spam actions.
  • 5) SHOULD be able to refuse mail from a host or a group of hosts.
  • 6a) MUST NOT refuse "MAIL From: <>" 🙅‍♀️.
  • 6b) MUST NOT refuse "MAIL From: <user@my.local.dom.ain>" 🙅‍♀️.
  • 7a) SHOULD be able to refuse mail from a specific "MAIL From:" user, <foo@domain.example>.
  • 7b) SHOULD be able to refuse mail from an entire "MAIL From:" domain <.*@domain.example>.
  • 8) SHOULD be able to limit ("Rate Control") mail flow 🚦.
  • 9) SHOULD be able to verify "MAIL From:" domain (using DNS or other means).
  • 10) SHOULD be able to verify <local-part> in outgoing mail.
  • 11) SHOULD be able to control SMTP VRFY and EXPN.
  • 12) SHOULD be able to control SMTP ETRN.
  • 13) MUST be able to configure to provide different Return Codes for different rules (e.g. 451 Temp Fail vs 550 Fatal Error) 🎛️.

Heads up: the discussion below keeps needing all kinds of pattern matching on domain/host names and IP addresses/subnets 🧩. It is RECOMMENDED that the data/template for that may be supplied from outside the MTA, e.g. the pattern matching rules live in the MTA but the actual patterns may sit in an external file. It is also RECOMMENDED that the pattern matching rules (the external file) may contain regular expressions, for maximum flexibility 💖.

Of course, string matching on domain/host names MUST NOT be case sensitive 🙅‍♀️. Since <local-part> may be case sensitive, it may feel natural to keep that here. However, since <sPAmMeR@domain.example> and <spammer@domain.example> are most probably the same user, and string compares are used to refuse his messages, we suggest that <local-part> comparisons be case insensitive too 🕵️‍♀️.

The vibe for all these recommendations is flexibility 🦋. No matter how well we design anti-spam rules today, spammers will find ways around them, so a well designed MTA should be flexible enough to handle those new threats 💪.

2.1. Restricting unauthorized Mail Relay usage

Unauthorized usage of a host as Mail Relay is basically stealing the relay's resources, and it puts the relay owner's reputation on the line 😤. It also makes it impossible to filter out or block spam without blocking legit mail at the same time 🙃.

So, the MTA MUST be able to control/refuse that kind of Relay usage 🚧.

In an SMTP session there are 4 elements, each with a different level of trust 🔍:

1)  "HELO Hostname"           Easily and often forged.
2)  "MAIL From:"              Easily and often forged.
3)  "RCPT To:"                Correct, or at least intended.
4)  SMTP_Caller (host)        IP.src addr OK, FQDN may be OK.

Since 1) and 2) are so easily and often forged, we can't depend on them 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 combo of:

  • "RCPT To:" address (domain).
  • SMTP_Caller FQDN hostname.
  • SMTP_Caller IP address.

Here's the suggested algorithm 🧠:

  • 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 FQDN (depending on if you trust the DNS), then accept to Relay ✅.
  • c) Else refuse to Relay ❌.

When you're doing a), make sure all kinds of SMTP source routing (both the official [@a,@b:u@c], the '%' hack and uucp-style '!' path) is either removed completely before the test, or at least taken into account 🧹.

Any site doing this must also be aware it might block correctly addressed messages 👀, especially ones originating or terminating in a gateway to a different mail system than SMTP. Before implementing a policy like this, a careful inventory should be done to make sure all the routing algorithms in use, whether from other mail systems or ad-hoc, are known. Each one of those systems must be taken care of on a case-by-case basis 🗂️.

Examples of these mail systems and their addressing schemes: X.400, with an address of the type:

"/c=us/admd= /prmd=xyz/dd.rfc-822=user(a)final/"@x400-gateway

Another example is DECnet MAIL-11, which can have addresses like this:

"gateway::smtp%\"user@final\""@mail-11-gateway

In all cases, the configuration MUST support wild cards for FQDNs and classful IP addresses, and SHOULD support "address/mask" for classless IP addresses 🌈. For example: 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 the decision/template data to come from an external source, e.g. a 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 to the mail (as described in RFC822, [2], and required in RFC1123, [3]) 📨. This Received: line MUST contain enough info to make it possible to trace the mail path back to the sender. There are two cases:

2.2.1. Direct MTA-to-MTA connections

Internet mail was designed so the sending host connects directly to the recipient, as described by MX records (there may be several MX hosts on a priority list) 🌐. To make sure you can trace things 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. For this kind of Received: line, we have:

It MUST contain:

  • The IP address of the caller.
  • The 'date-time' as described in RFC822, [2], pp 18.

It SHOULD contain:

  • The FQDN corresponding to the callers IP address.
  • The argument given in the "HELO" statement.
  • Authentication information, if an authenticated connection was used for the transmission / submission.

It's suggested that most of the other Received: fields described in RFC822 get included in the Received: lines 🎀.

Basically, any info that can help trace the message can and should go in the Received: line 🔎. This is true even when the initial submission is non-SMTP, like submitting through a web-based mail client where http is used between the web client and server. A Received: line can be used to identify that connection, stating what IP address was used when connecting to the http server where the mail was created 🕸️.

These recommendations are deliberately stronger than RFC1123, [3] 💪, and they exist to make sure mail sent directly from a spammer's host to a recipient can be traced with enough accuracy. A typical example: a spammer uses a dialup account, and the ISP needs his IP address at the 'date-time' to be able to take action against him 🫵.

2.2.2. Firewall/gateway type devices 🧱✨

okay so organizations with a policy of hiding their internal network structure are still totally allowed to do that, and they must still be able to do so 🙈 They usually make their internal MTAs prepend "Received:" lines with a super limited amount of info, or prepend none at all 🤫 Then the mail goes out through some kind of firewall/gateway device, which may even strip out all the internal MTAs' "Received:" lines before it adds its own "Received:" line (as required in RFC1123, [3]) 💅

By doing that, they take on full responsibility for tracing spammers who send from inside their organization. Or they accept being held responsible for those spammers' activities 😭 It is REQUIRED that the info in their outgoing mail is enough for them to do any traces they need 🔍

For incoming mail to an organization, the "Received:" lines MUST be kept intact 🫶 That way, users receiving mail on the inside can give the info needed to trace incoming messages back to their origin.

Generally, a gateway SHOULD NOT change or delete "Received:" lines unless it's a security requirement to do so. Rewriting the content of existing "Received:" lines so they "make sense" when passing through a mail gateway usually destroys and deletes the info needed to make a message traceable 💀 Care must be taken to preserve the info in "Received:" lines, either in the message itself, in the mail the receiver gets, or, if that's impossible, in logfiles 📁

2.3. Event logs 📝

The MTA MUST be able to provide enough local log info to make it possible to trace the event 🕵️‍♀️ This includes most of the info that goes into the "Received:" lines, see above.

2.4. Log anti-relay/anti-spam actions 🚨

The MTA SHOULD be able to log all anti-relay/anti-spam actions. The log entries SHOULD contain at least:

  • Time information.
  • Refusal information, i.e. why the request was refused ("Mail From", "Relaying Denied", "Spam User", "Spam Host", etc).
  • RCPT To: addresses (domains). (If the connection was disallowed at an earlier stage, e.g. by checking the SMTP_Caller IP address, the RCPT To: address is unknown and therefore cannot be logged 🙃)
  • Offending host's IP address.
  • Offending host's FQDN hostname.
  • Other relevant information (e.g. given during the SMTP dialogue, before we decided to refuse the request).

Heads up: it should be noted that logging more events, especially denied email, opens the door to denial of service attacks 😬 For example, someone could fill up the logs by sending a huge number of RCPT To: commands. An implementation that adds this extra logging must be aware that logfiles get bigger, especially during attacks 📈

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 FQDN that its .IN-ADDR.ARPA resolves to (depending on whether you trust the DNS 🤔). This could be done at a firewall, but since the MTA should be able to "defend itself," we recommend it be able to do it too 🛡️

It is RECOMMENDED that the MTA be able to decide based on FQDN 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 into 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

The list is searched until the first match, and the accept/refuse action is based on that 🎯

IP-address/length is RECOMMENDED. Implementations with wild cards, e.g. 10.11.12.* (classful networks on byte boundaries only), are of course much better than those without 💖

To improve filtering even more, the MTA MAY provide complete regular expressions to be used for hostnames, and possibly for IP addresses too 🧠

2.6. "MAIL From: <>" and "MAIL From: <user@my.local.dom.ain>" 💌

Even though fighting spammers is important, it must never be done in a way that violates existing email standards 🙅‍♀️ Spammers often forge "MAIL From:" addresses, so it's tempting to put general restrictions on that, especially for some "obvious" addresses. But this may wreak more havoc on the mail community than spam does 💀

When there's a need to refuse mail from a particular host or site, our recommendation is to use the other methods mentioned in this memo, e.g. refuse mail based on SMTP_Caller address (or name), no matter what "MAIL From:" was used ✨

2.6.1. "MAIL From: <>" 📭

The MTA MUST NOT refuse to receive "MAIL From: <>".

The "MAIL From: <>" address is used in error messages from the mail system itself, e.g. when a legitimate mail relay is used and forwards an error message back to the user. Refusing to receive that mail means users may not be notified of errors in their outgoing mail, e.g. "User unknown", and that will no doubt wreak more havoc on the mail community than spam does 😭

The most common case of a legitimate "MAIL From: <>" is sending to one recipient, i.e. an error message returned to one single individual. Since spammers have used "MAIL From: <>" to send to many recipients, it's tempting to either reject such mail completely or reject all but the first recipient. However, there are legitimate reasons for an error mail to go to multiple recipients, e.g. a list with several list owners, all located at the same remote site. So the MTA MUST NOT refuse "MAIL From: <>" even in this case 🫶

However, the MTA MAY throttle down the TCP connection ("read()" frequency) if there's more than one "RCPT To:", and that way slow down spammers using "MAIL From: <>" 🐢

2.6.2. "MAIL From: <user@my.local.dom.ain>" 🏠

The MTA MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".

By "my.local.dom.ain" we mean the domain name(s) that are treated as local and result in local delivery. At first thought it might seem like no one else will need to use "MAIL From: <user@my.local.dom.ain>", and that restricting who may use it would reduce the risk of fraud and thus reduce spam. While that may be true in the (very) short term, it also wipes out at least two legitimate uses:

  • Aliases (.forward files). <user1@my.local.dom.ain> sends to <user2@external.example>, and that mail gets forwarded back to <user2@my.local.dom.ain>, e.g. since <user2> has moved to my.local.dom.ain and has a .forward file at external.example 📬
  • Mailing lists. RFC1123, [3], gives a clear requirement that "MAIL From:" for mail from a mailing list should reflect the owner of the list, rather than the individual sender. Because of this, and because the owner of the list might not be in the same domain as the list (list host) itself, mail may arrive at the list owner's domain (mail host) from a foreign domain (from a host serving a foreign domain) with the list owner's local domain in the "Mail From:" command 💜

If "MAIL From: <user@my.local.dom.ain>" is rejected, both of these cases will result in failure to deliver legitimate mail 💀

2.7. 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 these kinds of rules are easily overcome by spammers changing "MAIL From:" every so often 🙄 But being able to block a certain user or a certain domain is super helpful while an attack has just been discovered and is still going on 🔥

Please note that

"MAIL From: <>"

and

"MAIL From: <user@my.local.dom.ain>"

MUST NOT be refused (see above), except when other policies block the connection, for example when the SMTP_Caller IP address of the peer belongs to a network that's deliberately refused 🧱

2.8. Rate Control 🐌

The MTA SHOULD provide tools for the mail host to control the rate at which mail is sent or received. The idea is twofold:

  1. If we happen to have a legitimate mail user with an existing legitimate account who sends out spam, we may want to reduce the speed at which they send it out. This is not without controversy and must be used with extreme care, but it may protect the rest of the Internet from them 🫠
  2. If we're under a spam attack, it may help us a lot to be 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. by reducing the "write()" frequency.

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 right now 📥 It is RECOMMENDED that the decision to take such action be based on the "MAIL From:" user, the "MAIL From:" domain, the SMTP_Caller (name/address), "RCPT TO:", or a combination of all of these 🎀

2.9. Verify "MAIL From:" ✅

The MTA SHOULD be able to perform a simple "sanity check" on the "MAIL From:" domain and refuse to receive mail if that domain is nonexistent (i.e. does not resolve to having an MX or an A record) 🔍 If the DNS error is temporary, TempFail, the MTA MUST return a 4xx Return Code (Temporary Error). If the DNS error is an Authoritative NXdomain (host/domain unknown), the MTA SHOULD still return a 4xx Return Code (since this may just be primary and secondary DNS not being in sync 🔄), but it MAY allow for a 5xx Return Code (as configured by the sysadmin) 🧑‍💻

2.10. Verify <local-part> 🧐

The MTA SHOULD allow outgoing mail to have its <local-part> verified, so 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: <fo0bar@domain.example>

and/or from malicious users:

MAIL From: <I.am.unknown.to.you.he.he@domain.example>

As always, spammers who really want to can get around this, but with stricter rules for relaying it gets harder and harder for them 💪 In fact, catching "typos" at the initial (and official) mail relay is reason enough for this recommendation all on its own ✨

2.11. SMTP VRFY and EXPN 🕵️

Both SMTP VRFY and EXPN give a potential spammer ways to test whether the addresses on their list are valid (VRFY), and even to get more addresses (EXPN) 😤 Therefore, the MTA SHOULD control who is allowed to issue these commands. This may be "on/off," or it may use access lists similar to the ones mentioned previously.

Note that the "VRFY" command is required according to RFC821, [1]. The response can, though, be "252 Argument not checked" to represent "off" or blocked via an access list. This should be the default 🔒

Default for the "EXPN" command should be "off" 🙅‍♀️

2.12. SMTP ETRN 🌪️

SMTP ETRN means the MTA will re-run its mail queue, which may be pretty costly and open the door to Denial of Service attacks 😩 Therefore, the MTA SHOULD control who is allowed to issue the ETRN command. This may be "on/off," or it may use access lists similar to the ones mentioned previously. Default should be "off" 💜

2.13. Return Codes

okay so the big thing here is flexibility 💖 you literally cannot write down in a doc how to balance returning 5xx (which makes legit mail bounce if there's a config oops 😭) against returning 4xx (which lets you catch those oops in the log files 🔍). it's a vibe-check decision, no cap.

So the MTA MUST be configurable to give "Success" (2xx), "Temporary Failure" (4xx) or "Permanent Failure" (5xx) for different rules or policies ✨. The exact codes, apart from the first digit (2, 4 or 5), should not be configurable 🙅‍♀️. Why? Because it's SO easy to configure the software wrong, picking the exact error code is super subtle, and lots of software implementations actually check more than just the first digit 💀.

However, when the response comes from a DNS lookup and the DNS system returned TempFail (a temporary error), the MTA MUST reflect that and give a 4xx return code 🫶. If the DNS response is an Authoritative NXdomain (host or domain unknown), the MTA MAY reflect that with a 5xx Return Code 🌸.

Go check the previous discussion on SMTP Return Codes for more deets 💅.

2.13.1. The importance of flexibility - an example ✨

At Chalmers University of Technology, our DNS contains

cdg.chalmers.se.  IN  MX    0   mail.cdg.chalmers.se.
                  IN  MX  100   mail.chalmers.se.

and similarly for most subdomains, i.e. a second host to store mail to each subdomain, should their mail host be down 🧚. This means that mail.chalmers.se must be prepared to act as Mail Relay for the subdomains ("RCPT To:") it serves, and that those subdomains' mail hosts have to accept SMTP connections from mail.chalmers.se. Late versions of spam software make use of this fact by always using mail.chalmers.se to get their mail delivered to our subdomains. By doing so, they still get Mail Relaying done for them, and they stop recipient hosts from refusing SMTP connections based on the sending host's FQDN or IP address 👀.

As long as we keep our design with a secondary MX host, we cannot really have mail.chalmers.se refuse Mail Relay, at least not with a 5xx return code 😤. However, it has been fairly straightforward to identify the hosts, domains and networks that make use of this possibility, and refuse to act as Mail Relay for them (and only them) with a 4xx return code 🎀. Legit mail from them may be delayed if the final recipient host is down, but it will eventually be delivered when it gets back up (4xx Return Code), and this is no worse than if we changed our MX design 🦋. Spam now faces a "Denied" response and has to connect to each and every one of the recipients, who may decide to refuse the SMTP connection 💀.

The bottom line is that this is only possible because of 1) enough flexibility in the Relay Authorization code and 2) enough flexibility in assigning Return Codes. An MTA with a 5xx Return Code carved in stone would have made this absolutely impossible 🪨🚫.

3. Future work

3.1. Impact on SMTP UAs and end users 📱

Even though this memo is about MTAs and recommendations for them, some of what's done here also impacts UAs (User Agents, the "ordinary mail programs") 💌.

A UA does two things:

  1. Reads mail from a mailbox and prints it 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 start to implement various anti-relay filters as described above, a UA on a portable laptop may get a response like "Relaying Denied" just because it happens to use IP addresses within an unknown range, or addresses that resolve to unknown FQDNs 😩.

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 get an IP address from that dialup pool; the IETF delegate will use an IP address from the terminal room. In both cases, their laptop mail program (the UA; e.g. pine, Netscape, Eudora) will try to send mail out 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 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. As long as we don't open up for the entire world all the time, we keep the log files under close observation, and we stop relaying the moment we find we're being used, this solution is probably good enough 🤞.

Another way around is for our salesman to use 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 with some other mail-sending protocol between the UA and the MTA 👑.

Although a separate submission protocol does not exist, a profile of SMTP for this, the "Message Submission" specification, [9], has recently been defined 📜.

Or, we could note that when the SMTP Authentication work, [10], is all in place, it will allow 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 in section 2.1:

+   If "SMTP Authenticated" then accept to Relay.

3.2. Personal anti-spam filters 🙅‍♀️📵

Since all users are individuals, there's little hope that any central anti-spam action will suit them all. In fact, people can and do argue about Freedom of Speech infringement if some central set of anti-spam rules is enforced without the users' approval 🗣️. (One could of course also argue about whether spam really adds anything to anyone, but that must be up to each individual user to decide, rather than being centrally decided 💅.)

So 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 won't 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 have something like:

/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'll deal with a mix of 5xx and 4xx codes:

    C  MAIL From: <usr@spam.example>
    S  250 <usr@spam.example>... Sender ok
    C  RCPT To: <usr@domain.example>
    S  250 <usr@domain.example>... Recipient ok
    C  RCPT To: <foo@domain.example>
    S  451 <foo@domain.example>... Denied due to spam list
    C  RCPT To: <bar@domain.example>
    S  550 <bar@domain.example>... Denied due to spam list

Of course, one could decide on either "250 OK" or "550 Denied" with no other alternatives for the individual user. But this too has to be explained well enough that an ordinary user understands the implications of "Refuse 'MAIL From: <.*@spam.example>'", and that it can wipe out or block mail he actually wanted 😭.

3.3. SMTP Authentication 🔐✨

SMTP Authentication, [10], has already been mentioned as a method to authorize Mail Relaying, but of course there's 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 🕵️‍♀️💜.

3.4. Spam and NATs 🌐

With the increased use of Network Address Translators (NATs), there may be a need for additional information in log files 📝. As long as there's a 1:1 mapping between the addresses inside the NAT and the addresses used outside it, everything is OK 🙌. But if the NAT box also translates port numbers (to combine many internal hosts into one external address), we will need to log not only the IP addresses of spam hosts but also the port numbers 🧩. Otherwise, we won't be able to identify the individual host inside the NAT 😵‍💫.

4. Security Considerations 🚨

Okay, bestie, this part is serious. The grassfire-like spread of spam raises several security issues that, honestly, put the whole Internet mail community at risk 😭

  • People may fail to find important mail in their flooded mailboxes. Or, they may delete it while cleaning up.
  • ISPs get overloaded mailbox hosts and filled disks. Cleaning up and helping customers takes a huge amount of human resources. In fact, ISP mail servers have crashed from too much mail 💀
  • While disks are unaccessible, either because they're full or because of a "mail quota", important mail may be delayed or lost. Normally this wouldn't happen without notice. But if both the sender and receiver hosts have their disks flooded, the mail being returned may also fail. The email service could become less trustworthy than before 💔
  • Hosts used as unauthorized Mail Relays become overloaded. Besides the technical implications, this also takes a lot of human resources, like cleaning up mail queues and dealing with furious external users who got spammed through the Relay 😤
  • The fight against spammers includes blocking their hosts, which is described in this memo. However, there's a big risk that Mail Relay hosts get blocked too, even though they're also victims. In the long run, this could make Internet mail service deteriorate 🥀
  • The common use of forged "MAIL From:" and "From:" addresses puts the blame on innocent persons, hosts, and organizations. This is bad for reputations and may affect business relations 🫠

Several of the methods described in this document increase the load on support systems around the email system itself. Those support systems can be DNS, logging, databases with lists of local users, authentication mechanisms, and others. So implementing the methods described here will increase the risk of a denial of service attack against the support system, by sending spam to a site. Logging facilities, for example, must be able to handle more logging. (What happens when the logfiles fill the disk?) DNS servers and authentication mechanisms must be able to stand the load of more lookups, and so on 📉

The functionality of the support systems during high load should be carefully studied before implementing the methods described in this document. Please don't skip this one, it matters 🙏

The mail system should be carefully studied too, for example how it behaves when one or more of the support systems needed for a specific method fails. A mail server MUST NOT respond with 5xx ("Permanent Failure") if there is a temporary problem with one of its support systems. That's a must-not, no exceptions 🛑

5. Acknowledgements 🫶

This memo is the result of discussions in an ad hoc group of Swedish ISPs and Universities. Without any hope of mentioning 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, Dave Kristol, Donald Eastlake, Ned Freed, Keith Moore, and Paul Hoffman 💜

Finally, many thanks to Harald Alvestrand and Patrik Faltstrom, both for useful comments and for their support and guidance through the IETF process 🌸

6. References 📚

  • [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
  • [2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
  • [3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
  • [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
  • [5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
  • [6] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
  • [7] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
  • [8] sendmail Home Page. http://www.sendmail.org
  • [9] Gellens, R. and J. Klensin "Message Submission", RFC 2476, September 1998.
  • [10] Myers, J., "SMTP Service Extension for Authentication", Work in Progress.

Also, a little footnote-style fun fact 🤓

Spam (R) (capitalized) is a registered trademark of a meat product made by Hormel. Use of the term spam (uncapitalized) in the Internet community comes from a Monty Python sketch and is almost Internet folklore. The term spam is usually pejorative, 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 SE-412 96 Gothenburg, SWEDEN,

Phone: +46 31 772 5913 FAX: +46 31 772 5922 EMail: lindberg@cdg.chalmers.se

Okay, legal stuff, but it's important so read it, bestie 🎀

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

📦 where this page comes from