On Wed, 4 Apr 2007 20:22:55 +0200 Michelle Konzack <[EMAIL PROTECTED]> wrote:
> 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! ?? The quote is Charles Cazabon's, not Dan Bernstein's. > > 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! Cazabon is explaining, both before and after this comment, why he thinks it sucks; your comment makes no sense. [Of course, you can disagree that it sucks, but it's just plain silly and / or dishonest to accuse him of offering "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, [EMAIL PROTECTED] reinjected thirty old messages from > > > various authors to [EMAIL PROTECTED] > > > > > > 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! Proved by whom? What's the proof? Cite? > > > --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 New devs have apparently taken over fetchmail development [1]. They themselves admit that: > Fetchmail was handed over in a pretty poor shape, security-wise. It will > happily talk to the network with root privileges, use sscanf() to read > remotely received data into fixed-length stack-based buffers without length > limitation and so on. A full audit is required and security concepts will > have to be applied. Random bits are: > > * code talking to the network does not require root privileges and needs > to run without root permissions > * all input must be validated, all strings must be length checked, all > integers range checked > * all types will need to be reviewed whether they are signed or unsigned > > > 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? It is reasonable to be distrust an app with a long history of security flaws, and see again the above quote from the new devs about the poor security condition of fetchmail when they took it over. [The quote is apparently from 2006, and IIUC, they imply that they have not quite whipped it into shape yet. I may be misreading, though.] > > > * Another remotely-exploitable security hole discovered in fetchmail > > > in > > > June 2002; versions prior to 5.9.10 (released in June 2002) are > > > exploitable . > > Which? CVE-2002-0146 [2]: > fetchmail email client before 5.9.10 does not properly limit the maximum > number of messages available, which allows a remote IMAP server to overwrite > memory via a message count that exceeds the boundaries of an array. > > > * 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)! Cite? > > > * 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... Namely? > > > * 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! Wonderful. > > > * 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? You know, Michelle, you might want to do at least *some* research before just spouting off. A brief glance at CVE finds this [3]: > fetchmail before 6.3.1 and before 6.2.5.5, when configured for multidrop > mode, allows remote attackers to cause a denial of service (application > crash) by sending messages without headers from upstream mail servers. > > > > 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)!!! You have done pen testing and are absolutely convinced that the Security Focus and CVE stuff is / was bogus? > > > 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! Perhaps correctly as in according to spec, but do you mean 'sane' as in intuitive and logical? > > > 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... It's on the Fetchmail home page [0]! CVE-2005-3088: Fetchmailconf was found to open the configuration files world-readable, writing data to them, and only then tightening up permissions, which may cause password information to be visible to other users. This bug affected fetchmail 6.2.0, 6.2.5 and 6.2.5.2. The bug is fixed in fetchmail 6.2.5.4 and 6.3.0. > > > > 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. Has anyone else reported problems? I'd like to see some corroboration and more details. Celejar [0] http://fetchmail.berlios.de/ [1] http://www.fetchmail.info/design-notes.html [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0146 [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4348 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
