Package: fetchmail
Version: 4.7.6-1
Severity: important
diff -urN fetchmail-4.7.5/FEATURES fetchmail-4.7.6/FEATURES
--- fetchmail-4.7.5/FEATURES Sat Jan 9 17:02:43 1999
+++ fetchmail-4.7.6/FEATURES Sat Jan 30 19:45:33 1999
@@ -20,7 +20,8 @@
* There is now an interactive GUI fetchmail configurator,
fetchmailconf.
* Code is 64-bit clean and Y2K-safe.
- * Can axutomatically decodes armored 7-bit MIME into 8 bits.
+ * Automatically decodes armored 7-bit MIME into 8 bits (this can be
+ suppressed).
* You can specify which SMTP error is recognized as a spam block.
* Support for Kerberos V authentication.
* Support for IMAP-OTP authentication using Craig Metz's patches for
This is not a feature, it's a bug. It's a very, very bad bug.
The entire REASON 7-bit MIME exists is because there are some stupid mail
gateways out there that do moronic things like strip trailing blanks from
lines and mangle 8-bit mails.
PGP/MIME (RFC 2015) uses "7-bit MIME" (quoted-printable) encoding to ensure
the integrity of the message en route to its destination. When received by
a PGP/MIME aware MUA (like mutt), the message digest contained in the
signature attachment is used to verify the message. If they don't match,
which always happens if some broken program like fetchmail silently
autoconverts it, the signature is bad. This utterly defeats the practice
of PGP/MIME-signing mails, which is of crucial importance to the Debian
project; hence the severity of this bug.
So our good friend fetchmail comes along and mangles what the gateways
don't?
This is in blatant violation of RFC 1847.
The entire contents of the multipart/signed container must be treated
as opaque while it is in transit from an originator to a recipient.
Intermediate message transfer agents must not alter the content of a
multipart/signed in any way, including, but not limited to, changing
the content transfer encoding of the body part or any of its
encapsulated body parts.
I insist that this broken automatic feature be turned back off by default
(which the manpage still says is the case).
Furthermore, I believe fetchmail should contain prominent warnings that use
of this option violates RFC's and will render PGP/MIME useless for
clearsigning.
Finally, I ask that either the upstream maintainers of fetchmail begin
showing some responsibility with regard to new releases. By this, I mean
that untested new features should not be enabled by default without
warning. This has happened at least twice in the past three releases.
First there was the broken new "antispam" feature which trashed mails it
couldn't generate a bounce for, and whose configuration flag was missing
from the .fetchmailrc parser, and which was enabled by default, and now
there is this.
Fetchmail has a version number which reflects maturity. The appellation of
"gold", a la dozens, perhaps hundreds, of proprietary payware applications
in the past, is not construed by most people to mean that non-"gold"
releases are of beta (or alpha) quality.
If that's what they are, call them that. Apparently what is not "gold" is
excrement.
If the fetchmail maintainers are not willing to handle this important piece
of software responsibility, it may become necessary for the free software
community to fork a new version that upholds fetchmail's heretofore good
reputation for stability, predictability, and reliability -- and which does
not toss in new, broken, and poorly documented new features at the drop of
a hat a la Microsoft.
In the meantime, I suggest to the poor harried Debian maintainer that we
stick to the so-called "gold" versions of fetchmail for all Debian releases
(including "unstable"). Mail is a deadly serious issue -- fetchmail is
used by a great number of Debian users and developers (witness the number
of people on the lists who have been seeing these corrupted PGP/MIME
messages), and this may be one area in which we cannot afford to follow the
bleeding edge.
It is a shame that fetchmail, for so long a lesson in "bazaar" style
development, is now acquiring the worst habits of the traditional,
closed-source environment.
--
G. Branden Robinson | Human beings rarely imagine a god that
Debian GNU/Linux | behaves any better than a spoiled child.
branden@ecn.purdue.edu | -- Robert Heinlein
cartoon.ecn.purdue.edu/~branden/ |
Attachment:
pgpTfFzm0R2Ka.pgp
Description: PGP signature