[nemo-qml-plugin-email] Expose encryption status.

[dcaliste]

It's based on https://codereview.qt-project.org/c/qt-labs/messagingframework/+/499122

@pvuorela , the main idea is not for the moment to bring decryption capabilities, but to let the power users to do something with encrypted emails, and also to mention to normal users that the email content is not displayed because of encryption.

Indeed, currently, an encrypted email simply display a blank page, without any information. With the current PR, the encryption status is exposed to QML and the application can be tuned accordingly.

Later on, the EncryptionStatus can be expanded a bit when decryption capabilities will be added to QMF, mentioning potential issues on decryption… That's why I didn't made it a boolean.

[pvuorela]

Appears sensical, though requires first the qmf changes going in. Though as disclaimer because of that and lacking an email encryption setup, haven't actually tested.

[dcaliste]

Thanks for the review. As soon as you agree on the QMF PR, I'll create a corresponding here, updating upstream target.

I can mail you an encrypted email if you have a GnuPG public key.

[pvuorela]

Started checking at some point the gpg setup, but now actually you could just send me email encrypted with any key since decrypting on the email app would need more enablers, right?

[dcaliste]

Hello ! Sure, I've just sent you an encrypted email, using my own public key to cypher it.

[pvuorela]

Hmh, got the email but it doesn't seem to be returning the isEncrypted status. Not 100% sure did i have messageserver restarted with your recent changes when the email was received, but at least forwarding the email to myself didn't work any better.

[dcaliste]

Ah, strange. Let's investigate a bit. The message should contain something like:

MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="Encrypt_/jQW0bSfVj/f+vjjeANLxd7Z";
 protocol="application/pgp-encrypted"

--Encrypt_/jQW0bSfVj/f+vjjeANLxd7Z
Content-Type: application/pgp-encrypted

Version: 1

--Encrypt_/jQW0bSfVj/f+vjjeANLxd7Z
Content-Type: application/octet-stream

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

hQEMA6tM5gigmVObAQgAiKmt0nrBk4Vj8ZNs9u/7G+NhI+OhZlMwcREh+psnBgAM
QTCJDMXy/KntYVsDzBhxEim67b85pqb6jLtEdn7EhwbuJjaA//UjKO/PUBw6hQxx
brNF5zpppWwuC+nmwvGry6kfubL3xiPeFD2z2nuEwQPN5VOACZpY7Y+ilf+FJgy8
iUbb0v3VpFabLnLBm87GyjINC+iLGU0MxsMjqrikEcQ4HNbDKY2bGYxDxIMhQAyO
62R0Ue8Wrq3RZCD/NOS1UG7M8ulOQ2S4XDXz7b5XM4EMB/IzfznE+1y+A8H5Uk/I
KSqkSpZ5E2+GX4uboJurRd3MEnCHjKv1xhfrSu6sLNKyARIvStaiF6C1KjLeQiuB
BY5DOBsHlK5fPOt80yUn9a5QpQX+k+GrTffFq8QMtl8YiVnw86sGRuFLPaYlQo5m
QaWyq0al5st3ted/IBCWKJkzlGzykh6lm2xIOTAPPoyhNeYXj80Jq+IkMGU8/SFN
BDjGaPDAPSjD9U791UU5kKhDPhAJqrT1KU2Ao8eCGimAAkvz/tN9afR+hay8HuGk
XtPhW/9JJSN/QXuNCo+XsSijJw==
=STA7
-----END PGP MESSAGE-----

--Encrypt_/jQW0bSfVj/f+vjjeANLxd7Z--

Looking in ~/.qmf/mail/xxxxx, you should see a skeleton like the one above. Then, there are two things:

1. the message server should have been restarted to properly set the metadata of the email in the database, so the email can be flagged in the email list view,
2. without restarting the message server, the email view page should display a banner mentioning the encryption, even if the mail was not flagged, because it is based on testing the multipart type.

Which brings me to your second try : forwarding the email and not redirecting it may have altered the multipart layout. To be flagged as an encrypted email, the top multipart type must be multipart/encrypted. This may be disvussed further if encrypted attachment can be supported but currently in QMF it's not the case.

All that being said, I'm going to test the exact setup here : recompile the sailfish OS QMF package, install it and restart the message server, compile and install the current PR and the corresponding one in jolla-email. I'll tell you if I have an issue.

[dcaliste]

Ok, having recompiled QMF master branch, this PR and the one in jolla-email, having installed all generated packages and finally restarted the messageserver, sending the same encrypted email to myself properly displays the little lock in the email list view and the banner in the email view page, with the possibility to click on the encrypted part to download it. At least with a POP3 account...

Testing with an IMAP4, there is indeed an issue. The banner in the email is properly displayed, but the email in not flagged as encrypted in the list view. Investigating...

[dcaliste]

Ok, I forgot to set the flag for IMAP protocol. See https://codereview.qt-project.org/c/qt-labs/messagingframework/+/505574

If you agree, I'll propagate this commit to the QMF repo here.

[pvuorela]

Mm, right. Didn't expect this to be protocol specific but indeed there are some parts like that. Seems like the EAS, which jolla.com btw is using, is also doing some HasAttachments flags etc so could be that it needs to be adapted separately.

[dcaliste]

I pushed the QMF PR adding these missing bits for the IMAP protocol: sailfishos/messagingframework#8

If there is a hasAttachments() test in EAS plugin, there are good chances that it requires to add the isEncrypted() test also.

