[H-GEN] I was sittin' and wondering'

[Robert Brockway]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On Mon, 4 Nov 2002, Greg Black wrote:

> | Fact!
> | One should have a backup MX server.
>
> This is another opinion.  It is much less widely held than the
> earlier opinion (and I don't share it).  One good reason for not

Hi all.  I have great respect for Greg's opinion, but I must say that I
generally prefer having at least one backup MX for a domain.  My personal
domain has 3 :)

It is important to offer some caveats here.  It is imperative that you
trust whoever administers your backup and I would always recommend no
backup MX in preference to one held only by people you do not trust.

Trust in this context has at least two connotation:

1.  You must trust that your backup MX is configured properly and will
    keep your mail safe when your primary MX[1] is down.  If it is
    misconfigured it might bounce your mail or just drop it.  Both of
    which are unsatisfactory.

2.  You must trust that the administrators of the backup MX won't peak
    at your mail or do anything else inappropriate with it.

It is for these reasons that I recommend that large organisations maintain
their own backup MX which is physically & network-wise seperate from the
primary.

> using a backup MX, especially if it's not one you fully control,
> is that you lose the ability to block spam -- block it at your
> primary and it gets delivered to your secondary which then
> delivers it to you.  Since you cannot correctly refuse to accept
> delivery from your secondary, you're hosed.

It does depend on how you approach the problem of Spam.  From this contaxt
& from previous things Greg has said, I believe he blocks port 25
connections from known spam hosts - perhaps by using the RBL or something
like that.  In this case a secondary would indeed end up relaying the
spam back to you (very annoying).

I use SpamAssassin.  I accept all mail and process it once it is on my
primary MX.  My backup MXs will hold all mail sent to my domain, spam or
not, and make no value judgement on this mail.  They send it to the
primary where it is evaluated.

Using this mechanism has the disadvantage that if you're volume charged
(which I am) you end up paying for the mail _before_ it is processed as
spam.  This is a little annoying but so far the costs to me have been
minimal.  I prefer this slightly greater cost overhead in order to avoid
losing any mail that might have been incorrectly tagged as spam.  Any mail
sent to me that is tagged as spam is sent to a spam folder which I review
weekly to look for false positives.

If you run without a backup MX you have to rely on the senders MTA[2]
(mail transport agent) to hold the mail until your primary is up.  The
administrator for that box may bounce mail back in a very short period of
time and you won't be able to do anything about it.  I abhorr unnecessary
mail bounces.

As can be seen, opinions differ on what is the correct way to approach the
problem, and in the end it really does depend on what you want to get out
of your mail system.

[1] Actually there is nothing wrong with having multiple primary MXs in a
peered arrangement.  Humbug itself used to do this, and may again one day.

[2] Or the MTA of their ISP if they relay mail through their ISP as some
do.  In this case you have the same potential trust problems as you do
with whoever controls your backup MXs.  If I'm considering sending an
unencrypted mail I don't send it unless I'm happy for the contents to turn
up on the front page of the Courier Mail.

Cheers,
	-Rob

-- Robert Brockway B.Sc. email: robert at timetraveller.org  ICQ: 104781119
   Linux counter project ID #16440 (http://counter.li.org)
   "The earth is but one country and mankind its citizens" -Baha'u'llah


--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/