[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: smtpserver consulting router
Once Andy Poling wrote:
>On Mon, 23 Feb 1998 email@example.com 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
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
You can't teach a new mouse old clicks