[pvuorela]

With the updated messagingframework and these PRs I'm getting the encryption status nicely on gmail. Created myself some encryption keys to test.

As expected, Exchange didn't yet work. The place where to add the status flag wasn't as clear as I first thought. But now again wondering why was this a separate flag instead of just using the isEncrypted() on QMailMessage?

[dcaliste]

We need the encryption flag if we want to get an icon in the message list. In that case, we don't have access to QMailMessage objects, but just the metadata of a list of them.

Of course, we can decide not to have any icon in email listings…

[dcaliste]

About the place where to add a isEncrypted() test in EAS, looking for where the attachment flag is set can be helpfull also. In IMAP, for instance, the flag is set with the following code:

message->setStatus( QMailMessage::HasAttachments, true );

And about the icons in mail listing, for reference, we currently set one for:

• attachment in general,
• calendar invitation / cancellation…
• digital signatures.

[pvuorela]

The message list is a good point and sounds like a place where it's good to have. Thanks for the explanation.

I'll try to figure out the EAS side a bit more.

[pvuorela]

For status update on these EAS investigations, been trying to sprinkle some enabling of the encryption flag on places that seemed good and debug outputs on how EAS interprets the emails. So far none are returning status properly on isEncrypted(). Best candidate seems multipart type mixed and part count of three(?).

I'm guessing EAS could need some extra detection for setting the MultipartEncrypted type, which is not done now. For comparison messagingframework / imapstructure.cpp is doing some enum mapping. Dunno if such type info is available on EAS to begin with. I'm also guessing the current mixed type is coming from calling QMailMessagePartContainer::setAttachments() which is doing some type adjustments.

So all in all doesn't appear to be that straightforward. Taking a step back pondering if EAS + PGP/GPG encryption is a combination that needs supporting, seems like generally EAS is supporting S/MIME and "Microsoft 365 Message Encryption". No idea how they would look like in received data. So not sure if a good idea but one option could be just to acknowledge that the encryption status is detected correctly on other protocols.

[dcaliste]

Ok, I've no idea indeed how EAS is working. Like IMAP, is it a kind of transport protocol but at the end you can create RFC2822 compatible emails from sended pieces ? Indeed IMAP is doing something like that with its "structure" string that allows to create skeleton email where one can later on retrieve the contain of each part of the skeleton. Nicely enough with IMAP, the skeleton is enough to set the Multipart::Encrypted MIME type. So it's easy to know where to set the flag.

Another approach for EAS, would be to look where the email is saved to the storage. Indeed, at the end, it is generating an RFC2822 compliant QMailMessage that can be saved in the storage. Because, I guess that sending a standard MultiPart::Encrypted email to a Microsoft server can be fetched later on. It's up to the client to decrypt, so maybe Outlook is not supporting GnuPG cases, but a SailfishOS client may…

So far none are returning status properly on isEncrypted(). Best candidate seems multipart type mixed and part count of three(?).

Do you mean that if I send a MultiPart::Encrypted email with the RFC compliant two parts, one with the version and one with the encrypted content, to a Microsoft email server, I'm going to get on a client through EAS protocol a MultiPart::Mixed email with three parts ? That sounds bad :/ Or is it the plugin interpretation of the received data that is not recreating a proper RFC2822 email ? Maybe the later, in that case, adding support for encrytion with EAS protocol may require a larger work indeed. And maybe not worth it…

[pvuorela]

So there's (WB)XML gotten from the server with something like this:

<Sync> / <Collection> / <Commands> / <Add> / <ApplicationData> basic structure
<To> & <From> & <Subject> etc metadata of the email, and...
            <Attachments>
              <Attachment>
                <DisplayName>PGP/MIME version identification</DisplayName>
                <FileReference>np3iyeutFEmiLhNmK2sHwwAAAAABDJ6d4snrrRRJoi4TZitrB8MAAxrHb441%3a0</FileReference>
                <Method>1</Method>
                <EstimatedDataSize>392</EstimatedDataSize>
              </Attachment>
              <Attachment>
                <DisplayName>OpenPGP encrypted message.asc</DisplayName>
                <FileReference>np3iyeutFEmiLhNmK2sHwwAAAAABDJ6d4snrrRRJoi4TZitrB8MAAxrHb441%3a1</FileReference>
                <Method>1</Method>
                <EstimatedDataSize>7437</EstimatedDataSize>
              </Attachment>
            </Attachments>
            <Body>
              <Type>1</Type>
              <EstimatedDataSize>0</EstimatedDataSize>
            </Body>
// ...and some more metadata

The sync code then handles that, for example calling QMailMessagePartContainer::setAttachments() with the attachment properties received. No encryption properties nor RFC2822 here. There is, however, some code to handle latter with QMailMessage::fromRfc2822() on body data, but what we get is plain text (type 1). Not sure would the server return different type if requested, but i'm not too eager going that way just to get unsupported encryption flag on.

[dcaliste]

I see, the MIME description of the email is completely lost, and even the metadata associated to the parts themselves (it's missing the most important content-type for instance). So definitely, except playing some heuristics here on fragile data like the DisplayName (???), there is no clean solution.

i'm not too eager going that way just to get unsupported encryption flag on.

I concour to this conclusion. EAS transport layer should just be left unsupported.

[pvuorela]

Alright. Let's have the status flag done for eas separately, if ever. Unclear how many accounts would have external GPG style encryption enabled anyway to receive such content.