[Gllug] Rejecting mail at backup MX

[Bruce Richardson]

On Tue, Feb 10, 2004 at 04:27:05PM +0000, Jason wrote:
> On Tue, 10 Feb 2004, Bruce Richardson wrote:
> 
> > > Yes this can happen but it's rare.
> > 
> > Either it's not that rare or my experience is extremely unusual.
> 
> One of the other. I provide backup MX for lots of domains and I've not 
> seen this much at all.

Where possible, differnet mail exchangers should be on different parts
of the network, so that if one is unroutable for any arbitrary part of
the internet, for whatever reasonm, the others are not.  Where companies
do this responsible thing, it is not uncommon for the case that the
primary is visibile to other mail exchangers for that domain but not to
remote mailers.  Problems with PMTU discovery are a common culproit.

> 
> > > Yes but it's more complicated than duplicating the maps
> > 
> > No, it isn't: it's less complicated.  No synchronisation process
> > required, one simple setting that says "ask ahead".
> 
> 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.

> 
> 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.

> > But you can also configure it to put the messages onto the retry queue,
> > which is going to happen anyway, if the end system is down, so I don't
> > see the problem.
> 
> 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?

> 
> > 	1.  Call forward.  If the end system is playing, accept anything
> > 	it accepts and reject anything it doesn't.  If the end system
> > 	isn't available, pass on to stage 2
> > 	2.  User maps.
> > 
> 
> 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.

> 
> 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?

-- 
Bruce

A problem shared brings the consolation that someone else is now
feeling as miserable as you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20040210/e58adc64/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug