Missing PGP/MIME support

[vasyugan]

I have installed and configured mailvelope, authorized the nextcloud domain and enabled the API. On one of my computers yesterday, I saw it working as expected, on the other, I see that incoming PGP encrypted mail (created with Mailvelope) is always displayed only as an attachment, rather than decrypted.

When I access the same mail account through roundcube with mailvelope enable, everything works just fine.

Expected behavior

Tell us what should happen It should just work™

Actual behavior

Mail app

Mail app version: (see apps admin page, e.g. 1.50)

Mailserver or service: self-hosted dovecot

Server configuration

Operating system: (e.g. Ubuntu 20.04)

Web server: Ningx

Database: mariadb

PHP version: 7.4

Nextcloud Version: 20.0.0

Client configuration

Browser: Firefox 81

Operating system: Debian GNU/Linux Bullseye

[ChristophWurst]

The problem is that our client can't handle embedded messages. This is not a problem with encrypted messages but any forwarded or similar message that is not the main part.

Ref https://github.com/nextcloud/mail/pull/2541 for the PR that added the download as attachment.

I think there is an existing ticket about the embedded messages but I can't find it right now …

[vasyugan]

The problem is that our client can't handle embedded messages. This is not a problem with encrypted messages but any forwarded or similar message that is not the main part.

Thanks, Christoph, just what irritates me is, with the same browser and the same Mailvelope it works just fine in Roundcube. I wonder if roundcube has some built-in magic that Nextcloud's mail app does not with regard to Mailvelope support.

Got interested in this because I am in the process of convincing a global human rights network to use Nextcloud and they got unexpectly interested in the mail app, even though they were supposed to use thunderbird with its build-in PGP support... So they definitely need robust PGP handling. Downloading and manually decoding messages is certainly not an option, as most staff and board are non-technical folks...

[ChristophWurst]

just what irritates me is, with the same browser and the same Mailvelope it works just fine in Roundcube

It's because Mailvelope just detects the PGP message in the browser document and offers decryption. Nextcloud Mail doesn't display the embedded message at all, hence there is nothing for Mailvelope to detect.

So, again, any simple email with an encrypted emails should work fine. It's just the ones that are send embedded as an attachment.

[vasyugan]

just what irritates me is, with the same browser and the same Mailvelope it works just fine in Roundcube

It's because Mailvelope just detects the PGP message in the browser document and offers decryption. Nextcloud Mail doesn't display the embedded message at all, hence there is nothing for Mailvelope to detect.

So, again, any simple email with an encrypted emails should work fine. It's just the ones that are send embedded as an attachment. No, unfortunately, in my observation. Simple PGP/MIME messages fail, only legacy inline PGP seems to work.

[ChristophWurst]

No, unfortunately, in my observation. Simple PGP/MIME messages fail, only legacy inline PGP seems to work.

Mind exporting such an email as .eml or similar with Thunderbird and posting it here? Then someone can try to reproduce.

[vasyugan]

Here are the relevant lines:

Content-Type: multipart/encrypted;
 protocol="application/pgp-encrypted";
 boundary="Rfy9LYPuKd9RG8LFoc9aPDXwfzQ32qEQl"

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--Rfy9LYPuKd9RG8LFoc9aPDXwfzQ32qEQl
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

--Rfy9LYPuKd9RG8LFoc9aPDXwfzQ32qEQl
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

-----BEGIN PGP MESSAGE-----

wcBMA0AiiRyUAYVDAQf+OUZ3A2Yrpw+EhfFIr00lpkyP6bgrZwoHiolhZvD3zocq9tMRSdDngJg0
gHrgJc91y3jaLSeDuAQUWPU+k4ShevVDM+Z5S2SFwPhRWb5xXj/IANtWPmF4iLjsYSH0tMBpJm/w

[ChristophWurst]

But that is a multipart message with a dedicated pgp part. So I guess it's the very same described limitation that Mail can't handle those. If there is a plain text part (as per content type) that contains pgp then it will display, I think.

As a remedy we could always show the application/pgp-encrypted part as if it were text and hope that Mailvelope picks it up.

[vasyugan]

But that is a multipart message with a dedicated php part. So I guess it's the very same described limitation that Mail can't handle those. If there is a plain text part (as per content type) that contains pgp then it will display, I think.

As a remedy we could always show the application/pgp-encrypted part as if it were text and hope that Mailvelope picks it up.

As far as I see it, that's the PGP/Mime standard, which is the default in any real mail client, e.g. Outlook/GpgOL and Thunderbird. Inline PGP seems to be mainly used by Mailvelope and as I understand, it is legacy. PGP/MIME is the correct™ way, that any mailer should support, at least passively.

Just to be sure, this here is from a message composed in Thunderbird 78:

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--siAL4TRdtcJVH51ByjyPKQ6ZH8U234sU2
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

--siAL4TRdtcJVH51ByjyPKQ6ZH8U234sU2
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

-----BEGIN PGP MESSAGE-----

wcBMA0AiiRyUAYVDAQf9F77iZuyWvXnXWHJzX1TgqLxj+eu8OZvwkRgJLCIIq/xS98raHnY/Il+P
Sq2pMc6NEKjvAOIPEm/jJPhI09Jt9dtoqMRLEqlAts29XP8YU7vWgCR2So4aPVu9/hRNm6lwfD2s 

[ChristophWurst]

Thanks for the info! I will look into this when time allows but right now this is a very low priority. If you are a developer or know someone who could help with the development I'm happy to discuss what we might need to change.

[vasyugan]

Thanks for the info! I will look into this when time allows but right now this is a very low priority. If you are a developer or know someone who could help with the development I'm happy to discuss what we might need to change.

Unfortunately, I am not a developer, my modest contributions to Nextcloud are limited to documentation. However, I should flag that as long as the combo of Nextcloud Mail and Mailvelope cannot handle PGP/MIME messages, it does not implement the established standard, and in my case, this means that it cannot be used by the network as their default mail client, which is a shame because else, they will be using nextcloud for most of their needs.

There is a long-standing Mailvelope bug related to PGP/MIME, https://github.com/mailvelope/mailvelope/issues/41 but I guess that fixing this issue here would not have to wait this other issue be fixed, because all Nextcloud Mail would have to do is download the bodies of messages with the content type "application/pgp-encrypted".

I am interacting with some other organisations who are focused on cybersecurity for civil society and might therefore be interested in contributing, but I would not be optimistic, that they have any free resources to devote to this, unfortunately.

[ChristophWurst]

No worries @vasyugan, I appreciate the time you take to report this.

I agree that it's not too much effort. But this is one of many small changes that we have to work on. And everyone has this ticket where they think it's that most important one. But of course that always depends on the user context.

In any case, leaving this open for pickup later or anyone else who would like to help.

Any enterprises using the software can get a subscription and we'll be then able to shift priorities accordingly. But I guess that doesn't work for your organizations.

[vasyugan]

No worries @vasyugan, I appreciate the time you take to report this.

I agree that it's not too much effort. But this is one of many small changes that we have to work on. And everyone has this ticket where they think it's that most important one. But of course that always depends on the user context.

In any case, leaving this open for pickup later or anyone else who would like to help.

Any enterprises using the software can get a subscription and we'll be then able to shift priorities accordingly. But I guess that doesn't work for your organizations.

Indeed. Civil society networks of that sort have limited resources anyway, and the situation was that I was trying to evangelize them to use PGP and then they discovered that Nextcloud comes with its own mail client which they would prefer to use over Thunderbird, and now I am looking for ways to reconcile security needs with their longing for convenience... I am just worried that they will happily adopt nextcloud but the glaring security of unencrypted e-mail will remain unaddressed.

[vasyugan]

But that is a multipart message with a dedicated php part. So I guess it's the very same described limitation that Mail can't handle those. If there is a plain text part (as per content type) that contains pgp then it will display, I think.

As a remedy we could always show the application/pgp-encrypted part as if it were text and hope that Mailvelope picks it up.

I think that's all that Roundcube does and that indeed suffices to tackle the situation.

[vasyugan]

@ChristophWurst I just grepped through the roundcube source code for encrypted.asc and application/pgp-encrypted, and it turns out, that it doesn't even have any special code for downloaded and displaying pgp/mime parts. It just seems to honour "Content-Disposition: Inline". Can't Nextcloud Mail just do the same?

[ChristophWurst]

It just seems to honour "Content-Disposition: Inline". Can't Nextcloud Mail just do the same?

"just". Yeah …

[vasyugan]

It just seems to honour "Content-Disposition: Inline". Can't Nextcloud Mail just do the same?

"just". Yeah …

I see that lib/Attachment.php explicitly changes the disposition of mime parts from inline to attachment The comment says: "Serve all files with a content-disposition of "attachment" to prevent Cross-Site Scripting"

So I see, this is a precautionary measure, but it is one that roundcube apparently does not need.

(I thought I coud just make it work by commenting out this line, but this doesn't seem to have been enough)

given that it prevents PGP from functioning properly, it seems to be worth it, exploring alternatives. Again, sadly, I am not a developer, but the task seems relatively limited: ensure that XSS is prevented while content-disposition: inline parts are indeed displayed inline.

Would this be a correct description of the issue?

[ChristophWurst]

It's more complex than that. It's not just what part to hide or what not to show. It can become this recursive structure where you have a mesage inside a message inside a message.

This has to be done properly.

So it's blocked until we found the time to work on this or a customer funds the development.

[gpgmailencrypt]

May be a bit late but I just want to clarify something about the PGP/MIME format. A PGP/MIME message just has one attachment, the enrypted message. Once decrypted it contains the message body and all attachments, just like any other non-encrypted message. It even can contain some of the header data like the subject.

The advantage of PGP/Mime over pgp/inline is that it hides the complete content (including file names of attachments) and it keeps all formatting of the message body. See https://tools.ietf.org/html/rfc3156 for details.

And if you like you might want to have a look in the sourcecode of my software https://github.com/gpgmailencrypt/gpgmailencrypt/blob/master/gpgmailencrypt.py#L5001 You simply need to combine the headers of the encrypted email ( escpecially FROM, RECEIVED etc) with the decrypted body. Just the subject needs some additional attention, as it may be part of the encrypted message body (see above)

Technically a mail could contain a pgp/mime attachment and different non-encrypted or pgp-inline encrypted attachments. But this would be totally against the idea of PGP/MIME and I know no e-mail client that can handle such an e-mail correctly.

[ioogithub]

I believe I have this problem too. I am an new Nextcloud user and I have been trying to get Nextcloud mail and Mailvelope working without success all day. Mailvelope works perfectly with my mail provider's webmail page but doesn't work at all with Nextcloud and mailvelope. All I see is a single attachment "encrypted.asc".

Many mail providers will not switch to inline because as vasyugan mentioned in this thread: https://github.com/nextcloud/mail/issues/3833, PGP/Mime is the standard best practice while inline is a depreciated and not well supported.

If many webmail providers have been seamlessly doing this for years then the problem is not unknown, it is just not supported currently in Nextcloud and Mailvelope.

So it's blocked until we found the time to work on this or a customer funds the development.

I am not an enterprise customer however I may be interested in funding this development. Who do I speak to about this? It is important because without it, Nextcloud and mailvelope mail does not work at all for me.

[vasyugan]

I am not an enterprise customer however I may be interested in funding this development. Who do I speak to about this? It is important because without it, Nextcloud and mailvelope mail does not work at all for me.

@ioogithub i think one would have to open a bounty for third party developers as nextcloud only works with customers through enterprise subscriptions

[ChristophWurst]

https://help.nextcloud.com/c/nextcloud-freelancing/48 is the place to talk about freelance funding. Bounties are a bit of a dated concept right now: https://help.nextcloud.com/t/dont-use-bountysource-anymore/84943

[vasyugan]

https://help.nextcloud.com/c/nextcloud-freelancing/48 is the place to talk about freelance funding. Bounties are a bit of a dated concept right now: https://help.nextcloud.com/t/dont-use-bountysource-anymore/84943

Thanks! For me, I would have to see where to get external funding for this. There are donors funding cybersecurity related applications, but I would have to go looking. But before that, I guess one should have an idea how much money is actually needed, and also, what the freelancer needs to do to ensure that the patches are accepted by Nextcloud, @ChristophWurst is there any quick read on this? @ioogithub Did I correctly understand you that you might be willing to fund this from your private pocket?

[ChristophWurst]

In general I strongly agree with this plan @vasyugan. This week and next I won't have time to look into the details in order to provide any action items or a list of things to change.

[vasyugan]

In general I strongly agree with this plan @vasyugan. This week and next I won't have time to look into the details in order to provide any action items or a list of things to change.

Do you imply that you will eventually get back to us with a list of changes that would have to be made? That certainly would make the process much easier, as we could specifically tell the freelancer what he needs to change.

[ChristophWurst]

I'll try but I can't promise :v:

[vasyugan]

So I'll nag you again two weeks from now, I guess.

Am 22.03.21 um 12:55 schrieb Christoph Wurst:

I'll try but I can't promise ✌️

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nextcloud/mail/issues/3833#issuecomment-804005734, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZI4ODU6SGXBCDOGKKXOKDTE4V4RANCNFSM4SU7HZYQ.

[ioogithub]

@ioogithub Did I correctly understand you that you might be willing to fund this from your private pocket?

Yes I am interested in funding this because without it I can't use Nextcloud Mail and so without it, a cloud platform that can't do email is much less useful.

From the discussion above it sounds like bountysource is no longer a viable option. I contacted Nextcloud sales and although they thanked me for the offer of support they confirmed that they do not accept commissioned feature development.

They also mentioned specifically that this request is not a priority so there is a real risk of funding freelance development work which will not be accepted by the company and integrated into the product for various reasons. Unless I am missing something, it doesn't sound like there is any acceptable mechanisms in place for integrating new features with this funding model.

[vasyugan]

@ioogithub Did I correctly understand you that you might be willing to fund this from your private pocket?

Yes I am interested in funding this because without it I can't use Nextcloud Mail and so without it, a cloud platform that can't do email is much less useful.

From the discussion above it sounds like bountysource is no longer a viable option. I contacted Nextcloud sales and although they thanked me for the offer of support they confirmed that they do not accept commissioned feature development.

They also mentioned specifically that this request is not a priority so there is a real risk of funding freelance development work which will not be accepted by the company and integrated into the product for various reasons. Unless I am missing something, it doesn't sound like there is any acceptable mechanisms in place for integrating new features with this funding model.

Maybe a viable option would be that a freelancer rather than patching the mail app itself develops the needed additions in form of another app that extends the functionality of the mail app.

Anyway, I think we need to keep nagging @ChristophWurst for directions.

Yes, it is a tragedy that e-mail encryption gets so little love, even from Nextcloud. Unencrypted email in my view is the most glaring security hole. Yes, I agree that for instance Telegram's security model leaves much to be desired, but normal unencrypted e-mail has no security model at all. It is basically as it was 50 years ago.

[vasyugan]

I'll try but I can't promise

@ChristophWurst Maybe, do you have time now to give us advice?

[vasyugan]

I'll try but I can't promise ✌️

Hey, @ChristophWurst I thought it was time to poke you again. At present, PGP support is broken, as the one standard, which is state of the art is not supported. If Nextcloud GmbH does not see this as a priority, it would be great if you could give us directions on what we have to to go 1) hire a third party to fix it 2) ensure that their additions are accepted by Nextcloud Does it make sense to go for a separate app that extends the mail app's functionality?

[ioogithub]

1. hire  a third party to fix it

I offered to fund it personally. Nextcloud sales said they would not accept this.

As recommended, I posting a freelancing ad, it got 0 replies.

2. ensure that their additions are accepted by Nextcloud

This seems to be the real problem with Nextcloud. I just saw an issue where a user found a verifiable bug, did a deep dive, coded and tested the solution. The fix was rejected because it was judged to be a bug that would not effect enough users... The reason given was that they do not have the resources to integrate the fix.

So Nextcloud rejects code solutions and also funding which they could use to integrate code solutions and improve the project.

I have to admit I do not understand how this model will lead to success.

[ChristophWurst]

@vasyugan I haven't forgotten. I'll get back to you soon.

[gpgmailencrypt]

To make it easier for a programmer here is a visual example how pgpmime works. If you need more information let me know pgpmime.pdf

[vasyugan]

@vasyugan I haven't forgotten. I'll get back to you soon.

Really sorry for all the nagging, but here is another friendly reminder...

[vasyugan]

@vasyugan I haven't forgotten. I'll get back to you soon.

@ChristophWurst Here is another reminder. Still friendly, but already a bit impatient... I would really like some advice in order to ensure that whatever the third party we would hire comes up with is not getting rejected by Nextcloud. Would it make sense to develop a separate PGP/MIME compatibility app that extends the functionality of the mail app, so as to insulate it from the main code?

[ChristophWurst]

To make it easier for a programmer here is a visual example how pgpmime works. If you need more information let me know pgpmime.pdf

Thanks a lot @gpgmailencrypt. The detail with Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; is very helpful, if that is set consistently by all clients then the detection of gpg/mime should be easier.

On this second thought it also looks like we don't even have to fix the limiter of embedded message rending in Mail for this specific feature. If That content-type and the protocol is detected, we can discard the first part and only show the application/octet-stream but as plain text. This should be possible to pick up by Mailvelope then.

Now to the more technical part. Right now most of the logic is located inside \OCA\Mail\Model\IMAPMessage::loadMessageBodies. Touching this can work but is dangerous, it's one of the remaining legacy parts of this app. New IMAP code is generally moved over to \OCA\Mail\IMAP\MessageMapper and loadMessageBodies should likely be migrated as well so the feature can get reliable unit and integration tests.

Right now the boundary part of the encrypted message is ignored, which is good. The main part of the message is however detected as attachment because \Horde_Mime_Part::isAttachment return true. There is handling for multipart/encrypted in that method but $this->parent is null.

With that information I'd say the actionable items are

• Refactor \OCA\Mail\Model\IMAPMessage::getPart into a new method of \OCA\Mail\IMAP\MessageMapper and unit test all the existing logic
• Find out why Horde's logic for attachments fails on those messages
• Extend the new method in the mapper so that it can cope with multipart/encrypted if Horde doesn't do it already when used correctly
• Send the encrypted part as plain text message to the front-end as if it were text
• Show a warning to the user if Mailvelope is not there but such a part is displayed, otherwise leave the rest to Mailvelope

[vasyugan]

To make it easier for a programmer here is a visual example how pgpmime works. If you need more information let me know pgpmime.pdf

Thanks a lot @gpgmailencrypt. The detail with Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; is very helpful, if that is set consistently by all clients then the detection of gpg/mime should be easier.

Since this is what the standard prescribes, this should be a given. Just checked messages generated by Thunderbird, Outlook (with the GPG OL extension) and by Protonmail. They all conform to the standard [...]

With that information I'd say the actionable items are

• Refactor \OCA\Mail\Model\IMAPMessage::getPart into a new method of \OCA\Mail\IMAP\MessageMapper and unit test all the existing logic

• Find out why Horde's logic for attachments fails on those messages

• Extend the new method in the mapper so that it can cope with multipart/encrypted if Horde doesn't do it already when used correctly

• Send the encrypted part as plain text message to the front-end as if it were text

• Show a warning to the user if Mailvelope is not there but such a part is displayed, otherwise leave the rest to Mailvelope

Thanks a lot @ChristophWurst , very helpful! For me as a layman, this all sounds like something that cannot realistically be implemented as a separate app, but something that requires patches to the mail app, which means that whoever takes on the task will have to interact with the core developers and if and when the patches are accepted will ultimately be outside of their control, it may hinge on factors such as the development roadmap, right? Would it make sense to take a two-pronged approach such as by forking the mail app and at the same time trying to reintegrate the changes into the upstream code?

[vasyugan]

1. hire  a third party to fix it

I offered to fund it personally. Nextcloud sales said they would not accept this.

As recommended, I posting a freelancing ad, it got 0 replies.

Where did you post it? @ioogithub

[ChristophWurst]

requires patches to the mail app, which means that whoever takes on the task will have to interact with the core developers and if and when the patches are accepted will ultimately be outside of their control, it may hinge on factors such as the development roadmap, right? Would it make sense to take a two-pronged approach such as by forking the mail app and at the same time trying to reintegrate the changes into the upstream code?

I do not have any objections with those changes in this app as long as all existing multi part handling works as before. So I'll happily accept any contribution that follows this rough plan that I proposed. What I would reject is patches that just make it work but without any kind of testing that helps us ensure the stability of existing features.

[vasyugan]

Thanks @ChristophWurst Unfortunately, since our partners are now saying that they are using Thunderbird, not only because of its working PGP/MIME support, we no longer have a grounds for raising the funds needed to pay for the development work. So I guess, unless someone else takes it up, this bug will remain unresolved.

[NoSubstitute]

@ChristophWurst - has this issue just been forgotten? Asking because I just used Mailvelope to successfully open and read an encrypted email sent from Mailvelope.

Sent it from my Gmail account to NC with Mailvelope installed in Chrome. Both webmail services opened in separate tabs in the same Chrome profile.

[vasyugan]

@ChristophWurst - has this issue just been forgotten? Asking because I just used Mailvelope to successfully open and read an encrypted email sent from Mailvelope.

Sent it from my Gmail account to NC with Mailvelope installed in Chrome. Both webmail services opened in separate tabs in the same Chrome profile.

I think someone has to pick it up @ChristophWurst has described the tasks in his comment.

[NoSubstitute]

For sure, but the problem description doesn't seem to be true anymore, or I am doing something wrong/right? I just used Mailvelope with NC Mail and it worked fine, no issues.

I created an encrypted email with Mailvelope (on Gmail) and sent it to my NC account. I opened the encrypted email with Mailvelope in NC mail, without issues.

[vasyugan]

For sure, but the problem description doesn't seem to be true anymore, or I am doing something wrong/right? I just used Mailvelope with NC Mail and it worked fine, no issues.

I created an encrypted email with Mailvelope (on Gmail) and sent it to my NC account. I opened the encrypted email with Mailvelope in NC mail, without issues.

That's because Mailvelope uses legacy inline PGP, rather than PGP/MIME. Try to open a message sent by e.g. Thunderbird or MS Outlook with the GPGOL add-on, and you will still see it fail. All full-fledged mail clients such as Thunderbird or Outlook with GpgOL use PGP/MIME. See this page for an explanation of the differences.

It is very unfortunate that among the two standards, Nextcloud Mail only supports the one which is outdated and deprecated.

[NoSubstitute]

Oh, it seems to be not only that. Recent version of Engimail with Interlink Email seems to not include who the recipient is. Meaning the info about which key is supposed to be used when decryption isn't included in the encrypted content, so the decrypting software has to guess!

With old Enigmail on old Thunderbird (still compatible with Enigmail) that means it has to ask for the password to all private keys in the attempt to decrypt the content, and until it works, it just asks for the password to the next key.

I thought that Old Enigmail on old Thunderbird would include info on which the recipient key is, and therefore be opened by Mailvelope, but that too doesn't include that information.

Only Mailvelope includes the recipient key info.

Mailvelope doesn't have the guessing feature, and instead just says no private key included and then does nothing.

This change of not including the recipient key breaks Mailvelope, regardless of email service (afaik, at least Gmail anc Nextcloud), and also "breaks" email client software like old Thunderbird and new Interlink (both using their respective version of Enigmail).

lol, and just now I found out why this is happening! It's a setting in gpg! throw-keyid - seems it can be used both with and without an s at the end (throw-keyids).

Disabling throw-keyid makes PGP-INLINE work great from other clients, readable by Mailvelop on NC Mail.

But I have now also verified that PGP/MIME doesn't work with NC Mail & Mailvelope, because NC Mail doesn't show a preview of the attachment. Just like @ChristophWurst said early on.

NC Mail doesn't display attachments/embedded content, and then Mailvelope has nothing to read.

So, it's bad, but it's not useless.

[vasyugan]

NC Mail doesn't display attachments/embedded content, and then Mailvelope has nothing to read.

Yes, it changes the disposition header on its own accord, something which Roundcube does not do, because on Roundcube PGP/MIME message can be read just fine. That obstructs interoperability with most "real" mail clients that support PGP and basically leaves only Mailvelop as the only client in broad usage that still uses inline PGP. Maybe that's not totally useless but very nearly, I have to say.

[NoSubstitute]

I meant that afaik all the '"real" mail clients' have the option of sending inline, and don't have to use PGP/MIME.

It's not that big of a hassle to tell those extremely few people who send PGP (/MIME) messages to please use inline when sending to you. There's probably even an address book setting where it can be set per recipient. At least if it is a "real" client. ;-)

[vasyugan]

I meant that afaik all the '"real" mail clients' have the option of sending inline, and don't have to use PGP/MIME.

Most of the users I support are non-technical people, they wouldn't even know what that means. You see, the reason why mail encryption is used to rarely is because it is such a hassle. In Signal, Matrix/Element etc, also throughout the web where almost everything is ssl protected now, encryption is totally transparent, the user doesn't have to do anything, it just works ™. By contrast, Mailvelope is such a horrible kludge, you use it only when you absolutely have to. Thunderbird allows you to use encryption by default with far less intervention (although the current implementation still leaves far too much to be desired, but things like determining which MIME format is going to be used is something the average joe almost certainly should not be bothered with.

It's not that big of a hassle to tell those extremely few people who send PGP (/MIME) messages to please use inline when sending to you. There's probably even an address book setting where it can be set per recipient. At least if it is a "real" client. ;-)

Using PGP/MIME is the more modern standard for a reason, it has significant security pluses: The entire message is getting encrypted in one blob, you don't see which and how many attachments there are. Crucially, the subject line can be encrypted. (You still cannot hide the sender and recipient addresses, though, so you can't reach the same level of security as with e.g. Signal), so, really, PGP Inline is obsolete and should be avoided whenever possible.

I don't have high hopes though, that there will be a time when email encryption is just common practice, unless we are going to have an overhauled protocol where encryption is build into the very core and is happening transparently without user intervention. I think email will eventually become obsolete and be replaced by messengers.