On Wed, Nov 05, 2003 at 01:42:34AM +0100, Vincent Lefevre wrote: > On 2003-11-04 15:42:40 -0700, Monique Y. Herman wrote: > > On Tue, 04 Nov 2003 at 21:54 GMT, Vincent Lefevre penned: > > > In some sense, yes. But if fetchmail didn't use the delivery system, I > > > wouldn't have lost mail. > > > > And if I hadn't typed 'rm -rf' in my root directory, I wouldn't have > > lost my system. > > If you're stupid enough to type 'rm -rf' in your root directory, it's > your problem. *You* are typing 'rm -rf', whereas the delivery system > is generally not configured by the user. Yup, and I think that what Monique was trying to say tactfully really comes down to this: If you're stupid enough to connect fetchmail to a misconfigured MTA, that's your problem. If a non-privileged user wants to use fetchmail and the MTA is misconfigured and won't play nice, there's always the -m option to skip the MTA and pipe mail straight to procmail (or the MDA of choice). > > In both cases, the behavior is well documented, and in both cases, > > user error can end in disaster. > > No, it is not well documented. fetchmail makes some assumptions on > the local delivery (which worked perfectly without fetchmail). So... fetchmail may require some configuration. I like things to work "straight out of the box" as much as the next guy (and fetchmail did, for me) but I don't see how you're getting from "some assembly required" to "defective product". > Moreover the local delivery configuration is out-of-control for > the user (one needs to have a root access, which is not acceptable > for a user program). Lots of things that an unprivileged user will _use_ need root to _configure_ before they work. > > fetchmail follows the "unix philosophy" of chaining well-defined > > capabilities so as not to reinvent the (less capable) wheel. > > Completely wrong! I hope you don't think that for instance, a MUA > should use the local delivery system for copying messages to a > different mailbox! I think that if you want to convince anyone that Monique, and fetchmail, and its authors, and its many users (and the entire Unix philosophy?) are "completely wrong"; you'll need a more solid argument than this groping for a dubious metaphor. Besides which, I can easily see people having mutt use procmail to sort and move mail to a different mailbox. Maybe I want to take advantage of filter rules that weren't there when the mail was delivered the first time... Very much the same philosophy as with fetchmail passing to the MTA. The MTA's job is to transport mail. It's generally good at it. Fetchmail's job is to get mail from a remote mailbox. Why rewrite MTA functionality? Why not just hand off to the existing MTA and let it do its job? If the MTA is broken/misconfigured that's hardly fetchmail's fault. > > If you don't like that approach, then don't use the tool, but don't > > claim that the tool is poorly designed just because you don't like > > this philosophy and furthermore didn't take the time to understand > > the basics of how the tool worked. > > It is poorly designed as a POP3 mail fetcher tool, as it relies on > special support of the local delivery configuration. If you're going to write off as "poorly designed" any tool that requires some configuration, maybe Linux is not for you. And its "special support" requirements don't seem to be too special. It worked straight outta the box with my straight-outta-the-box install of Exim. My $0.02CDN -- ,-------------------------------------------------------------------------. > -ScruLoose- | Hi! I'm a .signature virus. Copy me into < > Please do not | your ~/.signature to help me spread! < > reply off-list. | < `-------------------------------------------------------------------------'
Attachment:
pgpRWGCLBx46o.pgp
Description: PGP signature