Mail: 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 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.

[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.