[Gllug] Rejecting mail at backup MX

[Bruce Richardson]

On Tue, Feb 10, 2004 at 02:15:37PM +0000, Jason wrote:
> On Tue, 10 Feb 2004, Bruce Richardson wrote:
> 
> > No, that isn't the purpose of a backup MX.  It's one of the functions
> > but not the only one.  It is entirely possible for there to be a
> > situation where arbitrary e-mail box A cannot connect to B's primary but
> > can route to B's secondary even though B's primary is up and running and
> > perfectly visible to the secondary.  I see this happen every day.
> 
> Yes this can happen but it's rare.

Either it's not that rare or my experience is extremely unusual.

> 
> > Furthermore, spammers and viruses often deliberately target secondaries,
> > trying to bypass the defensive features on the primary.  The
> > call-forward feature prevents them from succeeding.
> 
> 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".

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

> 
> > Secondly, I clearly stated that it can be configured to allow the
> > messages through when the end system is not available.
> 
> 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.
> 
> There isn't a single "right" answer to this issue. The call forward 
> mechanism you are using is one good way or dealing with some of the issues 
> arising from backup MX abuse. I don't think it's necessarily the right one 
> for the OP though.

They could be used in combination.  Sequence events for incoming
message:

	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.

-- 
Bruce

I object to intellect without discipline.  I object to power without
constructive purpose. -- Spock
-------------- 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/b7ae6464/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug