Re: info-gnus-english Digest, Vol 49, Issue 13

Re: info-gnus-english Digest, Vol 49, Issue 13

[Gernot Hassenpflug]

Whew, those are pretty devastating comments. Not to say fetchmail is
all bad, the bad attitude allegedly conveyed by the maintainers makes
it look a lot worse perhaps than it is. The great thing for us free
software users is that we are free to choose alternatives, write them
if capable, and educate one another about their various advantages and
shortcomings. Thanks for the useful info.
-- 
BOFH excuse #314:

You need to upgrade your VESA local bus to a MasterCard local bus.

Re: info-gnus-english Digest, Vol 49, Issue 13

[Hadron]

nospam@dev.null (Alexey Pustyntsev) writes:

> <hadronquark@gmail.com> Hadron writes:
>
>> 
>> And fetchmail was designed to lose and misdirect your mail?
>>
>> Does anyone else back up these claims? 
>>
>> I have been using fetchmail with procmail for over a year with no issues
>> whatsowhatsoever.
>
>> Is it better to use "getmail"?
>
> I think so. Getmail is written in Python and, probably, has better
> protection against various 'overflow' bugs and, yes, it seems to be
> far more reliable even when I use it over very slow connections. 
>

I installed it an ran it - works well.

I'm not sure the config is easier though - you need a seperate rc file
for each account from what I can gather.

Re: info-gnus-english Digest, Vol 49, Issue 13

[Alexey Pustyntsev]

<hadronquark@gmail.com> Hadron writes:

> 
> And fetchmail was designed to lose and misdirect your mail?
>
> Does anyone else back up these claims? 
>
> I have been using fetchmail with procmail for over a year with no issues
> whatsowhatsoever.

> Is it better to use "getmail"?

I think so. Getmail is written in Python and, probably, has better
protection against various 'overflow' bugs and, yes, it seems to be
far more reliable even when I use it over very slow connections. 

> btw, how is fetchmail "insecure"?

Below is what I read in getmail faqs. I think you may well find it
interesting too. The problems I had are described here precisely.


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


-- 
Rgds
Alexey