374
edits
Changes
From SME Server
Jump to navigationJump to search→Internal Mail Servers
signal-event email-update
signal-event email-update
=== Secondary/Backup Mail Server Considerations ===
Many people misunderstand the issues of using a secondary or backup
mail server (backup MX) to hold your mail before it gets delivered
to your SME Server. If you consider putting a backup mail server in
place because you are concerned about lost mail because your internet
connection may occasionally drop out, think again and consider the issues
discussed below.
====What is ''Backup MX''====
A backup MX is a system whereby through your DNS records you tell other
servers on the internet that in order to deliver mail to your domain they
first need to try the primary MX record and if they fail to connect they
can try to connect to one or more of your listed backup or secondary mail
servers. See also http://en.wikipedia.org/wiki/MX_record
====The process of delivering email to your SME Server====
So lets look at how mail gets delivered with and without a
''backup mx'' when your Internet link, ISP or server is down.
====='''Without''' a backup MX:=====
* The sending mail server cannot connect your server.
* The sending mail server MUST queue the mail and try again later.
* The mail stays on the sender's server.
* The sender's server resends the mail at a later date.
''The requirement to re-queue is a fundamental part of the SMTP protocol -
it is not optional. So, if your server is '''offline''' due to a link or ISP
outage, '''the mail just stays at the sender's server until you are once
again reachable'''.''
====='''With''' a backup MX:=====
* The sending mail server cannot contact your server
* The sending mail server sends the mail to your secondary MX
* The secondary MX queues the mail until your link/server is up
* The mail is queued on an '''untrusted''' third-party mail server (''think about confidential mail between your company and some business partner'')
* The sending mail server's administrator ''thinks'' it has been delivered, according to their logs
* You have no, or little, visibility over the queued mail
* When your link comes up, the secondary MX sends the mail on to your server
* You have added more hops, more systems and more delay to the process
If you think that a backup MX will protect against broken mail servers
which don't re-queue, you can't. Those servers will drop mail on the floor
at random times, for example when ''their'' Internet link is down.
Those servers are also highly likely to never try your backup MX.
Thankfully those servers are mostly gone from the Internet, but adding a
secondary MX doesn't really improve the chances that they won't drop mail
destined for your server on the floor.
====Backup MX and SPAM Filtering====
On top of the issue, indicated above, there is another issue to consider
and that is what happens with SPAM due to the use of a ''Backup MX''.
Your SME Server takes care of filtering a lot of SPAM by checking on the full
username & domain at the time it is received.
For example if your server hosts '''example.com''' and someone sends
mail to '''joeuser@example.com''', the server will '''only''' accept the mail
if joeuser is a local user/alias/group/pseudonym on the server.
Otherwise, the mail is rejected during the SMTP transaction.
A backup mail server however, generally does not have a full list of
users against which it can check if it should accept the mail for the given
domain. Hence it will accept mail for ''invalid'' users.
So:
* If you trust the secondary MX, you _will_ accept a lot of SPAM when the link comes up.
* If you don't trust it, you will cause a lot of SPAM backscatter as the mail has been accepted at the secondary MX and then later bounced by you.
* Stopping backscatter is why SME Server rejects invalid addresses during the initial SMTP transaction.
The SPAM backscatter can only be stopped if the secondary MX has a full list
of users for your domain to allow filtering to occur.
But:
* You need to be able to configure this secondary MX with such user/domain lists
* You need to maintain these secondary configurations when users are added/deleted from your primary server configuration
* You need to test (regularly) if the secondary is successfully accepting/rejecting mail as required.
Quite a few sites have lost lots of mail through misconfigured backup MX servers. Unfortunately, the time when you find
out they are misconfigured is when you go to use them, and then you find that the backup MX has changed configuration and bounced all of your mail.
Then you realise that this mail could have queued at the sender's site if there hadn't been a broken secondary MX bouncing the mail for you.
* If you bounce mail at your server, you have logs to show what's wrong.
* If your secondary MX bounces your mail, you usually have no way to determine what happened other than via reports from the original senders that your mail bounced.
==== Summary ====
In summary, if your server/Internet connection is available most (let's say >90%) of
the time, you are generally better off <u>without a secondary MX</u>.
If your server/link is down more than this (e.g. dialup), you should not be delivering mail
directly to your server.
If you still want to consider setting up a seconday MX, ensure that:
* you have fully control of the configuration of each of the email gateways for your domain
* each gateway can make decisions on whether to accept/reject mail for the users at the domain
<noinclude>[[Category:Howto]]</noinclude>
<noinclude>[[Category:Howto]]</noinclude>
