Re: 2.99.56pre4 config help

[Matti Aarnio <mea@nic.funet.fi>]

(cutting down the attribution to salient points, I hope..)
On Tue, Jun 10, 2003 at 01:58:59PM +0400, Eugene Crosser wrote:
... 
> Speaking of which - a random thought.  I understand that what I am
> talking about probably cannot be implemented, but still.  With the
> recent rise of spam, two problems surfaced:
> 
> 1. Spam attacks with random local names.  ...
> 2. "Bounce spamming".  ...
> 
> So, while the idea of separating smtp reception from routing seems
> attractive, it probably would be much better to do routing in the course
> of SMTP session, and report failures synchronously.  This would require
> less resources from the local server and generate less traffic on the
> Net.  Additional benefit of combining smtpserver and router into one
> entity would be that smtp policy could be processed by router that
> posesses of better tools for that.

Even the router is somewhat "stateless" in its processings of addresses.
There are definite benefits of having knowledge of some address existing,
or not, there I agree with you.

> It just came to me that such reorganization is not as unrealistic as it
> seems: smtpserver and router could still be separate processes, talking
> over unix domain socket or something; at the end of session smtpserver
> could pass the file to the router much the same way as it currently does
> for contentfilter.

Possibly a separate router process instance(s), possibly started by
the  smtpserver  master instance, and communication goes via some
multiplexing channel (e.g. bi-directional pipe for each of running
smtpserver peers).

Presently our synchronous routing needs (system depending) 0.100
seconds to start the router and do one routing, and finally it gets
discarded after (on average) one set of MAIL FROM/RCPT TO addresses
having been processed.   With multiple routing tasks (20 "from's"
in my test took 0.370 seconds with startup included -- or about 12-15
millisecs per address.)

There are certain short-circuiting possibilities in the router code
to handle some things, essentially all successfull expands of any
kind can be used to signal that address is acceptable.

How statefull that communication is ?  E.g. is there any real need
for storing 'from' address data, and latter using it in 'to' address
analysis?   If not, that simplifies things somewhat, and there can
be a pool of long living processes supplying this service.

For memory management reasons there should be a C coded service
function in the router that calls relevant script functions, and
handles memory management (flushing trigger) things.

> Am I mad or what?

"Proof of the pudding is in tasting" -- only working code shows
that the idea isn't mad.  How hard it is to make, indicates degree
of madness...  Hard enough, and it won't complete.

> Eugene
-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi