Ah ha! I didn't realize synchronous delivery was the key feature of the
mua_wrapper veature.
Is that really what's wanted in such a config though -- i.e. do you
really want to force the MUA to have its own queueing mechanism and to
force it to used its own queuing mechanism? Hmmm... I guess you do
since that's the easiest way to ensure the more naive user can still
find his or her undelivered mail and do something to delete or deliver
it. If their mail were to become "hidden" in the MTA queue then they'd
need to know about and to use a whole other interface to find and manage
it.
Indeed synchronous delivery is not likely what's wanted for TCP input
even in "local-only" configurations (and even when the store and forward
rule isn't so strictly necessary in such local-only configs). In those
cases it's highly unlikely that the sender will have its own queueing.
I think the dilema though is still that with a local-only mail system
there's still the high potential for confusing users, and causing them
to fall into the trap that seems to have been the original reason Marc
asked his question starting this thread.
It would be nice if everything, e.g. with e-mail on a system, worked the
same uniformly no matter what user-interface is used or where and how
the system is plugged into the network. Having one way of sending mail
from, say, Thunderbird, and another from, say, cron, is certainly less
than ideal.
The problem is of course that to make a unified and tightly integrated
design easy to use for a truly general-purpose system that can cover all
the bases from a PDA or laptop to a server to a firewall the whole
system's configuration, and all the subsystem configs, must be much more
tightly integrated.
If all the system integrator is doing, as Marc seems to be doing, is
just trying to come up with one universal "does everything for everyone"
stand-alone configuration for the mail sub-system then nothing is going
to work quite as well in any situation as it could and he will end up
with exactly the kinds of problems he began this thread with.
And of course it's not Philip's job as Exim's author to come up with all
the best ways of integrating his mailer into all the myriad of different
systems with all their multitudes of uses. That's the system
integrator's job, assuming they want to create a product that doesn't
require a trained expert do to custom configure every installation.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
