mutt feeds more to gnupg than it needs, causes invisible/lost text
You won't see this text if mutt automatically verifies signed text (if pgp_auto_decode is set). Run ':exec check-traditional-pgpreturn' 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- ---BeginMessage--- 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/)
Re: mutt feeds more to gnupg than it needs, causes invisible/lost
Hello Martin, It seems there is a misunderstanding from you of course the parser from debian because normaly the Debian Signature Parser cut off the GPG signed message and packe it into a new one with the signature attached, which mean, it change te Header from gpg-signed to multipart put the origial signed message body in the first part and then the Debian- Signature in the second one. Now, I am puzzeling arround, when this was changed back to the current behaviour. Maybe you have ask the listmasters... It seems it was changed by the transition from lists to listz since I have old messages which show the behaviour I described. Attaching a signature outside (exactly at the end) of the mime boundary is AFAIK not allowed by RFC. The part will be only shown, if it is attached at the beginning of the body. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # http://www.tamay-dogan.net/ Michelle Konzack http://www.can4linux.org/ Apt. 917 http://www.flexray4linux.org/ 50, rue de Soultz Jabber linux4miche...@jabber.ccc.de 67100 Strabourg/France IRC#Debian (irc.icq.com) Tel. DE: +49 177 9351947 ICQ#328449886 Tel. FR: +33 6 61925193 signature.pgp Description: Digital signature
Re: mutt feeds more to gnupg than it needs, causes invisible/lost
You won't see this text if mutt automatically verifies signed text (if pgp_auto_decode is set). Run ':exec check-traditional-pgpreturn' if you see it to get the described effect. -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hello, also sprach Michelle Konzack linux4miche...@tamay-dogan.net [2009.11.27.1538 +0100]: It seems there is a misunderstanding from you of course the parser from debian because normaly the Debian Signature Parser cut off the GPG signed message and packe it into a new one with the signature attached, which mean, it change te Header from gpg-signed to multipart put the origial signed message body in the first part and then the Debian- Signature in the second one. This has nothing to do with the case at hand. It is true that there seems to be a problem with the Debian list servers, and I am following up on that. For MIME messages, the list servers *must* attach a new part for they cannot edit existing parts which might be signed. The actual problem remains though. For some reason, the last message I sent was inline *and* PGP-mime signed, thus this one is simpler to exemplify the problem. There's a bit of text preceding the Hello, up top of 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. - -- martin | http://madduck.net/ | http://two.sentenc.es/ i always choose my friends for their good looks and my enemies for their good intellects. man cannot be too careful in his choice of enemies. -- oscar wilde spamtraps: madduck.bo...@madduck.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAksP6YQACgkQIgvIgzMMSnXzWgCgrgSe40w2i1Qwc3jKNMbh1cbU xysAoLerRS2pXJkT3E90TXAuH1l6KSr5 =Qt8M -END PGP SIGNATURE-
Re: mutt feeds more to gnupg than it needs, causes invisible/lost
martin f krafft wrote: The actual problem remains though. For some reason, the last message I sent was inline *and* PGP-mime signed, thus this one is simpler to exemplify the problem. There's a bit of text preceding the Hello, up top of 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. Indeed. I've noticed this as well. A more annoying case is if someone replies to a clearsigned PGP message and leaves the entire message intact (as those who top post are prone to doing). When mutt displays such a message the only thing it shows is the original, PGP signed text. It makes it appear as if the sender had simply resent the original post without adding anything of their own (the first few times I saw this, I figured it was user error, as those who top post are also prone to silly errors like that ;). I don't have any particular help for you Martin, but I can definitely confirm what you're seeing. I unset $pgp_auto_decode to work around this for the time being. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Two things are infinite: the universe and human stupidity; and I'm not sure about the universe. -- Albert Einstein (1879-1955) pgpTWqKsIXbIx.pgp Description: PGP signature
Re: mutt feeds more to gnupg than it needs, causes invisible/lost
So, a couple of things... On Fri, Nov 27, 2009 at 11:55:52AM +0100, martin f krafft wrote: You won't see this text if mutt automatically verifies signed text (if pgp_auto_decode is set). Run ':exec check-traditional-pgpreturn' if you see it to get the described effect. I have pgp_auto_decode set, and additionally I unset it and manually executed check-traditional-pgp, and I saw the above text in all cases. So unless I misunderstood you, it seems my Mutt behaves differently from yours... But besides that, check-traditional-pgp is not intended to work with MIME messages... check-traditional-pgp (default: Esc P) This function will search the current message for content signed or encrypted with PGP the “traditional” way, that is, without proper MIME tagging. Technically, this function will temporarily change the MIME content types of the body parts containing PGP data; this is similar to the edit-type function's effect. The pgp-auto-decode variable is meant to be set only if you primarily receive mostly non-MIME PGP messages. Which is to say that check-traditional-pgp is only meant for non-MIME messages, and setting pgp_auto_decode makes mutt run that on every message. 3.153. pgp_auto_decode Type: boolean Default: no If set, mutt will automatically attempt to decrypt traditional PGP messages whenever the user performs an operation which ordinarily would result in the contents of the message being operated on. [...] This variable was added (by me, in fact) for folks who (like myself at the time) mostly received mail signed or encrypted in non-MIME fashion, which is to say all the signed/encrypted text and the signature itself was in the body of the message. For example, Pine for the longest time (and possibly still, but I have no idea) was only capable of using PGP in such a mode, and as it happened literally everyone I knew who used PGP also used pine at that time. So, you may not like the behavior, but it's not a bug. The solution, as already noted, is to unset pgp_auto_decode. It's neither appropriate nor required for MIME-based PGP mails, as mutt already does the right thing there without it if the messages are marked properly. The option is probably obsolete or headed there, and probably should not be set by default. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgphAGWbNtKnt.pgp Description: PGP signature
Re: mutt feeds more to gnupg than it needs, causes invisible/lost
I sometimes see TOFU on lists where the sender is replying to a message that was signed using traditional (inline) PGP. Their message does not show up once check-traditional-pgp is called. Only the original text from the quoted PGP signed section is displayed. I don't think mutt has always behaved this way, but it happens somewhat infrequently, so I could just not remember it. If you call check-traditional-pgp on this message, is this text lost? It is for me and I would call it a bug. It might also be some subtle difference between our configurations, gpg versions, etc. I don't know how much I care about it, as I just don't care much about inline PGP messages. But it is a bit curious. -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Derek Martin wrote: I have pgp_auto_decode set, and additionally I unset it and manually executed check-traditional-pgp, and I saw the above text in all cases. So unless I misunderstood you, it seems my Mutt behaves differently from yours... Hmmm. I can reproduce it using mutt -n -F /dev/null. It also doesn't seem to matter whether I use the gpgme backend or the classic backend. But besides that, check-traditional-pgp is not intended to work with MIME messages... I've seen this problem when there is no PGP-MIME involved. Or did you mean any MIME? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQFDBAEBCAAtBQJLEI+SJhhodHRwOi8vd3d3LnBvYm94LmNvbS9+dG16L3BncC90 bXouYXNjAAoJEEMlk4u+rwzjtNAIAKAMA3gookXY/N8HY9dgiLhR0+Ts2QvjmbAv kszePAwBy8KhXTt88MGPEE4Tz0QnUADDTtZBHxhVy29PPE+S9RITPuULgxoNvmcJ pJSkpGgZivlmm8vs90PBL68YKwH1Lv97XFSQhiAGWHtWBFR4LtB7gAvB+em4oeVB 6hKDo22O2A/5d/oU3L6SpOK/PbyRas4JDbSsV3Kk2lPYMyav+ATH+i9atCIjwi79 S4um0bxLsaTOhuJcjNpgosRpSpTunisYudF84bVmWHpr2NV+TLxeIkL2crai9aYc XmwnyK9AJljSzoPDlwufqvZRMxVsXs40a2X9EHEZ/uxNJ26XQ3E= =pxX0 -END PGP SIGNATURE- -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Hard work never killed anybody, but it is illegal in some places. -- Demotivators (www.despair.com)
