[70555] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Barracuda Networks Spam Firewall

daemon@ATHENA.MIT.EDU (Per Gregers Bilse)
Tue May 18 20:20:24 2004

From: Per Gregers Bilse <bilse@networksignature.com>
Date: Wed, 19 May 2004 01:19:50 +0100
In-Reply-To: <40AAA435.8030403@ehsco.com>
To: "Eric A. Hall" <ehall@ehsco.com>
Cc: nanog@merit.edu
Errors-To: owner-nanog-outgoing@merit.edu


On May 18,  7:03pm, "Eric A. Hall" <ehall@ehsco.com> wrote:
> > For a long time since then, backup MXs have been seen as a kind of 
> > value-added courtesy service; they serve no really useful purpose
> 
> well, they're handy for centralizing filters against multiple domains, if
> you're willing to put your various primaries at the mercy of the filter
> service, and if the filter knows your valid recipients. what with
> ldap-smart servers and fancy routing, this isn't even hard anymore.

But this only means that the primary, and only, MX should be the
filter service MX; in turn, it would deliver sanitized email to
its real destination.

An amusing twist on this is then that the final recipients could
be listed as less preferred MXs -- if the filter service MX is down,
one would accept all mail unfiltered, rather than wait until the
primary, filter service, MX is back on line.

While this would be a legitimate use of less preferred MXs, even if it
practically turns the original rationale upside down, I would generally
suggest to opt for uncompromising reliablity on a filter service MX,
and fall back on DNS changes for disaster recovery, rather than receive
tons of junk unfiltered mail whenever there's a glitch on the primary,
filter server, MX.

But your point is technically correct.  Only goes to show how much
mileage there is to be had from an otherwise very simple protocol
extension.-)

Best,

  -- Per


home help back first fref pref prev next nref lref last post