On Wed, Nov 05, 2003 at 09:34:09AM -0600, Ron Johnson wrote: > On Wed, 2003-11-05 at 09:08, Bijan Soleymani wrote: > > On Tue, Nov 04, 2003 at 03:42:40PM -0700, Monique Y. Herman wrote: > > > On Tue, 04 Nov 2003 at 21:54 GMT, Vincent Lefevre penned: > > > > On 2003-11-04 10:41:10 -0700, Monique Y. Herman wrote: > > > >> That's because fetchmail didn't lose the mail; the delivery system > > > >> did. > > > > > > > > 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. In both cases, the behavior is well documented, and in > > > both cases, user error can end in disaster. > > > > The purpose of rm is to delete files. The purpose of fetchmail is not to > > send my emails to /dev/null. It's not ok for a program to have dangerous > > defaults. Nowhere in the fetcmail manpage does it say: > > WARNING if your MTA is badly configured there will be MASSIVE LOSSAGE! > > If you don't know what an MTA is do not proceed! > > The purpose of fetchmail is to take mails from a pop server and > give it to the MTA. If the MTA then sends it to /dev/null, in > *no* way is that fetchmail's fault. Ok, I know, but it would be nice if people didn't lose mail this way. This is all the more reason for the warning: WARNING if your MTA is badly configured there will be MASSIVE LOSSAGE! Fetchmail will blindly send it email, and can't verify where the email is actually going. You have been warned! > Have you checked your MTA's man page to see if *it* says "WARNING > if your MTA is badly configured there will be MASSIVE LOSSAGE!"??? Bad example, my MTA doesn't rely on software X, where if X is badly configured massive lossage will occur. > > > fetchmail follows the "unix philosophy" of chaining well-defined > > > capabilities so as not to reinvent the (less capable) wheel. 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. > > > > There is another important objective: "doing the right thing". It is > > simply not acceptable to lose mail. Even if it isn't fetchmail's fault, > > fetchmail should be fault-tolerant (deal with a misconfigured mail > > system). Fetchmail should scream loudly: your mail system is fubar, > > bailing out now! I don't know if this is possible, but I think that > > that would help a lot of people. > > How the hell does fetchmail know whether the MTA is fubar? This is *why* there *should* be a warning. Because given a bad MTA fetchmail will happily send your mail to /dev/null. > Read this: http://cbbrowne.com/info/unix.html I am not disputing unix philosophy. I am disputing the "if I pipe data to another program, I am not responsible for what happens" non-sense. I am of the school that believes that it is not acceptable for a program to destroy users' mail. I believe that if this happens the user should send a bug report of the type: Dear so and so, Your broken software has annihilated my mail. Please fix this bug, so that other people won't have to suffer this way. and not Dear so and so, Your advanced software assumes there is a working MTA on the system. As I have lost a considerable amount of mail through this ingenius procedure I would appreciate it if you would add a configuration option that will bypass this step (deleting my emails). I think Havoc Pennington said something along these lines, but in a different context. Bijan -- Bijan Soleymani <bijan@psq.com> http://www.crasseux.com
Attachment:
signature.asc
Description: Digital signature