Hi Bernhard, Bernhard Reiter <bernh...@intevation.de> wrote: > > thanks for working on Free Software and for discussing questions > like this in the open!
And thank you for the friendly reply. :-) > The short answer (from someone that was in the project team of S/MIME > implementations for mutt and kmail and support for PGP/MIME for Kontact > Mail and the Outlook plugin for Gpg4win (my roles did include technical > coordination, analysis and testing.): > > I am on the PGP/MIME side of things, I recommend it as default for > sending out emails. See also http://wiki.gnupg.org/SignatureHandling . > > a) for encrypted emails, there is no drawback. Every email client just > have to be able to deal with message/rfc822 mime-parts anyway. I actually disagree, the drawbacks are significant if you broaden the scope to include users of mail clients that do not have native support - which once you step out of the Free Software bubble, is most mail clients. As discussed in my post, if you have a PGP key but are unable to use a PGP/MIME aware mail client for whatever reason (work supplied laptop, no Internet outside of Internet cafés etc.), then you will not easily be able to receive and decrypt PGP/MIME attachments, even if you have GnuPG 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 manually feeding that to mutt, after manually adding the leading 'From ' delimiter is absolutely possible, but is not something you can expect a normal user to do, and not something a techie would enjoy doing on a regular basis). If this is carried to its logical conclusion, a burden ends up being placed on the user of a PGP/MIME enabled mail client - he has to carry around in his head a mental model of the technical capabilities of those receiving encrypted mail and *manually* change the format of his outgoing mail if he wants it to be readable by less technically privileged recipients. All in all, this goes way beyond what I consider an acceptable user experience. 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 don't hear from them again. This issue came to my attention however, due to the rise of webmail and attempts to write plugins to communicated using PGP (although Javascript is getting so powerful, they are likely to overcome this in the near future, with a select few compatible webmail services), and I'm told this is also what happened with the K9 mail client and APG. I'd like Mailpile users to be able to easily exchange secure content with these users, even if their tools are a bit on the primitive side. I will however freely admit that I am not a veteran of the PGP encryption field. I've worked with it off and on for the past 20 years, but Mailpile is my first serious attempt at implementing a full stack. So perhaps I am overestimating the impact here? > b) for signatures, https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime > lists the drawback that some transport agents will modify attachments. In the > past I've published a number of patches and problem reports to Mailman, so I > know this issue quite a bit. It is due to a missdesign of the python email > package and it should be fixed. (And it is fixable by a reasonable effort). Yes, Mailpile is written in Python and I've had to bend over backwards in order to validate and generate signatures. I am pretty sure I still have bugs to work out there, trying to compensate for the Python library's flaws without rewriting the whole thing is, long term, a losing game. It is tempting to blame the Python libraries, but the fact 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. 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 incompatible. MIME is a forgiving standard, PGP/MIME is emphatically not. This causes headaches for people trying to implement PGP/MIME and any source of friction like this reduces tool support and uptake. > 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. Exactly. > On the other hand, the advantages are clear and PGP/MIME seems the best > design given current standards and practure of SMTP and MIME. And given a > reasonable mime library, the implementation for creation is much easier as for > parsing and should not pose a major problem. In my experience both generating and validating PGP/MIME signatures is very error prone if you are saddled with a MIME library that has different ideas about things. You are right, it is the best standard we've got at the moment, but only by virtue of being the ONLY standard 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 better. So really, I guess I'm asking this community for feedback on two things: 1) Are these problems as common as my experiences imply, or am I just really unlucky? 2) Is there any interest in trying to improve the standards? -- I make stuff: www.mailpile.is, www.pagekite.net
signature.asc
Description: OpenPGP Digital Signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
