[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to run fetchmail as daemon at startup



Am 2007-03-23 09:38:31, schrieb Celejar:
> >    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.

This is typical Bernstein bullshit!

  1)  I have never lost any messages since 1999/03
  2)  Never gotten mail loops
      (How can they if fetchmail fetch only messages)
  3)  Bounces are only done by the MTA or MDA not by fetchmail.
  4)  Which other problems?

> >    When people have pointed out problems in fetchmail's design and
> >    implementation, it's maintainer has frequently ignored them, or (worse

  What was ignored?

> >    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

  Where is the problem with the syntax?

> >    configuration-file-writing program, leading to comments like:

  I do not like fetchmail-conf so I do not use it...
  I have my OWN X-GUI which I like since it do want I want!

> >      The punchline is that fetchmail sucks, even if it does have
> >      giddily-engineered whizbang configurator apps.

  No explanation WHY it sucks!

> >  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.

  Not right, this is definitivly a bug in qmail!
  Which IS proved!

> >      --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 is actively developed and
  gotten many enhancements since 1999/03

> >    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.

  This happen since most ISP's do not know HOW to do multidrop.
  D.J. Bernstein should read the RFC's adgain!

> >      perhaps treat a delivery as "temporarily failed" ... This is so you
> >      don't lose mail if you configure the wrong envelope header.

  Never gotten such problems...

> >    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.

  I have never a mangled messages and do not know,
  what bullshit he is talking about..

> >    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.

  Who use this old releases?

> >      * Another remotely-exploitable security hole discovered in fetchmail in
> >        June 2002; versions prior to 5.9.10 (released in June 2002) are
> >        exploitable .

  Which?

> >      * 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".

  And? Getmail was crashing too on 64Bit (Opteron)!

> >      * Another remotely-exploitable security hole in fetchmail discovered in
> >        September 2002; this hole lets an attacker run arbitrary code on the
> >        victim's computer.

  Oh... getmail had flaws too...

> >      * 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.

  Was very fast solved!

> >      * 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 .

  How this?  -- I fetch per day over 400.000 Messages on my Intranet Server
  and it haver happen for many years.

> >      * 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.

  HOW and WHERE?

> >    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

  Those are bullshit!
  I have tested and it does not happen since I use Debian/Woody (5.9.11)!!!

> >    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

The Syntax is working correctly!

> >    known that fetchmailconf created its files in such a way that users'
> >    passwords could be read during file creation.

I do not know about this...

> >    But don't just take my word for it; see
> >    http://docs.freebsd.org/cgi/mid.cgi?200102172349.QAA11724 and
> >    http://esr.1accesshost.com/.

  Blahblah!

> >    getmail users have not had to worry about any of these security holes or
> >    design and implementation errors.

"getmail" has lost many messages while I have tried out it on a test-server.

> 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.

"fetchmail" is easy to configure too...

I use it without any problems since 1999/03 and NEVER have lost messages.

> >      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.

getmail span a second instance while fetchmail refuse to start
a second instance for the same $USER for security reason.

> >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

Ahhh, since be default it do it, which mean you will run into locking
problems "fetchmail" refuse to start, with the exception if you create
a secondary TEMPDIR where it can run alone...

But this is ONLY on $USER reauest for security reason!

> >    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.

Right, so "getmail" is not secure for a $USER
who do not know how to handel such situation.

> >      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:

fetchmail not since it is designed to FETCH messages!
the reauested feature is a feature for a Stand-Alone-MUA
like kmail, mozilla or thunderbird

> >      * 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.

And one time the battery in your RTC give up... <wutsch>
ANY messages on the server deleted!

It just happen to me!

Thanks, Greetings and nice Day
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSN LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Attachment: signature.pgp
Description: Digital signature


Reply to: