Red Hat Bugzilla – Bug 18008
Pine and application/pgp
Last modified: 2007-03-26 23:36:01 EDT
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'.
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
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