[Gllug] Rejecting mail at backup MX

[Jason Clifford]

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.

> > 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, etc which introduces complexity.

Duplicating maps is trivially easy in my experience.

> > and may introduce excessive latency in a connection.
> 
> Not if you are only using it for internal systems (as you should) and
> those systems are themselves properly configured.

For internal systems the introduced latency will not be very great however 
backup MX is very often a remote facility - indeed where it is a local 
facility on the same network as the primary the likelihood that it will 
ever be needed with the primary is available and the message is not 
abusive is very remote indeed.

> > Which is precisely what the OP was seeking to avoid.
> 
> 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.

> 	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.
> 
> But I wouldn't bother, seeing that I can do it without the user maps
> and more simply.  Call forward is also much better if a box will be
> passing mail on to more than one system (either because it is a gateway
> box or because it is a relay for more than one domain).  It's much
> simpler in that scenario and also allows you to set policy on the end
> system, by configuring the end system either to reject invalid
> recipients at the smtp level or to accept them and then generate NDRs.

I wouldn't bother with your step 1 as user maps makes it redundant.

Also with maps in an SQL database which is replicated to the secondary I 
only need to update the primary for the secondary to get a completely 
independant copy almost immediately if the connection between them is up 
(and if it's not up the update will happen as soon as it is).

As for multple final destination servers or domains why should that be a 
complication? I handle a great many domains for backup MX and many of them 
go to remote primaries. If I implement backup MX protection that wouldn't 
be a problem as it would only be for those who want it anyway and they 
will co-operate to make maps possible.

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