"The Linux Gazette...making Linux just a little more fun!"

Secondary MX Records: How and Why

From Craig Capodilupo on Thu, 24 Dec 1998

Some domains have multiple MX records. Sometimes the MX record of lower preference, say 20, is an off-site domain. Does this off-site server have to be configured to hold mail until the primary exchanger is back online?

I am going to use my UNIX server as a secondary mail exchanger but I am not sure if it has to be configured.

In the good old days there was no special tricks to providing secondary MX for your friends. They would just add you mail server to their DNS records, listing you as a "less preferred" mail exchanger (an MX record with a higher value than any of yours). Mail would be relayed automatically.

This was in the days of "promiscuous mail relaying" --- it was easier to just let anyone relay mail though anyone else. However, just as venereal disease contributed to the demise of the "free love" promiscuity of the '60's --- the blight of spam as spelled the end of open e-mail relaying in our decade.

The problem was that spammers would dump their e-mail on any open relay --- one piece of mail that might be addressed to thousands of happless recipients (and with the return addresses forged on top of that).

When you install 'sendmail' version 8.9.x and later the open relay to which early versions defaulted are now closed. You'll have to create a relay map (default location in /etc/mail/relay-domains) to enable relaying for your sites).

There are some questions that relate to this in the 'sendmail' FAQ at:

http://www.sendmail.org/faq/section3.html#3.27

... although you could disable this feature and allow promiscuous relaying --- I'd not suggest this.

You'd eventually get hit by a spammer and then you'll probably end up on Paul Vixie's "Real-time blackhole list" (the RPL) or on "DorkSlayer's" ORBS (open relay blocking system). There are many sites these days that subscribe to these free DNS lookup services in their "check_relay" macros --- and deny any mail access whatsoever from any site listed on one or either of these.

However, that should be all there is to it. Normally your mail would just get tossed into the queue at your MX secondary's site where it will languish until your site is back up (or less busy, or whatever). In other words whatever connectivity problem the original sender's site had in getting to your primary MX host will probably go away within a few hours --- and your secondary MX will relay your mail during its normal queue runs. The orginal sender will get delay notifications (4 hours, 4 days, etc) according to the settings in your secondary's configuration files.

Some people use these features in their firewall configuration --- they place a higher MX host outside their main network (on the exposed network segment) --- and all outside mail has to hit it first (since they can never connect to the preferred hosts inside due to the packet filters). The packet filters then allow that exposed host (and only that exposed host) to transfer files into the domain. Thus the potential attacker can't attempt to directly exploit bugs in the internal SMTP daemon (especially if the "exposed" host is behind an anti-spoofing screen, and has "source routing" disabled, which all Linux systems default to).

A more elegant approach is to use "split DNS" --- so that the external/exposed MX host appears (to the outside world) to be the preferred mail destination while the real preferred system (to your internal systems, and to your exposed host itself) is sequestered on your internal network using non-routable "private net" addresses. The advantage to this is that your potential attackers don't have any information about your internal structure --- and they can't route packets to your internal hosts at all (those don't have "real" IP addresses). Thus the outside attacker has to resort to high wizardry to get packets to your hosts, before any exploits can even be attempted.

(I should note that any attacks that can be carried through the mail contents will still get delivered to you. The bugs this protects you from are those in the TCP connection handling of the daemons --- not in the parsing of headers and message contents).

I've heard of some sites that maintain separate queues for their relay neighbors. I don't know exactly how that works --- but its similar to the way that ISP's maintain queues for their SMTP customers. Basically they create a rule (probably an entry in their mailertable) that calls the relay mailer with an extra parameter. Thus all the queue items end up in special, separate directories. Then the SMTP ETRN command can be used (by customers) to force a queue delivery (something like: 'sendmail -q -O QueueDirectory=/var/spool/mqueue.customerX') when the customer's connection comes up.

Then there are sites that deliver all mail to a given site into a single mail spool (mbox) file. Hopefully they are adding the "X-envelope-To:" headers as they do this. Then their clients use 'fetchmail' to grab these messages, split them back out and dispatch them according to the delivery policies at the disconnected site.

Personally I still prefer UUCP for handling mail to disconnected sites. However, it is getting increasingly difficult for new users to find people who understand UUCP. (Oddly one study showed that the use of UUCP hasn't decreased at all -- it's grown at a slow, steady couple of percent all along. However, compared to the explosive growth of the Internet it as seemed, by comparison to completely disappeared. I think UUCP is still a very good option for emerging countries and for anyone that isn't maintaining dedicated connections to the Internet --- though I'd say that a bit of work should be done on simple configuration tools and examples. It's easy enough to use UUCP as a transport for DNS/Internet "domain" style addresses. So we don't need to ever return to the bad old days of "bang paths").

TIA,
Craig

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 36 January 1999

						a	b	c	1	2	3	4	5	6	7	9	10	11	12
						15	16	18	19	20	21	22	23	24	25	26	27	28
						29	31	32	33	34	35	36	37	38	39	40	41	42	44
45	46	47	48	49	50	51	52	53	54	55	56	57	60	61	62	63	64	65	66
67	69	72	76	77	78	79	80	81	82	84	85	86	87	91	94	95	96	97	98