procmail
[Top] [All Lists]

Re: Procmail futures

1999-01-09 15:42:10

[Followups redirected to procmail-dev]

"Edward S. Marshall" <emarshal(_at_)logic(_dot_)net> writes:
On Sat, 9 Jan 1999, Bennett Todd wrote:
Remember the LDA is invoked for every delivery.

Sorry for ripping out the rest of your post, but this was the part that
made me sit up and think about something.

Why invoke a separate copy of a local delivery agent every single time you
want to deliver something (from a high-level perspective; forget
implementation details for now)?

Wouldn't things be more efficient with a single process, perhaps
multi-threaded (or multi-process, ala Apache), with the MTA simply feeding
this (via some sort of IPC), and this delivery "engine" doing deliveries? 
Give it enough smarts to be able to deliver mail according to a set of
user-defined rules (.deliveryrc, a database, etc.; which could be cached
for efficiency if needed).

Hmm, sounds like you're thinking of LTMP, documented in rfc2033 and
implemented (client-side) in sendmail 8.9.0.  I did an preliminary
implementation of the server-side in procmail back in May of 1997, and
it appeared to work, though I never got around to putting it into real
service.  For security and simplicity, my implementation forked a child
for each recipient (with multiple uids involved, multithreading is out
of the question).  Merging that work back into procmail is on my todo
list, but probably won't be done for a while -- I want to get some of
the simpler enhancements and fixes done before tackling LMTP again.
You can find my todo list at:
        http://www.gac.edu/~guenther/procmail/todo.html

If one was going to put a tcl interpreter into a procmail-like local
delivery agent, LMTP would be a godsend: initialize the interpreter
when the master process started, give it the message data when it is
read in, then fork a kid per recipient.  Poof: the fixed costs are
moved as much out of the loops as possible.


I'm cc'ing this message to procmail-dev(_at_)procmail(_dot_)org and setting
the Reply-To: to point there as well.


Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>