Reworking on smtpserver subsystems..

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

Two lengthy coding nights has left me quite beaten, no jokes even
of such are todays theme..


First a picture:

  http://zmailer.org/zman/smtpserver-processes.gif

I need to add a message-rate limiter/tracker subsystem into the
smtpserver, and at the same time I begun to consider what other
things might be needed.

For the longest time I have shied away from this thing, because I am 
worried about security in setting up the inter-process communication
without letting hostile users within the system to do nasty surprises.


My long-standing thought has been, that spawning a new interactive
router for each incoming message is royal waste of resources.
Similarly the content-filters could be reused.

Details to decide begin with how to create communication from
fork()ed smtpserver instance to subsystem server.  And even,
could the subsystem servers be folded all within the main
smtpserver.

Because we are using fork()  to instantiate existing listening
server into full-blown protocol talker,  this bodes a bit ill
to things, like keeping zillion fds open in the main server
just waiting to be switched over to a given sub-server.
(More about this below.)  (We could use  "spawn()" as well,
e.g. in order to run this thing in windows, but starting the
SMTP protocol interaction server in such a way is heavier, than
it absolutely needs to be -- in UNIX anyway.)

The picture I have drawn is least messy one I have so far come up,
but runs separate process instances with need to have published
rendezvous points.

Are the rendezvouz points in AF_UNIX, AF_INET, or even AF_INET6 ?
(Or  doors(2)! )  How to handle security (even weakish) so that
nobody inside the box connects to the interactive server and do
something drastically stupid ?   Or is such even necessary ?
(e.g. router interrogation protocol could talk over loopback
address, and would handle request/reply processing in safe manner;
AF_UNIX rendezvouz sockets can be named in ZENV variables, of course.)


In the case of the content-filter interaction:  What would be safest way
to pass in reference for the message file over rendezvouzed socket ?
The content-filter server would need to be able to scan daemon owned
files under $POSTOFFICE/public/, but that does not secure against
everything possible.  What would be the threats in this environment
with each connectivity way ?  Would there be need to pass at first
some password ?

For the rate-logger/tracker things are a bit more complex.  My thinking
is that the rate-logger/tracker is a server in itself talking to its
peers and telling them, that some IP address has done thing X, and
that everybody within the cluster should count it.  (I am thinking
of using IP multicast with TTL = 1, e.g. lan-local.)  Although...
we do already define 'etrn-cluster' parameters.  The idea of "cluster"
members is the same, but communication points (TCP or UDP ports) are
different.  The 'mailq' socket is held at the scheduler, after all...
It is rather stupid sounding idea to replicate same data to multiple
configuration entries, of course..    Another way could be, that
we just presume the cluster front-end L4-aware switch to balance
incoming connects to all servers, or to send them all the time to
same server...

In either case, the rate limitation using this tracking data will
bite at earliest at N rate-limited events.  Predicting exactly when
it bites is rather complicated, with C servers in cluster it will
bite the lattest at N*C events.



The 'messy' approach would be to run all multiplexing servers in
the master smtpserver interaction loop.  The good part would be
that bi-directional socket pairs are easier to create in that
environment for each smtpserver protocol talker,
( fd 0,1,2 for the SMTP socket, 3,4,5 for server IPCs.. )
but post fork() cleanup is very messy.
(Scheduler does that, after all, but it can rely transport-agents
to have their environments cleaned by virtue of 'close-on-exec'
flags on most sockets and files.)


Any thoughts, anyone ?

-- 
/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