Hide Forgot
Pine works fine with encryption and signed messages and such, except when I send messages with Mutt plus GnuPG: the Content-Type is application/gpg, and pine's pinegpg filters don't get triggered it seems. If I have incoming mail filtered through a script that changes 'application/gpg; ...; format=text' to 'text/plain', it works, but obviously that's not as good as making pine understand application/gpg.
There is no such thing as 'application/gpg'. 'application/pgp' has been withdrawn at least 4 years ago. Instead software should use the MIME types 'multipart/signed', 'multipart/encrypted', 'application/pgp-encrypted', 'application/pgp-signature' and 'application/pgp-keys'. Have a look at RFC 2015 for details. Therefor it's not a good idea to let pine handle 'application/gpg'. Cheers Cord
As seen above - not a bug. Closed.
I meant application/pgp. The bug still stands I think. Pine doesn't even attempt to cope with MIME security types, and messages sent out using PineGPG filters end up like this: [...] Content-Type: TEXT/PLAIN; charset=US-ASCII -----BEGIN PGP MESSAGE----- [...] That _can't_ be right. But it's the only format that pine understands. So the bug is either with pine or with pinegpg. [I think the reason for all this is that pine relies quite heavily on /etc/mailcap for things like this; unfortunately our /etc/mailcap seems to be broken, but I'll file another bug for that. Even with a fixed mailcap there won't be proper integration (reply to an encrypted message including the message text, for example).]
I have decided that the problem truely lies in the broken mailer using the improper mime type for gpg/pgp. IOW, mutt should be fixed to send the correct type. That said, other applications should be forgiving, so if I can correct this easily enough in PINE or in /etc/mime.types I will try to do so. As for PINE sending out incorrect content-type, that is a different bug on its own. There are a few reported bugs with pgp/gpg support for PINE to which I don't see any simple solution at this time. I am considering removing pgp/gpg support unless some other great solution comes to exist in the mean time.
Mutt sends the correct content-type, it's pine that doesn't. I am telling mutt to use the obsolete application/pgp rather than a proper MIME-encoding because pine doesn't have a _hope_ of understanding the latter. The limited pgp support that pine currently has _is_ useful though, since it's easy enough for the recipient to work around. It's just irritating..
Ok, I am not completely clear here. The initial bug report appears to be WRT pine receiving messages that are pgp signed and not detecting that properly. If this is what you're saying, and the incoming mail _is_ properly sogned, then it is a bug. If the message is not properly signed and using a validf mime type then it is not a bug, but is something I'd leave open as a "forgiving enhancement". Pine _sending_ gpg/pgp signed messages incorrectly is a different story. It is a separate issue to me though from fixing incoming pgp/gpg bugs. Please clarify this issue in my mind and I'll have a look-see at the problem deeper. Also please file a separate bug report for the pgp-sending pine issue as both problems are unrelated WRT a fix, and I'll want to close them seperately.
Yes, my fault, sorry. There are two separate bugs. This report is (meant to be) about this scenario: - send message using mutt with 'traditional' set - content-type is (correctly) set to 'application/pgp; ...' - pine's 'this is a PGP-signed message' filter doesn't trigger I'll file another bug about what pine sets outgoing signed mail's content type to..
I've read the relevant RFC's, and I agree that this is something that should be fixed. I don't consider it an extremely high priority though because the pinegpg app has a few other problems and I am going to try and find a better replacement for it if there is one out there. If not, I will look into this again some time and fix it. .
Going through deferred items. pine is deprecated now, so closing this as WONTFIX