You won't see this text if mutt automatically verifies signed text (if pgp_auto_decode is set). Run ':exec check-traditional-pgp<return>' if you see it to get the described effect.
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hey folks, I sent this message clear-signed on purpose to illustrate what I think is a bug in the mutt-gpg integration. There's a bit of text preceding this mail, but if you configured mutt with pgp_auto_decode, then it filters the entire message through gnupg, which swallows all the unsigned text. A similar case happens when a mailing list manager appends a MIME-part with unsubscribe information, as was the case in the attached message to debian-devel-announce; mutt does not display this portion of the body, as it is unsigned. You need to <edit> the message to be able to see what I mean, then search for 'UNSUBSCRIBE'. I think that mutt should not do this, it should only filter through gnupg precisely the stuff which is marked as PGP content (/^-----/) and pass everything else verbatim. Is this doable? Should I file a bug report? - -- martin | http://madduck.net/ | http://two.sentenc.es/ "one should never do anything that one cannot talk about after dinner." -- oscar wilde spamtraps: madduck.bo...@madduck.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAksPsAwACgkQIgvIgzMMSnV72wCeLIVFzQmBREMLcwEWvLJy1yxC BJAAn2of52aM/XbnGXs68LrxXaly/ggp =iwJ4 -----END PGP SIGNATURE-----
--- Begin Message ---Hello everyone, Over the past year or two, lots of changes have been made to the mail handling for user mail accounts, and there are plenty of other changes planned for the future. All the changes below do not affect liszt or alioth. Some notable changes: - A single mail configuration template for all d.o machines - The busier machines use clamav with 3rd party signatures for scanning mail - packages.d.o uses spamassassin on all mail at smtp time - The BTS uses greylisting - Most machines now route through a set of gateway MXes for inbound and outbound delivery, letting those machines spend more time doing what they're meant to and less time fighting spam. - Users can set the envelope for their mail - Users can decide whether a mail should be rejected, marked up, or blackholed if it gets a 'hit' during content inspection - Teams can have group writable mboxes or not - Teams can use the same anti-spam techniques (RBLs, callouts, greylisting, etc) as regular user accounts. - Teams can have some aliases be only addressable from within the d.o estate Things planned for the future: - Breaking up the conflation between @debian.org and @$machine.debian.org mail handling (more on this in a seperate mail) - BATV checking (there is support in ud-ldap, just not yet in the exim configuration) - Users can decide to opt out of the default anti-spam setup in place. One of the happy side effects of this is a substantial reduction in spam across the estate. We've stopped accepting roughly half a million mails a day that were obviously spam, although of course we can do better. One way you can help yourself is to log in to db.debian.org and select the anti-spam options you feel would be helpful for your account. For DNSBLs and RHSBLs, you'll need to use the mail gateway, as there is not yet support in the web interface. More notes on what the various fields mean and how they will be used can seen in the very meager documentation [0] and more accurately here [1]. Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sg...@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | ----------------------------------------------------------------- [0] http://db.debian.org/doc-mail-handling.html [1] http://git.debian.org/?p=mirror/dsa-puppet.git;a=tree;f=modules/exim;h=HEAD
signature.asc
Description: Digital signature
--- End Message ---
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
