[Gllug] Rejecting mail at backup MX

[Jason Clifford]

On Tue, 10 Feb 2004, Bruce Richardson wrote:

> > For every message you have to "ask ahead" and you have to consider what to 
> > do when that fails, 
> 
> Yes
> 
> > etc which introduces complexity.
> 
> No, because the options to consider are simple.

It's inherently more complex than simply accepting all email for the 
domain and forwarding it as appropriate.

> > 
> > Duplicating maps is trivially easy in my experience.
> 
> Duplication and synhronisation are by definition more complex and
> automatically introduce possibilities for errors that do not exist with
> call forward.

I disagree. Duplication and synchronisation can be as simple as 
configuring mysql to replicate to the secondary (which works very well 
indeed) or using rsync in a cron job.

> > Again - *precisely what the OP was seeking to avoid*. Retrying and dealing 
> > with the attendant bounces which all fail is a large part of the problem 
> > with backup MX abuse.
> 
> Come again?  If his primary is down, then his secondary will have to put
> incoming messages onto the retry queue.  All that changes with call
> forward is that this happens at a slightly earlier stage.  Am I missing
> something or are you?

You are. The OP doesn't want to accept the message in the first place if 
it's not for a valid local user. Relying upon call forward mechanisms will 
acheive this only while the primary is visible to the secondary. Once it 
is no longer available the messages are accepted and the whole point 
fails.

> > I wouldn't bother with your step 1 as user maps makes it redundant.
> 
> Either one could be said to make the other redundant but one is less
> flexible and inherently more error-prone.

And it's your one in my view. I suspect you and I shall agree to disagree 
on this.

> > Also with maps in an SQL database which is replicated to the secondary
> 
> Excuse me, but I'm tryhing to stop laughing.  Synchronising SQL
> databases?  Less complex?  Have you considered a career in stand-up?

I'm suggesting replication not synchronisation.

MySQL (and others) suppport replication and it is trivially easy to set it 
up and maintain it - I know as I use it a lot.

It works well and it's reliable. I've been using it in anger for almost 2 
years without any significant problems. On the one occassion the system 
failed (due to a disk failure) I was able to get the database back in sync 
in less than 5 minutes.

I think the market for ugly, fat stand-ups is already saturated so I'll 
leave that for others.

Jason Clifford
-- 
UKFSN.ORG		Finance Free Software while you surf the 'net
http://www.ukfsn.org/	   ADSL Broadband from just £23.75 / month 

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug