Pros and cons of PGP/MIME for outgoing e-mail?
wk at gnupg.org
Mon Nov 24 14:12:48 CET 2014
On Mon, 24 Nov 2014 10:25, bre at pagekite.net said:
> installed, because if you download the raw encrypted payload for
> processing offline, then after decryption you end up with a fragment of
> MIME and tools for working with such fragments barely exist outside the
> world of development tools (downloading the raw message source and
There is also a good chance that you end up with QP or even Base64
encoded plaintext which you neither can't read using standard desktop
tool. Now for the English world this is in general not a problem but
most people do not use plain ASCII and thus most mails are QB or Base64
encoded and can't be read without proper MIME support or by Unix gurus.
> manually feeding that to mutt, after manually adding the leading 'From '
formail is your friend ;-)
> Of course, today encryption is so rare that the only folks encountering
> this problem are nontechnical people, journalists and activists and the
> like, and they just give up and us something else to communicate and we
They are more clever that you probably expect. Copy+paste is a
technique they use all the day and with that it is pretty easy to
decrypt mail. Well plain ASCII of course because there is no standard
on how to specify the character set - no the charset: armor header does
not work. All the others users are using a modern MUAs anyway.
> is that they do generate valid MIME - after swearing at Python for
> months, it dawned on me that it's probably the PGP/MIME standard that is
> just being too picky.
Please explain that. RFC-3156 was released in 2001 to even relax some
requirements of RFC-2015 (1996). Now compare that to the various
problems with PGP-2 clear signed messages passing different gateways and
systems - all kind of fun happened depending on the versions of
PGP/GPG/FOO you used. RFC-3156 has a simple set of of requirements to
help the trailing Tab/Space/CR problems.
> This is part of what I meant by tightly coupled in a previous e-mail -
> unless MIME libraries and interfaces are explicitly written with
> PGP/MIME in mind, and carefully tested, they easily end up being
All the problems I have seen with MIME were due to incomplete MIME
implementations which barely worked ... and one which did ugly things to
mails internally passing from one animal to the other. And no, the
latter was not Outlook (which not claimed to be an RFC-822 aware mail
> incompatible. MIME is a forgiving standard, PGP/MIME is emphatically
> not. This causes headaches for people trying to implement PGP/MIME and
It is related to encrypted - it can't be for signatures. The whole
point of signatures is that you want to verify that the mail did not
BTW, the standard practice in the industry seems to be encrypt the
document and attach it. That is an easy to learn workflow and works
identical to the way many companies send letter (e.g. PDF attached).
>> Another drawback is that some proprietary email clients (like outlook)
>> do not enable someone to influence the mime-structre. This is the bigger issue
>> of course.
To be fair, that changed with Outlook 2010. We merely had not the
resources to change GpgOL to make use of the new Outlook structure.
> we've got. All the other issues aside, I don't think anyone will
> seriously argue that an e-mail encryption standard which transmits the
> subject line in the clear is a "good standard". It's silly and we can do
The subject is not part of MIME. PGP/MIME is about MIME - it is not
only used with RFC-821 and we can expect that SMTP will eventually
replaced by a P2P protocol - conveying MIME containers.
Anyway, the question is what you define as meta data: Only the
addresses? The attention line/the subject? Good MUAs inform the user
that the subject will be send in the clear and that can actually be good
thing for fast scanning of mails.
> 2) Is there any interest in trying to improve the standards?
Counter question: Is there any interest in fixing the remaining non MIME
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-users