Last-priority MX and spam

[beq]

Are there any unforeseen issues to specifying the same MX server more than once (with different priorities) in a domain's DNS?

As a hypothetical, say you use a secondary MX server for backup redundancy, but it's not well protected. And you want to do something about spam that purposely target the last-priority MX server (based on exactly that assumption). Should you specify your primary MX server (which is better protected) again, but this time as the tertiary MX server?

I suppose you could also specify a last-priority MX server that doesn't actually accept for that domain (or any domain) -- either by rejecting everything at connect (5xx or just 4xx tempfail), or as a "blackhole" spam sink. That is, assuming you already have other intermediate-priority MX servers for the real backup redundancy. Incidentally are there any such mail servers around that we can use?

How about specifying an invalid or non-existant last-priority MX server name? I'm thinking spam software wouldn't be smart enough to retry from a failed lookup (whereas normal MTAs should never even try the last MX as presumably you would already have ample backup servers ahead of it).

Then again I'm not sure how such spam work these days, whether they always target the last MX server, or the one immediately following the primary, or randomly. Been wondering about this stuff for awhile...

[beq]

I was hoping to get input on how others prefer to set up their MX records to handle spam that target non-primary MX...

I haven't seen much discussion of this topic here, but it's supposed to be a well-known spam exploit (since many use backup MX servers that aren't well protected)?

[xbot]

Originally posted by beq
Are there any unforeseen issues to specifying the same MX server more than once (with different priorities) in a domain's DNS?

As a hypothetical, say you use a secondary MX server for backup redundancy, but it's not well protected. And you want to do something about spam that purposely target the last-priority MX server (based on exactly that assumption). Should you specify your primary MX server (which is better protected) again, but this time as the tertiary MX server?

I suppose you could also specify a last-priority MX server that doesn't actually accept for that domain (or any domain) -- either by rejecting everything at connect (5xx or just 4xx tempfail), or as a "blackhole" spam sink. That is, assuming you already have other intermediate-priority MX servers for the real backup redundancy. Incidentally are there any such mail servers around that we can use?

How about specifying an invalid or non-existant last-priority MX server name? I'm thinking spam software wouldn't be smart enough to retry from a failed lookup (whereas normal MTAs should never even try the last MX as presumably you would already have ample backup servers ahead of it).

Then again I'm not sure how such spam work these days, whether they always target the last MX server, or the one immediately following the primary, or randomly. Been wondering about this stuff for awhile...

I read your first sentence, and skimmed through your others.

Yes--you can use the same domain/ip twice (or more) for the same MX records. In fact, that's the whole idea of MX--prioritize. It's not just so you can retrieve mail--in fact, I've been in situations where mail worked without an MX record.

[beq]

Originally posted by xbot
Yes--you can use the same domain/ip twice (or more) for the same MX records. In fact, that's the whole idea of MX--prioritize. It's not just so you can retrieve mail--in fact, I've been in situations where mail worked without an MX record.

Hmm, pardon I don't quite catch the gist of your meaning?

OT1: In regard to your last sentence, were you referring to a domain which is CNAME aliased to another domain?

OT2: Anyways, I forgot to mention that while it's not related to the spam topic of this thread, FastMail's legacy MX settings also end up being duplicative (in that both smtp.us and smtp.us2 hostnames resolve to the same set of IPs, and are rolled into one hostname in the new MX settings).

[DrStrabismus]

An A record may be used when there are no MX records nor a Cname.

[beq]

Originally posted by DrStrabismus
An A record may be used when there are no MX records nor a Cname.

Thanks, I forgot about that.

So DrS just wondering, do you have an opinion on secondary-MX configuration tactics to combat this type of specialized (but supposedly common) spam?

[stevew]

That is, assuming you already have other intermediate-priority MX servers for the real backup redundancy. Incidentally are there any such mail servers around that we can use?

Rollernet seems to provide a good backup mx service.

[beq]

Originally posted by stevew
Rollernet seems to provide a good backup mx service.

Thanks for the info. I should've clarified my question though, I was actually looking for a specialized MX server whose sole function is to 4xx/5xx reject everything that it receives. I guess I could just specify any 3rd-party MX server which does not host my domains, but that would be bad behavior without asking their permission first?

Same goes for a "blackhole" MX server that drops everything it receives, I suppose I could just specify the server belonging to some of those DEA services...

[stevew]

To be honest, I think this would cause you a world of pain.

Any email service routing email by least cost route rather than your published preferences MIGHT use the 'blackhole' MX.
(this assumes the 'blackhole' is not on your subnet)

Also the way the internet works means all points are not connected at all times - from time to time only your 'blackhole' MX will be reachable by some.
(this will be less of a problem with more MXs spread over a number of networks, but you will still lose legitimate email)

Misconfigured / broken hosts may also be a problem, or they may not.


If this is a home test system it might be ok if you don't mind loosing email now & again.
I'd hate to explain to an employer or important customer who complains "I've lost some important emails" all of the above.
I would make getting email sound a little like a lottery.

[beq]

Originally posted by stevew
To be honest, I think this would cause you a world of pain.

Any email service routing email by least cost route rather than your published preferences MIGHT use the 'blackhole' MX.
(this assumes the 'blackhole' is not on your subnet)

Also the way the internet works means all points are not connected at all times - from time to time only your 'blackhole' MX will be reachable by some.
(this will be less of a problem with more MXs spread over a number of networks, but you will still lose legitimate email)

Misconfigured / broken hosts may also be a problem, or they may not.

Whoops I'd missed your reply first time around, sorry!

Hmm, those are very interesting points you raised... much appreciated thanks Steve.

I'd just been pondering simplistic schemes like this since it was pointed out to me in the past that a 3rd-party store-and-forward backup MX service we'd used at one point turned out to be a spam magnet, where its daily function became mostly a backdoor to queue spam to our main server.

Anyways some interesting facets of this topic had been explained by Tuffmail.

And FastMail had long ago told me that they'd also discussed the idea of high-preference MX spam sink, and also that their off-site backup MX originally used to 4xx everything (after first checking that the primary servers are up, I think). But since then the backup's become more a full fledged mail server with its own userlist, IP blocklists, monitoring heuristics, etc. They'd also pointed me to more advanced ideas such as the MX honeypot.

As another example, MarxMail (which I never used) mentions a similar strategy:

1. A lot of spammers target the highest MX record instead of sending to the lowest one like they are supposed to. They figure that the "backup" mx server probably has the least amount of spam protection. That may be true of other servers but not on mine. These spammers usually go for the highest MX and never retry the lower ones. So - my simple solution is that on my highest MX record I have a dummy server that returns a temporary error on EVERYTHING that connects to it. The temporary error tells the server there's a problem and come back later and try again. Spammers rarely do. This server is actually on the same computer as my lowest MX record so it is never really up when the main one isn't and in theory should never get a legitimate email. But - in case it should the temporary error will allow it to retry the correct server and deliver the email a little later without ever losing a real message. Of the spam this rejects - it's 100% accurate.

[Redpin]

An option to look into is the greylisting pseudostandard... I believe this would accomplish what you want, in that a "secondary" MX with no whitelist would then initially defer all incoming connections at the SMTP level... real servers would go on to try another server, or eventually retry that one, at which point the message would be accepted, but many spammers would just move on to the next message and discard that delivery.

[beq]

OLD THREAD BUMP

I thought I should carry over the discussions from unrelated FM thread to here:

Originally posted by beq
...there's a high number of spam that specifically target backup-priority MX servers even when the primary MX server is up, on the rationale that backup MX servers (many are simple store-and-forward backup spoolers) tend to have reduced or no spam filtering [see P.S. below].
...

[P.S.] As I understand it, the worst thing would be if you use a store-and-forward backup MX server that has no anti-spam, but mail delivered from this backup server is always accepted (whitelisted) by the primary MX server. So spam that specifically target the backup MX server would get a free ride into your Inbox.

In regards to a backup queueing MX server that has no userlist nor adequate antispam (and which stores and forwards to the main mail server), I guess it's not just an issue of whether the primary server accepts all mail from the backup.

The spam filtering on the primary server still would no longer be able to check on various aspects of those emails that were sent to the backup MX, such as the HELO/EHLO hostname and IP address of the sending mail server.

And without special handling in this case, could SMTP rejections by the primary server create similar backscatter concerns as with external forwarding scenarios?

[hadaso]

Originally posted by beq
Same goes for a "blackhole" MX server that drops everything it receives, I suppose I could just specify the server belonging to some of those DEA services...

So why not 127.0.0.1 ? (would they spam themselves then?)