On Fri, 23 Mar 2007 09:00:14 -0400 (EDT) [EMAIL PROTECTED] wrote: > On 22 Mar, Celejar wrote: > > > > ... > > > > > > > I use getmail, which is not even designed to run as a daemon. From the
[snip] > What advantages are there to getmail? I've run fetchmail > successfully in daemon mode, with the only problem being that it doesn't > always download all the messages in one shot. I'm not a big advocate > of it, however, it just works ok for me. I may play around with getmail > to see if it's better for me with regards to the download issue. I'm not much of an expert, but here's an excerpt from the getmail FAQ: > Why did you write getmail? Why not just use fetchmail? > > Short answer: ... well, the short answer is mostly unprintable. The long > answer is ... well, long: > > I do not like some of the design choices which were made with fetchmail. > getmail does things a little differently, and for my purposes, better. In > addition, most people find getmail easier to configure and use than > fetchmail. Perhaps most importantly, getmail goes to great lengths to > ensure that mail is never lost, while fetchmail (in its default > configuration) frequently loses mail, causes mail loops, bounces > legitimate messages, and causes many other problems. > > When people have pointed out problems in fetchmail's design and > implementation, it's maintainer has frequently ignored them, or (worse > yet) gone in the completely wrong direction in the name of "fixing" the > problems. For instance, fetchmail's configuration file syntax has been > criticized as being needlessly difficult to write; instead of cleaning up > the syntax, the maintainer instead included a GUI > configuration-file-writing program, leading to comments like: > > The punchline is that fetchmail sucks, even if it does have > giddily-engineered whizbang configurator apps. > As an example, Dan Bernstein, author of qmail and other software packages, > once noted to the qmail list: > > Last night, [EMAIL PROTECTED] reinjected thirty old messages from > various authors to [EMAIL PROTECTED] > > This sort of idiocy happens much more often than most subscribers know, > thanks to a broken piece of software by Eric Raymond called fetchmail. > Fortunately, qmail and ezmlm have loop-prevention mechanisms that stop > these messages before they are distributed to subscribers. The messages > end up bouncing to the wrong place, thanks to another fetchmail bug, but > at least the mailing list is protected. > > --D. J. Bernstein > > The maintainer also ignored dozens of complaints about fetchmail's > behaviour, stating (by fiat) that fetchmail was bug-free and had entered > "maintenance mode", allowing him to ignore further bug reports. > > fetchmail's default configuration values frequently cause lost or > misdirected mail, and seem to be chosen to cause maximum pain and > inconvenience. From fetchmail's to-do file (emphasis mine): > Maybe refuse multidrop configuration unless "envelope" is _explicitly_ > configured ... This would prevent a significant class of > shoot-self-in-foot problems. > > perhaps treat a delivery as "temporarily failed" ... This is so you > don't lose mail if you configure the wrong envelope header. > > fetchmail is famous for mangling messages it retrieves, rather than > leaving them alone as a mail-handling program should. getmail will add > trace information to messages (so you can see what happened, and when), > but will otherwise leave message content alone. > > In addition, fetchmail has a long history of security problems: > > * versions released before 20 June 2001 contain a buffer overflow, which > can be remotely exploited (see www.securityfocus.com/bid/2877 for > details). getmail is not vulnerable to buffer overflows, because > buffers in Python are dynamically sized. > * Another remotely-exploitable security hole discovered in fetchmail in > June 2002; versions prior to 5.9.10 (released in June 2002) are > exploitable . > * Reading fetchmail's UPDATES file, it appears that another security > problem was fixed in 5.9.12, where a server could crash fetchmail on > 64-bit platforms. Also worrying is a mention that it includes a fix > for "password shrouding". > * Another remotely-exploitable security hole in fetchmail discovered in > September 2002; this hole lets an attacker run arbitrary code on the > victim's computer. > * Another remotely-exploitable security hole in fetchmail discovered in > December 2002; once again, a remote attacker can run arbitrary code on > the machine running fetchmail in its default configuration. See this > advisory for details. > * January 2003: More buffer overflows in fetchmail let attackers run > arbitrary code . > * October 2003: Anyone can cause fetchmail to crash by sending you a > message . Other problems are here , and I might have missed some . > * Just in case you thought fetchmail was all better now, there's still > new security problems being discovered in it. In December, 2005, it > was revealed that anyone can send a fetchmail multidrop user a message > that causes fetchmail to crash. > > In July, 2004, it was noted that there may be at least 2 unfixed > denial-of-service attacks, 2 unfixed remote-code-execution, 2 unfixed > remote-user-access, and 3 unfixed remote-shell attacks against fetchmail. > See http://www.mail-archive.com/euglug@euglug.org/msg00971.html for > details > I've given up even trying to stay abreast of the various security holes in > fetchmail, but others have noted continuing problems, including: > > * another arbitrary code execution vulnerability announced on 21 July > 2005. > > The fetchmail authors' boneheaded decision to create a configuration-file > GUI editor (rather than actually giving fetchmail a sane configuration > syntax) also came back to bite them in the ass: in October 2005, it became > known that fetchmailconf created its files in such a way that users' > passwords could be read during file creation. > > But don't just take my word for it; see > http://docs.freebsd.org/cgi/mid.cgi?200102172349.QAA11724 and > http://esr.1accesshost.com/. > > getmail users have not had to worry about any of these security holes or > design and implementation errors. Now again, I'm not an expert, and I basically was just impressed by all these words :). But getmail certainly is easy to configure, and I've never had any problems with it. > > What happens if getmail (or fetchmail for that matter) gets called > by cron when another instance is still running, due to network issues > or huge attachments? This used to be more of an issue when we had > dialup, and I'd limit the message size in fetchmail. >From the getmail FAQ: > How do I stop multiple instances of getmail from running at the same time? > > getmail has no problems running multiple instances in parallel, though you > shouldn't attempt to use the same getmail rc file from two different > instances at the same time. If you need to prevent two instances of > getmail from running simultaneously, use any standard Unix method of > providing a mutex for this purpose. One example would be to run getmail > under a program like setlock (part of the daemontools package). Change > your script or crontab file to invoke getmail like this: > > /path/to/setlock -n /path/to/lockfile /path/to/getmail [getmail options] > > There are other programs that provide functionality similar to setlock. I have no experience with this. > Can either getmail or fetchmail be configured to leave the messages > (read or unread) on the server until they've been there for a certain > time period? Getmail can do something like this (I'm not sure if this is exactly what you want). From the configuration documentation: > The optional options section of the rc file can be used to alter getmail's > default behaviour. The parameters supported in this section are as > follows: [snip] > * delete_after (integer) -- if set, getmail will delete messages this > number of days after first seeing them, if they have been retrieved > and delivered. This, in effect, leaves messages on the server for a > configurable number of days after retrieving them. Note that the > delete parameter has higher priority; if both are set, the messages > will be deleted immediately. Default: 0, which means not to enable > this feature. HTH, Celejar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
