DNS

DNS is short for "domain name system" and is the magic on the internet that turns names like "www.workaround.org" into IP addresses like "212.12.58.129". If you want to receive email for a certain domain you need to be in charge of its "zone" which contains the actual "records". The zone file for "workaround.org" contains an A (address) record so that you can view this website. And among other records it contains an MX (mail exchanger) record telling which servers should be used when someone sends an email to devnull@workaround.org. This is a simplified extract of the zone file:

IN  TXT  "v=spf1 ip4:212.12.58.128/27 -all"
IN  MX      10 mx1.workaround.org
IN  MX      20 mx2.workaround.org
IN  MX      30 mx3.workaround.org
IN  MX      40 mx4.workaround.org
IN  A    212.12.58.129

The "IN" is the class of the records. On the internet it's always "IN".  The second column designates the record type:

  • TXT = Text record (can be any text up to 255 characters) - used for SPF here (will be described later in the tutorial)
  • MX = Mail Exchanger record (designates the email server responsible for this domain)
  • A = Address record (default entry)

How other mail servers find your mail server

Imagine that some mail server on the internet has an email for your domain in its queue. Now it needs to find out which IP address to connect and send the email via the SMTP protocol. First it does a DNS lookup for an MX record of the domain used in the email address. If it gets several addresses back it will try the servers mentioned in the response beginning with the servers having the highest priority (=smallest number) assigned. If it doesn't reach it then it will try the next mail server in order. If the mail server did not find any MX entries then it will try another DNS lookup for an A record and send the email there.

Let's try an example. You want to send an email to devnull@workaround.org. So the domain is apparently the "workaround.org" part. Is there an MX entry? You can try that yourself using the dig tool. ("host" or "nslookup" will work equally well. Install dig using "aptitude install dnsutils" if you haven't already.)

$> dig +short workaround.org mx
30 mx3.workaround.org.
40 mx4.workaround.org.
10 mx1.workaround.org.
20 mx2.workaround.org.

So there are four mail servers in question. The one with the highest priority (10) is mx1.workaround.org. Let's find out its IP address by asking for an A record of this hostname:

$> dig +short mx1.workaround.org
212.12.58.158

The mail server will now try to reach the mail server on this IP address on TCP port 25 (SMTP) and attempt to deliver the email. Incidentally (or maybe not) the mail server does not appear to be reachable. There are no more mail servers with priority 10 so it tries the next best mail server mx2.workaround.org with priority 20. Which IP address does it have?

$> dig +short mx2.workaround.org
212.12.58.129

This mail server works better and the SMTP connection is established and the email delivered.

So in order to receive email for a domain you need to set at least one MX entry in its zone to point to your mail server. Note that an MX entry points to a hostname - never an IP address. If you can't add MX entries then an A record will do, too.

9 Comments

DNS & Reverse DNS Setup

So for sending emails, it all comes down to the postfix using the correct identification (from myorigin = / etc/mailname), and that the Reverse DNS entry for the used IP matches myorigin, right?

And for receiving emails, it all comes down to the MX DNS entries, which do not have to be the same as myorigin / the Reverse DNS entry, right?

So mx2.workaround.org -> 212.12.58.129 -> torf.workaround.org is your mailserver, which means torf.workaround.org is your myorigin = / etc/mailname.

And with mx1/3/4.workaround.org -> 212.12.58.158 -> spam-relay.workaround.org -> "Host spam-relay.workaround.org not found: 3(NXDOMAIN)", why do you have such an obvious Reverse DNS entry for that IP (or why a Reverse DNS entry for that IP at all), which additionally does not lead anywhere?

I also would like to know, what 212.12.58.158 exactly does on port 25. Is there just a -j DROP, or any kind of -j RECECT?

Detecting & Blacklisting Spammers

You wrote: "So I can analyse the attempts to first use mx1 or mx4 instead of my real MX entry to detect spammers and blacklist them."

It would be VERY interesting to see, how you do that. But I don't quite understand, because every sender is supposed to try mx1 first, so what to analyse there? Sounds like there is some sophisticated checking going on there, did you write a script? I mean, first you have to find out, if the spammer to blacklist only tried mx1, but not mx2 afterwards, then if he tried to use the last or a random one, except mx2. And then how does the actual blacklisting work then?

That idea is great, but I have no clue, how I could implement it.

Fake MX & Greylisting

Ok, so AFAIK that trick with fake MX entries is meant to be a replacement for greylisting, and can not be combined with server-side greylisting, right?

Dirty Tricks

You are using that dirty DNS trick yourself, so it has to be useful. ;-)

I already did some research, and both tricks are indeed useful, but I am not entirely sure, if they really can be combined.

With fake DNS entries you have to take care, that the fake MX with the highest priority rejects the connection on ports smtp/ssmtp (not just drop, and no temporary error, but an iptables -j REJECT), because otherwise it's possible that the next one is not tried (that's at least true for qmail). The real MX better be on the entry with the second highest priority, otherwise the delay may get to big. The other fake MX entries are just for the case, a spammer is trying a random entry or the one with the lowest priority. I have now altogether 9 entries, all but the real one poiting to an IP with connections to ports smtp/ssmtp being rejected.

The problem is now, that the remote mailserver already has been rejected on MX1, so he tries the real one on MX2. If you do greylisting on that one, it means the remote mailserver gets a temporary error response from your postfix (usually the error 450). Is it then ensured, that the remote mailserver will then try again MX2, and does not go on with the MX entries of lower priority?

If it tries MX2 again, everything is alright, but if it steps through the MX entries with lower priority (on which it gets rejected), will it then start all over with the MX entry of the highest priority again, or just give up?

I could not find any info on that, and it even gets more complicated, if different mailservers behave differently in such a situation (for which at least qmail is known for).

It has to be rejected!

REJECT vs. DROP: You have to reject on MX1, because that's the only one which leads to an immediate result:

# telnet mx1.workaround.org smtp
Trying 212.12.58.158...
telnet: Unable to connect to remote host: Connection refused

Which means you are using -j REJECT on MX1, because a -j DROP would result in waiting until timeout, which can take quite a while (a DROP does not give a reply to the other side). With a -j DROP it would look like this:

# telnet mx1.workaround.org smtp
Trying 212.12.58.158...
.
.
. (takes quite some time, usually several minutes)
.
.
telnet: Unable to connect to remote host: Connection timed out

I am confident about the usefulness of the fake MX trick, but I am not entirely convinced about the additional greylisting on the real MX. It only works (it it most likely indeed does in all cases), if the remote server really comes back after a reject on MX1, the 450 temp error on MX2 (if greylisted), and the rejects on all the other MX entries with lower priority.