Re: virus scanning
On Mon, Feb 16, 2004 at 03:01:41PM +1100, Russell Coker wrote:
> > > > 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
> > >
> > > Unless you're doing call-outs then rejecting at the DATA stage is OK.
> >
> > I am doing callouts, but they'd still be getting stuck in my queues even
> > if I wasn't. They'd be getting stuck with all the other stuff that callouts
> > avoid, though.
>
> If a 550 is sent then it should not be stuck in your queues, it should be
> bounced.
No, normal spam junk gets stuck with double bounces... the mail passes the
callout in the RCPT stage here, my server bounces the message on to a faked
address over there, and then their server responds with a bounce which gets
stuck in my queue as a double bounce. :/
> > > > > 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. :)
> > >
> > > No. Secondary MX's usually receive the mail, queue it, and then send it
> > > on if possible. They don't just open a TCP connection to the primary and
> > > pipe the data through unchanged.
> >
> > There's not much negative difference (a small delay, a small resource
> > usage), and the advantage of not bothering the primary MX is lost, so I
> > don't see much reason to prefer that.
>
> The negative difference is that it forces you to have the same
> configuration in terms of valid recipients and virus/spam filters for both
> the primary and secondary
Which is really not much of a problem. The only difference my MXs usually
have is the differently auto-trained Bayesian classifier in SA.
--
2. That which causes joy or happiness.
Reply to: