Re: smtpserver consulting router

[Andy Poling <andy@globalauctions.com>]

On Mon, 23 Feb 1998 mea@nic.funet.fi wrote:
> > 	I think it used to be that smtpserver used to consult
> > router process to verify RCPT, VRFY, MAIL et cetera parameters?
> > It would be a better substitute for current anti-spam facilities
> > in smtpserver, I wonder if it still works and how bad it impacts
> > machine load?
> > 							alexis
> 
> 	Yes, you can have it, but the primary reason I never
> 	supported it is that to do it you need to run full-
> 	blown router process under the smtpserver, and while
> 	it might work for you, it definitely is way too heavy
> 	for me.
> 
> 	Hosts nic.funet.fi and archie.funet.fi are expanding
> 	linux-* lists from vger.rutgers.edu, and VGER is feeding
> 	archie at about rate of 100 000 - 200 000 recipient
> 	addresses every day. (Weekends are down to mere 100 k
> 	recipients..)  (NIC has heavier load, for only past
> 	two weeks has archie taken part of the load, before
> 	it everything was on nic..)

I am doing exactly this (router processing form the smtpserver through
"verification" to determine "localness" of recipients and senders for a
client.  I'm using a different channel (smtplocal) to indicate local
destinations, and I've modified the smtpserver to note whether recipient and
sender addresses are local when the verification is done.

This is on an SGI Indy (acting as mail hub) which also does over 100k
recipients on the weekends (obviously much more during the week) and it's
not a problem, though the mail is incoming from a dozen machines.

The primary cause for delay is DNS lookups, and you basically regain that
lost time during the succeeding router processing due to DNS caching.

This is with version 2.99.38 because I've been leery of the fast-paced
progression of versions and bug fixes of late...

-Andy

Global Auctions
http://www.globalauctions.com