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
Submitted by Anonymous (not verified) on
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?
Spam fighting details
Submitted by Christoph Haas on
Yes, my /etc/mailname is "torf.workaround.org". Although the general rule is that the MUA (mail user agent = email client program) is responsible for setting the correct sender email address. It's considered bad style to just send mail as "johndoe" and then expect the MTA (mail transfer agene = mail server like Postfix) handle the completion to johndoe@torf.workaround.org.
The 212.12.58.158 is an IP address that belong to my network range but which I don't use. My firewall is set to drop SMTP requests (TCP 25) to that IP address and log that. So I can analyse the attempts to first use mx1 or mx4 instead of my real MX entry to detect spammers and blacklist them. Actually I don't think it's really important for that IP address to be forward resolvable. It's enough for spammers to try the wrong MX entries first. I will probably omit that reverse entry - t'was there for documentation reasons. I doubt a spammer would check the entries and look for the word "spam" in the PTR records. :)
The reason I chose DROP is that the remote (legitimate) server will assume that there is a problem with my network connectivity and try again. I have heard of mail servers who assume that a REJECTion means that there is no mail server on that IP address and drop the email. It's not an effect I have experienced myself yet though.
Christoph
Detecting & Blacklisting Spammers
Submitted by Anonymous (not verified) on
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
Submitted by Christoph Haas on
See here on information about such fake MX records. The idea of spammers is that the backup relay/MX servers may be set up less secure. Administrators set up a strong main server and just have a backup server in case the first servers goes down. So spammers often try to use the mail server with the lowest priority to deliver their crap.
I don't analyse anything automatically, yet. But if you see a delivery attempt first to your lowest priority then you can assume that something is at least unusual. There is a certain domain I haven't used actively any more for years but spammers hit that domain heavily. So I run a catchall account to feed spamassassin. And with information using the "fake MX records" technique I might be able to blacklist such people easier.
And if I'm lucky then spammers will just try the lowest priority MX and then let go.
Fake MX & Greylisting
Submitted by Anonymous (not verified) on
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?
Not exactly
Submitted by Christoph Haas on
It's not a replacement for greylisting and can be combined with it. Although the principle is similar. With greylisting you make sure that the remote server has a queueing system. With fake MX you make sure that spammers don't get through if they deliberately choose the mail server with the lowest priority. Both are just dirty tricks and I'm not sure how useful they are.
Dirty Tricks
Submitted by Anonymous (not verified) on
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).
Depends
Submitted by Christoph Haas on
Just because I use those tricks doesn't mean they are actually useful. :) I play around a lot.
The SMTP RFC will probably tell something about queueing and MX entries. But in real life it probably depends on the mail server software that you use. Postfix behaves correctly. And I haven't heard complaints from my few dozen users about that. Greylisting seems to delay incoming emails for longer (5-10 minutes) than fake MX entries do.
Regarding REJECT versus DROP: I would expect that both replies mean "there is no working mail server here accepting mail via SMTP" but somewhere I read that a REJECT may lead to the origin mail server to give up the delivery.
I'll have to observe whether spammers are using the lowest or highest priorised server without retrying. Might be interesting.
It has to be rejected!
Submitted by Anonymous (not verified) on
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.