Hi Where we have multiple internet connections, we setup MX records for both connections. If one connection is down, email flows through the other one.
hc Howard Cunningham, MCP Microsoft Small Business Specialist Macro Systems, LLC 3867 Plaza Drive Fairfax, VA 22030 www.macrollc.com 703-359-9211 howa...@macrollc.com - personal For technical support, send an email to serv...@macrollc.com or call 703-359-9211 (24/7) -----Original Message----- From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Chris via mailop Sent: Thursday, December 17, 2020 5:07 PM To: mailop@mailop.org Subject: [EXTERNAL] Re: [mailop] What's the point of secondary MX servers? Caution brain bending ahead: Secondary MXes have a role as your main mail server. Long experience with spambotnets reveals that most of them are pretty stupid, because their MX capabilities are limited. In fact, many spambots infections don't do any DNS lookups at all, and rely on pre-recorded resolutions done centrally, of JUST the primaries, and in some cases long after the resolution has gone stale. In particular, the spambot responsible for most bitcoin extortion and Russian pseudo-Canadian Rx is a good example of something that caches resolutions for as much as a year or more. Some of my most effective spamtraps don't have anything MXed at them anymore. I've had one trap move from one set of IPs to another. The old MXes actually generate more infected IPs than the new ones do EVEN WITHOUT treating anything hitting the old MXes as infected by definition. [My bot detection rules on the new IPs is around 60% of total traffic. Damn spot on 100% on the old ones.] A few other spambots think they're smarter than you, and will deliberately spam the worst priority MX thinking that these will be the servers that have the weakest filtering. If you have a few IPs to burn, and an existing mail server, this is what I recommend: 1) Set up a secondary MX pointing at your real mail server with full spamfiltering. 2) Set the primary MX pointing at a stub that does nothing more than do a reject on HELO/EHLO. 3) Set a tertiary MX pointing at an IP that doesn't actually have anything listening. Many spambots will hit the primary, get a failure, and simply give up. Real servers will hit the primary, then try the secondaries. A few spambots will hit the tertiary and waste their time waiting for something that won't happen. Note: both the primary-MX reject, lower priority MX hang proposals did make the rounds, separately, many years ago on, say, Usenet discussion forums. I can personally assure you that they really do work, but your precise mileage may vary. On 2020-12-17 16:21, John Levine via mailop wrote: > As we all know, MX records have a priority number, and mail senders > are supposed to try the highest priority/lowest number servers first, > then fall back to the lower priority. > > I understand why secondary MX made sense in the 1980s, when the net > was flakier, there was a lot of dialup, and there were hosts that only > connected for a few hours or even a few minutes a day. > > But now, in 2020, is there a point to secondary servers? Mail servers > are online all the time, and if they fail for a few minutes or hours, > the client servers will queue and retry when they come back. > > Secondary servers are a famous source of spam leaks, since they > generally don't know the set of valid mailboxes and often don't keep > their filtering in sync? What purpose do they serve now? > > R's, > John > > PS: I understand the point of multiple MX with the same priority for > load balancing. The question is what's the point of a high priorty > server that's always up, and a lower priority server that's, I dunno, > probably always up, too. > > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
