[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: virus scanning



On Sun, Feb 15, 2004 at 05:08:40PM +1100, Russell Coker 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.

That's a fair point, but that doesn't mean that we have to classify d-a
among the stupid majority; instead we can help them fix the problem.

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

Hey, I know all about it. Even when people don't do it entirely wrongly,
they can still screw up. Various yahoo.tld mail servers don't reject invalid
recipients at RCPT stage but at DATA. (I highly doubt that they actually
take the spam data and analyze it, but it must be more fun to get all that
extra traffic, and screw up people's Exim callouts at the same time.)

> Also some spammers seem to prefer MX secondaries because they tend to have
> less spam protection.

Which is exactly the reason why having a properly set up last MX is a good
idea -- it saves work in rejecting a lot of the spam for the primary (and
possibly others).

> I've considered setting up a MX secondary that tarpits all connections to
> deal with such spammers...

A great way to break an RFC that's older than I am...

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

Which should be another violation of the aforementioned RFC.

(Yes, I know that there's a bug in some versions of Postfix that causes it
to not use !first MXs with certain error responses.)

> Most mail servers won't immediately try the MX secondary if the primary is
> available, there will be some delay.

I don't know why you say _most_, but even if it's true, that's still
better than having it kept at their end and subject to their expiry rules.

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

Yes (connect; MAIL FROM:<>; RCPT TO:<$recipient>; QUIT).

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

Ahm. That's basically what a secondary MX usually does, you know. :)

-- 
     2. That which causes joy or happiness.



Reply to: