[Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8041] trunk/mailman/Mailman

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 27, 2006, at 10:36 PM, Brad Knowles wrote:

> At 6:33 PM -0700 9/27/06, Carson Gaspar wrote:
>
>>  I love the idea. A fork/exec per message always makes me  
>> twitch... I have a
>>  feeling it would also provide better fault-tolerance, especially  
>> in a
>>  replicated filesystem cluster, where you have clear atomic  
>> behaviour at
>>  your disposal.
>
> I agree that fork()/exec() is not an ideal model here, but then
> postfix doesn't use that model internally -- it uses a single parent
> with multiple child processes, and then hands off sockets.  It also
> keeps pretty much the entire working queue in memory, as opposed to
> single-threading through the filesystem.
>
> I don't see how using Maildir is going to solve any of these
> problems.  IMO, if we're going to learn from postfix, I think we
> should learn the right things and take away the right lessons, and
> not just glom onto some alternative technique that has been known to
> have a whole host of other problems.

Remember that we're only talking about how to most efficiently get  
mail from the MTA via local delivery into the Mailman incoming  
queue.  Once in Mailman we'll handle the message our own way, not  
with maildir.

This means that we're limited by what the various MTAs we want to  
integrate with support.  Until now, we've always gone with delivery  
to a program, because that's supported by all MTAs.  This is what  
Carson was referring to by fork/exec -- the MTA must fork/exec  
Mailman's mail wrapper (i.e. post) which basically just sucks the  
message text from stdin and write it to a file.  It seems clear that  
if you could eliminate that extra process (essentially a glorified  
cat), you'd get a win.  I think you're going to get about the same  
amount of filesystem thrashing in either case, so you might as well  
avoid the extra process overhead.

Looking at Postfix, what other options are readily available?  I  
suppose you could try to hook into the transport maps, but if I  
understand them correctly, you're still talking about forking a  
process per message.  Maybe LMTP to a daemon process is another  
option, but there appears to be no documentation on www.postfix.org  
about LMTP.

As for what's best for other MTAs, that's a good question.  I think  
we'll always have to support delivery-to-program since that seems  
like it's the lowest common method.  If there are delivery mechanisms  
that make more sense for specific MTAs, then I'm all for including  
them, but others who are more familiar with those mailer servers will  
have to help (read: donate code).

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRRtHdnEjvBPtnXfVAQIVKQP+PBYbnBeG7M7MySaZdGyUy74d/cRwModC
p19xJNMDsSvKKR4dy+uWzyzTF9uM3xPSKQUokvMWQHudyMmtf980E6db4THF1/do
i87z/B3gLS+7SwyXYeRPqnMlEjuHkmFGjPS4t9jz9sGaraixVE9qMqJ3F8S+n7hi
6DuAdUtRqOw=
=s19m
-----END PGP SIGNATURE-----