* Re: info-gnus-english Digest, Vol 49, Issue 13
[not found] <20070512155652.1F28A14A99@sycore.org>
@ 2007-05-13 21:42 ` Alexey Pustyntsev
[not found] ` <mailman.623.1179093055.32220.info-gnus-english@gnu.org>
1 sibling, 0 replies; 3+ messages in thread
From: Alexey Pustyntsev @ 2007-05-13 21:42 UTC (permalink / raw)
To: info-gnus-english
<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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: info-gnus-english Digest, Vol 49, Issue 13
[not found] ` <mailman.623.1179093055.32220.info-gnus-english@gnu.org>
2007-05-13 23:39 ` Gernot Hassenpflug
@ 2007-05-14 11:12 ` Hadron
1 sibling, 0 replies; 3+ messages in thread
From: Hadron @ 2007-05-14 11:12 UTC (permalink / raw)
To: info-gnus-english
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: info-gnus-english Digest, Vol 49, Issue 13
[not found] ` <mailman.623.1179093055.32220.info-gnus-english@gnu.org>
@ 2007-05-13 23:39 ` Gernot Hassenpflug
2007-05-14 11:12 ` Hadron
1 sibling, 0 replies; 3+ messages in thread
From: Gernot Hassenpflug @ 2007-05-13 23:39 UTC (permalink / raw)
To: info-gnus-english
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-05-14 11:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20070512155652.1F28A14A99@sycore.org>
2007-05-13 21:42 ` info-gnus-english Digest, Vol 49, Issue 13 Alexey Pustyntsev
[not found] ` <mailman.623.1179093055.32220.info-gnus-english@gnu.org>
2007-05-13 23:39 ` Gernot Hassenpflug
2007-05-14 11:12 ` Hadron
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).