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

Re: How to prevent being a 'bouncer' of evil mail?

Yves Junqueira wrote:
> On Fri, 25 Jun 2004 18:21:20 -0400, Kris Deugau <kdeugau@vianet.ca>
> wrote:
> > I've been lucky enough to only work with *nix mail servers except
> > for that one Novell system- and it had some advantages I've yet to
> > see in any *nix system.  <g>

> Interesting. Was that Novell server old? In what architecture did it
> run on?

x86 Novell Netware 4.11, supporting Novell's "Internet Messaging System"
mail package.  It had some truly *peculiar* behaviour in some respects,
and some horrible bugs with respect to some DNS-related operations, but
it integrated *very* nicely with the Netware administration system and
was ideal for a small ISP.

> Exchange 2003, the final server in the case I said, is ok. It is not
> that stupid. The problem is with Norton for Gateways. In our current
> setting, it gets the message before Exchange does, and it is very
> dumb.

Ah.  You'd think that a tool designed to integrate in some way with
Exchange would be able to hook in to things like a recipient check.

> We will be removing NAV in the future, when we are more
> confident on Clamav (it still misses some old MS Word "Macro
> viruses").

I can't say I've seen much trouble with Clam, and the most recent
release (0.73) has fixed the problems I've had.

> But, hmmm..., even we didn't have NAV, it wouldn't help much. Let's
> say Postfix (the gateway) delivers the message to Exchange, which is
> "smart". Even so, AFAIR, we would have another e-mail created
> notifying the failure, instead of a so desired SMTP error code. After
> Postfix gets the message, it sends a success reply to the client, and
> just then tries to send the mail to the destination, that will give
> postfix a failure reply code. Postfix will then have to send a DSN,
> right?

As a fresh new message, yes.  At least, that's what happens by default
on any MTA I've ever met, in such a setup.

> Or could you issue the RCPT TO command to the other server
> BEFORE sending the final result to the client, in the front server?

Hmm.  I know sendmail doesn't support anything like this out of the
box;  but I don't know for sure about any other MTAs.  I've used a very
nice milter for sendmail (MIMEDefang) to do exactly this- check a
recipient against the next server in the chain when the remote "client"
server attempts RCPT TO:- and it worked very well.

> The world would be so much easier if Debian ruled from the
> beginning...

*shrug*  I've had some problems using Debian for email handling;  I've
ended up having to build custom .deb's for a number of Perl modules, and
use packages from backports.org to get the functionality I wanted. It
didn't help that in one case I was converting from a RedHat system in
production use.  :/

On the other hand, apt-get is *very* nice...

"Sendmail administration is not black magic.  There are legitimate
technical reasons why it requires the sacrificing of a live chicken."
   - Unknown

Reply to: