Re: virus scanning
On Sun, 15 Feb 2004 04:38, Josip Rodin <joy@srce.hr> wrote:
> > This is easy to fix, just remove the MX record that points to gluck! MX
> > secondaries don't provide any benefit with the way the Internet works
> > today. They just cause needless bounces and administration problems.
>
> No, they don't, when they're set up properly.
Setting up a secondary MX properly has been demonstrated to be beyond the
ability of 99.99% of all administrators.
AOL's front-end SMTP servers will receive mail for non-existant accounts and
then send bounces out in response to spam and virus messages. Even AOL's
admins and the administrators of mose (all?) other major ISPs can't get this
right.
Also some spammers seem to prefer MX secondaries because they tend to have
less spam protection. I've considered setting up a MX secondary that tarpits
all connections to deal with such spammers...
> I prefer that when the
> primary mail server is down that incoming mail is stored on the secondary
> so that I know how much there is, to be able to view some of it if it's
> urgent, and to flush it as I like when the primary goes back online.
You still don't know how much there is. Not all mail servers will send mail
to a MX secondary. Most mail servers won't immediately try the MX secondary
if the primary is available, there will be some delay.
> The problem that Santiago descries can be fixed with callouts (callbacks as
> exim3 likes to put it), but debian-admin is wary of enabling it in general.
What are "call-outs"? Is this when the secondary MX connects to the primary
to verify the address? If so why not just have a SMTP proxy on the MX
secondary which passes all data through to the primary if it's available, and
sends it locally for queuing otherwise?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: