Bug 18008 - Pine and application/pgp
Summary: Pine and application/pgp
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pine   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-01 10:10 UTC by Tim Waugh
Modified: 2007-03-27 03:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-25 09:52:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Tim Waugh 2000-10-01 10:10:49 UTC
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.

Comment 1 Cord Kielhorn 2000-10-01 15:08:09 UTC
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'.


Comment 2 Cord Kielhorn 2000-10-01 15:11:25 UTC
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'.


Comment 3 Trond Eivind Glomsrxd 2000-10-01 15:21:41 UTC
As seen above - not a bug. Closed.

Comment 4 Tim Waugh 2000-10-02 14:29:15 UTC
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


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).]

Comment 5 Mike A. Harris 2000-12-14 19:07:23 UTC
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.

Comment 6 Tim Waugh 2000-12-14 19:11:53 UTC
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..

Comment 7 Mike A. Harris 2000-12-14 19:24:26 UTC
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.

Comment 8 Tim Waugh 2000-12-14 19:33:39 UTC
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

Comment 9 Mike A. Harris 2001-01-28 20:28:59 UTC
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.


Comment 10 Mike A. Harris 2003-04-25 09:52:35 UTC
Going through deferred items.  pine is deprecated now, so closing this

Note You need to log in before you can comment on or make changes to this bug.