good show

[Jay R. Ashworth]

On Wed, Jul 28, 2004 at 07:08:00PM -0400, John Esak wrote:
> > Which is an excellent reason for always having at least two
> > MX records in your DNS.
> >
> > When the main server is down the secondary holds them until
> > it comes back up and then delivers them.
> 
> Bill,
> Can you explain this to me further?  We have had _serious_ problems with my
> favorite "Rapidsite/Verio". All mail going to nexusplastics.com and a lot
> going to valar.com is being delayed for this reason. They say their systems
> are overloaded and they are putting in a fix within the next 4-6 weeks that
> will fix the problem. Meanwhile, it has been 4 to 6 weeks already and we
> actually have large (like million dollar clients) telling us that if we
> can't be more responsive to our email they will start looking elsewhere!!
> How can we be responsive to email that comes 6 to 8 to 12 hours after it has
> been sent, or worse not at all. I have been in nearly constant communication
> with lots of the tech support people at Rapidsite, but they are pretty much
> giving me the same patent answers that don't say anything. They want me to
> switch our problem accounts (which I would guess be all of them) to
> something called ViaVerio... some other product they must offer. Why would I
> move to another product from a company that is now providing me a product
> with failing service. It's not very trust insipiring. We are now nearly at a
> litigation point... Should I just switch to Level 3 as you have suggested in
> the past, or is there something that can be done with secondary MX records?
> Whay wouldn't they tell me about such an option?
> 
> What are your suggestions?

"Secondary MX" is the common name for a combination of techniques
intended to reduce mail delivery failures.

To have this really be reliable, you need (at least) two things, in
each of two categories:

You need for the master DNS zone for your domain to be served from at
least 2 machines, and preferably 3 or 4, *on different backbones and
uplink providers*.  This way, mail will never bounce with "can't
resolve domain", which is a soft bounce (the sending SMTP server will
usually retry for up to 5 days).

You need at least one extra machine to actually *receive mail* for your
domain.  These machines must have public, static IP addresses, and
properly administered mail SMTP mail systems.  You configure then in
your DNS zone as additional MX records, with higher numbers in their MX
records (and therefore lower priority).

If a sending system tries to get mail to you, and for some reason
cannot contact your primary MX server, it will try your secondaries in
descending priority (ascending numerical) order.  Hopefully, *one* of
them will be accessible.  As usual, the optimal situation is to have
your secondaries in phsyically separate locations, on different
backbones, just like your DNS servers.

These secondary servers are configured to accept the mail for your
domain, but not try local delivery -- they then attempt the delivery to
your primary server themselves, for however long your secondaries are
configured to try -- which, hopefully, you're in control of.

Worst case, if your machine is running but your link has suffered
backhoe fade, you might be able to sneakernet the mail spool from a
secondary to the primary for delivery.

The highest bandwidth data transport known to mankind is a FedEx plane
full of DVD-ROM's.  (This used to be a station wagon fill of magtape,
when someone at Duke coined it about Usenet; I've clearly updated.)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"You know: I'm a fan of photosynthesis as much as the next guy,
	but if God merely wanted us to smell the flowers, he wouldn't 
	have invented a 3GHz microprocessor and a 3D graphics board."
					-- Luke Girardi