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...
-kgd
--
"Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken."
- Unknown
Reply to: