Alternative smtp servers

[Kevin Darcy]

Joseph S D Yao wrote:

> On Wed, May 03, 2000 at 08:29:10AM +0000, James A Wilde wrote:
> > We are looking to build a little redundancy into the mail system by
> > providing alternative smtp servers for our users.  I have seen references in
> > these postings to alternative A records, as follows:
> >
> > smtp.dom.com.    IN    A    123.456.789.12
> >                  IN    A    123.456.789.13
> >
> > Is it really as simple as that, and will a machine set up with its smtp
> > server set to smtp.dom.com try a random choice from these two machines?
>
> No, it's not that simple.
>
> In the above scenario, the name will resolve into one or the other IP
> address [for most applications, including sendmail, I believe].  So an
> e-mail message will randomly go to one or the other.  If one is down,
> the e-mail will bounce, and whatever store-and-forward algorithm is in
> place locally [or dump-and-forget algorithm] will apply.

Actually, Joe, sendmail is smart enough to transparently fail over to the other
IP address -- at least this works for relatively-recent versions of sendmail. And
the order of the addresses isn't necessarily "random"; maybe the DNS response
just came from an authoritative server which arranged the RRset in "fixed" order.

But it's still better to use MX records, since not all mailers are as smart as
sendmail (no snickering, please; I've seen some really DUMB mailers in my time).

> If you're talking about for RECEIVING e-mail, then you should have
> machines with different names in "A" records, and MX records pointing
> to the two machines.
>
> smtp1.dom.com.    IN    A    123.456.789.12
> smtp2.dom.com.    IN    A    123.456.789.13
>
> dom.com.        IN  MX  10 smtp1.dom.com.
> dom.com.        IN  MX  20 smtp2.dom.com.
>
> If the mail server preference values are equal, then the same thing
> happens - e-mail goes randomly to one or the other.  But if one goes
> down, then 'sendmail' will try the other - as will any other MTA worth
> its salt.  If the preference values are unequal, as above, then the
> higher-preference [lowest-number] one will always get the e-mail,
> unless it's down.
>
> So, now you have a backup method to RECEIVE e-mail.  What about
> delivering it?
>
> Some people would try NFS-mounting a common mail directory.  This has
> two problems.  (1) if the NFS host is down, the directory still isn't
> available.  (2) on many systems, locking of NFS files doesn't work, or
> doesn't work well.  And locking is vital to e-mail.
>
> The solution that many use is to have the lower-preference mail host
> forward all local e-mail to the higher-preference one.  If the latter
> is down, the former will store it for as long as it has been told to.
> That means that e-mail at least has been received here on the premises.
> If you are going to be down longer than the storage period, you can
> convert the secondary mail receiver to be a mail distributor as well.
>
> You still need to decide whether or not to restore all of the e-mail
> that was received but not yet delivered, from the primary mail server.
>
> > And secondly, would the same thing work with CNAME records, as follows:
> >
> > smtp.dom.com.    IN    CNAME    smtp1.dom.com.
> >                  IN    CNAME    smtp2.dom.com.
>
> CNAMEs should never be used as targets of MX records.

Or, more to the point, a CNAME shouldn't have multiple targets.


- Kevin