D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] email

 

Mick Vaites wrote:
>  
> Yup but an ISP can never be authoritive of a customers mailboxes if the
> mailboxes are located on the customers mail server.

It doesn't matter if it is an ISP or within a company, provision of a
secondary MX has the same technical issues, sure there may be other
non-technical issues.

There are two common approaches to providing a secondary MX these days
that address this.

One is two duplicate the list of valid addresses by some out of band
arrangement.

The second is to proxy the valid addresses, so a cache is built up when
the primary mail server is available, and when it is unavailable you
store email for addresses known to be valid, and defer email to others.
Or to proxy, and only accept unknown addresses when the primary mail
server really is down (milter-ahead did this). However this later
approach is less useful if the primary is down/inaccessible due to a
huge spam run or related problem.

Simply acting as a relaying MX where all mail to a domain is queued is
so counter productive, most people do better to simply disable such a
service.

The issue is that a useful secondary MX must implement similar spam
control. If you greylist, the secondary MX must also greylist (ideally
from the same database). If you use a blocklist the secondary MX needs
to use the same blocklist, otherwise much of the blocked email is still
delivered via the secondary.

Because of the large amount of spam typically attempting delivery from
secondary MXes that relay, you also have to specially configure the
primary not to drop the spam filled connection from the secondary. This
is especially true if the secondary doesn't validate email addresses.
Been there seen the genuine email in the secondary mx queue take longer
to deliver than if the secondary MX wasn't present, because the queue on
the secondary is stuffed full of email that is to non-existent addresses
causing the primary to repeatedly drop the connection.

Sure with very effective spam filtering on a backup MX you can just
about skip the recipient check for small domains, but you wouldn't want
to make it a systematic part of being a secondary MX.

-- 
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html