I have two hosts as MX for the domain bitsex.net – m.juicedhost.net and juicedhost.net. Good practice would be to configure both to act as MX for that domain, but I never got around to configuring the MX with the lowest priority, juicedhost.net, to relay mail for bitsex.net. Maybe as well.
Even when the highest priority MX, m.juicedhost.net, is up, I get quite a few hits to juicedhost.net, which has the lowest priority. All of those hitting juicedhost.net seems to be spammers, as it is requests directly from a end user’s PC:
2008-11-06 07:08:06 H=([119.94.191.31]) [119.94.191.31] F= rejected RCPT <[...]@bitsex.net>: relay not permitted
2008-11-06 08:54:09 H=([61.153.52.7]) [61.153.52.7] F= rejected RCPT <[...]@bitsex.net>: relay not permitted
2008-11-06 10:43:29 H=pool-96-232-98-212.nycmny.fios.verizon.net [96.232.98.212] F= rejected RCPT <[...]@bitsex.net>: relay not permitted
I’ve removed the user part of the email address, but it is valid users on this domain! And the sender seems to be a dynamic address from the ISP Verizon, quite possibly handed out to an individual with a infected computer.
Why do spammers choose the MX with least priority? Because they guess it’s just set up as an relay agent, that does not check if the user actually exists, but just stores/relays the mail to the primary MX? Even so, it seems to be a nice trick for avoiding some spam.
It’s probably bad practice to have a backup MX not accepting email, but it seems to work nice as a anti-spam measure, since some spammers seems to hit the lowest priority MX first, and does not confirm enough to the standard to try another MX in the list. So I’m not going to configure my backup MX any time soon. It’s easier to deny relaying.
Any legitimate mail is likely to go through the senders SMTP server first, which will store the message, and retry for up to five days if it can’t reach any MX’ on the first try. So I don’t think there’s a real chance of loosing legitimate e-mail, if the sender is on a properly configured system.