Re: How to prevent being a 'bouncer' of evil mail?
On Fri, 25 Jun 2004 18:21:20 -0400, Kris Deugau <email@example.com> wrote:
> Yep. I've never set up exactly such a system, but for a while I had a
> Linux box acting as a gateway for a Novell IMS machine that had some
> related stupidity (DNS resolution speed issues, IIRC). I was able to
> just open a connection to the Novell box and issue RCPT TO: for each
> recipient, because it wasn't *quite* so stupid as to accept mail for
> nonexistent users.
> 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?
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. We will be removing NAV in the future, when we are more
confident on Clamav (it still misses some old MS Word "Macro
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? Or could you issue the RCPT TO command to the other server
BEFORE sending the final result to the client, in the front server?
The world would be so much easier if Debian ruled from the beginning...