[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: info-gnus-english Digest, Vol 49, Issue 13
From: |
Alexey Pustyntsev |
Subject: |
Re: info-gnus-english Digest, Vol 49, Issue 13 |
Date: |
Mon, 14 May 2007 08:42:29 +1100 |
User-agent: |
Gnus/5.11 Emacs/22.0.95.1 |
<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
- Re: info-gnus-english Digest, Vol 49, Issue 13,
Alexey Pustyntsev <=