>[...] Unfortunately, ESR would not accept patches for the mistaken
MX problem, nor for the preference order problem, nor for the
tunneled envelope information stripping problem. He seemed to
be too busy with speaking engagements, and has since declared
fetchmail to be in "maintenance mode", in order to demonstrate
a recognizable commercial software lifecycle for an Open Source
project, to give business the warm fuzzies.
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.
But this is not the strongest language. Perhaps the most snarky response to fetchmail comes from Terry Lambert (docs.freebsd.org/cgi/getmsg.cgi?fetch=585008+0+archive/2001/freebsd-arch/20010218.freebsd-arch):
>As to fetchmail: it is an abomination before God. If someone in the press ever paid for an audit of the source code, the result would refute the paper "The Cathedral and the Bazaar" to such an extent that it could damage the Open Source movement, which has pinned so much on the paper, in ill-considered haste.
>ESR has constantly maintained that fetchmail is "not an MTA", and he is right: it could be, but it's not.
>When mail is delivered to a POP3 maildrop, envelope information is destroyed. To combat this, you would need to tunnel the envelope information in headers. Generally, sendmail does not support "X-Envelope-To:" because it exposes "Bcc:" recipients, since fetchmail-like programs generally _stupidly_ do not strip such headers before local re-injection of the email. Without this information, it can not recover the intended recipient of the email. The fetchmail program delivers this mail to "root".
>The program has another bug, even if you elect single message delivery (in order to ensure a "for <user@domain>" in the "Received:" timestamp line. The bug is that it assumes the machine from which the download is occurring is a valid MX for your domain.... [pld: the end result is misaddressed replies]
...
>Unfortunately, ESR would not accept patches for the mistaken MX problem, nor for the preference order problem, nor for the tunneled envelope information stripping problem. He seemed to be too busy with speaking engagements, and has since declared fetchmail to be in "maintenance mode", in order to demonstrate a recognizable commercial software lifecycle for an Open Source project, to give business the warm fuzzies.
Nope.
UUCP must stay; Fetchmail sucks (2001) (freebsd.org)
https://mail-archive.freebsd.org/cgi/getmsg.cgi?fetch=585008...
>[...] Unfortunately, ESR would not accept patches for the mistaken MX problem, nor for the preference order problem, nor for the tunneled envelope information stripping problem. He seemed to be too busy with speaking engagements, and has since declared fetchmail to be in "maintenance mode", in order to demonstrate a recognizable commercial software lifecycle for an Open Source project, to give business the warm fuzzies.
https://pyropus.ca./software/getmail/faq.html#faq-about-why
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.
[...]
https://pld.cs.luc.edu/courses/412/spr20/mnotes/bazaar.html
But this is not the strongest language. Perhaps the most snarky response to fetchmail comes from Terry Lambert (docs.freebsd.org/cgi/getmsg.cgi?fetch=585008+0+archive/2001/freebsd-arch/20010218.freebsd-arch):
>As to fetchmail: it is an abomination before God. If someone in the press ever paid for an audit of the source code, the result would refute the paper "The Cathedral and the Bazaar" to such an extent that it could damage the Open Source movement, which has pinned so much on the paper, in ill-considered haste.
>ESR has constantly maintained that fetchmail is "not an MTA", and he is right: it could be, but it's not.
>When mail is delivered to a POP3 maildrop, envelope information is destroyed. To combat this, you would need to tunnel the envelope information in headers. Generally, sendmail does not support "X-Envelope-To:" because it exposes "Bcc:" recipients, since fetchmail-like programs generally _stupidly_ do not strip such headers before local re-injection of the email. Without this information, it can not recover the intended recipient of the email. The fetchmail program delivers this mail to "root".
>The program has another bug, even if you elect single message delivery (in order to ensure a "for <user@domain>" in the "Received:" timestamp line. The bug is that it assumes the machine from which the download is occurring is a valid MX for your domain.... [pld: the end result is misaddressed replies]
...
>Unfortunately, ESR would not accept patches for the mistaken MX problem, nor for the preference order problem, nor for the tunneled envelope information stripping problem. He seemed to be too busy with speaking engagements, and has since declared fetchmail to be in "maintenance mode", in order to demonstrate a recognizable commercial software lifecycle for an Open Source project, to give business the warm fuzzies.
Ouch.