Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Feb 2005 11:47:43 -0500
From:      Craig Green <freebsd@craigg.org>
To:        Noah Davidson <NoahD@oopz.com>
Cc:        freebsd-isp@freebsd.org
Subject:   Re: Sendmail question
Message-ID:  <4210D62E.5020708@craigg.org>
In-Reply-To: <1BC9C5447DEF1F4FBE3927A31D6B540404DC09@gehrig.hall.oopz.com>
References:  <1BC9C5447DEF1F4FBE3927A31D6B540404DC09@gehrig.hall.oopz.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Noah Davidson wrote:

>This is a backup mail server.  The primary mail server is an Exchange 2003 server.  So when mail is sent to invaliduser@bdomain.com then this server sends the mail to the exchange server that is responsible for handling the mail for domain.com.  Since the user does not exist it bounces the mail.  
>

The usual way of preventing bouncing is to have a list of valid users on 
the secondary MX as well as the primary.  That way the secondary MX can 
reject mail for bad recipients, rather than being forced to accept 
everything, attempt a relay and bounce email for the bad rcpts. 

Naturally, there are a lot of instances where this is not possible. :-/

To work around this problem, what we did was use a 'call-ahead' milter, 
specifically Snert's milter-ahead.  See http://www.milter.info/.  It's 
not in Ports, but it compiles easily enough from tarball and the author 
even includes a FreeBSD compatible startup script.  If you're leery 
about using programs not in Ports, MIMEDefang is in Ports and while it 
does not do this by default, if you know Perl coding a call-ahead 
function for it would be easy enough to do.

What the milter does is after getting a 'RCTP TO' command from the 
foreign SMTP server, it checks to see if a route exists for the 
recipient domain in the mailertable (i.e. if the mail server is acting 
as a gateway or relay for the recipient domain).  If a route does exist, 
it initiates an SMTP connection to the indicated destination server and 
sends a HELO / MAIL FROM: <> / RCPT TO: sequence, with the RCPT TO being 
what the milter received from the foreign server.  If the milter gets 
back a 'recipient okay' from the server in the mailertable, then it 
tells the foreign server 'recipient okay'.  If the recipient is 
rejected, then the milter also rejects the recipient. 

In essence, it forwards on the response from the server in the 
mailertable to the foreign server--hence 'call ahead'.

Milter-ahead includes a cache (with a configurable timeout) of 
previously-checked recipients so it doesn't have to query the server in 
the mailertable every time.  Its behaviour when it can't reach the 
server in the mailertable is configurable; you can either have it give a 
4XX temporary error, or just accept the message.  The latter is most 
appropriate for backup MXs and is what we use.

Instead of bouncing a couple hundred thousand emails a day, we now 
reject them immediately at the border.  This saves us from annoying a 
lot of people, generating double-bounces when the envelope sender is 
faked, cuts down on our bandwidth usage (since we reject after the RCPT 
TO, the email body is never sent), and saves our spam and virus scanning 
resources.  It does increase the number of SMTP connects to the 
destination server, but from a bandwidth point of view, you can check a 
lot of email addresses in the bandwidth saved by rejecting a couple of 
viral emails instead of forwarding them on and having them bounce.  All 
in all, it's a clear win for us.

The only downside is that a reject response may be cached for an email 
address that later is activated and becomes valid. As you might guess 
this happens vanishingly rarely, but it has happened once or twice.  
Keeping the cache time to a day or two mitigates this (it defaults to 
one week(!)); with a one day cache, newly invalidated data will be held 
for an average of only 12 hours.  If we do get a report, we simply flush 
the cache and all's well.

Regards,

Craig.
------

>Then the root alias gets a copy of the bounced mail.  Is there any way to prevent this from happening?  This server should just queue the mail for the exchange server until the exchange server is available.
> 
>Thanks
>Noah Davidson
>
>_
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4210D62E.5020708>