Re: How to run fetchmail as daemon at startup
On Fri, 23 Mar 2007 09:00:14 -0400 (EDT)
judd@wadsworth.org 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, root@xxxxxxxxxxxxxxxxx reinjected thirty old messages from
> various authors to qmail@xxxxxxxxxxxxxx
>
> 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
Reply to: