Re: smtpserver consulting router

[Alexis Yushin <alexis@NL.net>]

Once Andy Poling wrote:
>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...

	Ok, so here we have couple of possibilities:

	1. Accepting everything with SMTP server, and letting router
	   just drop things it does not like on the floor

	2. Run SMTP server with all policy checks, therefore
	   reimplementing entire address parsing facilities in
	   smtpserver and lateron doing almost the same in router.
	   (Well, you know, those MAIL FROM: <@here.where.i.connect:spam@spam>)

	3. Run router synchroneously with SMTP server. Would not
	   be such a bad idea if we merge it together with PIPELINING,
	   where smtpserver could go on talking smtp, and queuing
	   request for the router. Would it be something?

	4. Run router in verification mode. We do not really need
	   to run full loaded router, to implement spam policy
	   hardwired into smtpserver, it would take router with
	   couple of relations and nothing else. Also we might
	   optimize the thing by not spawning router every smtp
	   connection.

	There is a group for whom anti spam in smtpserver works
better and there is a group who would prefer to have it in router.
Why dont we try out these two ways and give each other input on
what we'd experience.

	BTW, Matti, about PIPELINING, you probably know there is
a bug which would break the ``PIPE'' and SMTP connection if remote
side would not accept a recipient, therefore report a error to
MAIL FROM / RCPT TO -- sending zmailer gets messed up with error
codes.
							alexis
-- 
		You can't teach a new mouse old clicks