Re: How to prevent being a 'bouncer' of evil mail?
On Fri, Jun 25, 2004 at 09:03:48PM -0300, Yves Junqueira wrote:
> On Fri, 25 Jun 2004 18:21:20 -0400, Kris Deugau <firstname.lastname@example.org> 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>
> 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?
I do that. A call forward to the next server in the chain to verify the
recipient before accepting the mail from the sender. I use Exim though.
It even caches the recipient verification results to avoid unnecesary
traffic. I don't know if it is that easy with postfix, but surely it is