Test message with PGP signature
Confustion ondeck some ropes are amiss.
In some mail clients (Outlook?) this seems to lead to an empty message altogether, not even the signature block is displayed.
The copy I have in my sent folder on the Phone looks fine.
Looking at the sent email in Thunderbird though shows the same signature block as appears on the recipients side.
PRECONDITIONS:
PGP key pair is available (imported in Settings) and signing key selected for signatures in email account.
STEPS TO REPRODUCE:
Create a new message
Enable PGP signature
Type some Text
Send
EXPECTED RESULT:
Signature block is attached after message content
ACTUAL RESULT:
No message content, signature block only
ADDITIONAL INFORMATION:
Source of the recieved email (redacted):
Return-Path: <ADDRESS_REMOVED>
Delivered-To: ADDRESS_REMOVED
Received: from proxy02.mailserver_removed.name ([127.0.0.1])
by dovecot04.mailserver_removed (Dovecot) with LMTP id nN7RCI0BRV+DBAEAvlP5og
for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200
Received: from proxy02.mailserver_removed ([127.0.0.1])
by proxy02.mailserver_removed.name (Dovecot) with LMTP id 0i4fGw7/RF+MrAAAGFAyLg
; Tue, 25 Aug 2020 14:18:36 +0200
Received: from mailin05.mailserver_removed (unknown [IP_removed])
by proxy02.mailserver_removed (Postfix) with ESMTPS id 4BbShD5D2Mz11fH
for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200 (CEST)
Received: from mx03.mailserver_removed (mailin05.mailserver_removed [127.0.0.1])
by mailin05.mailserver_removed (Postfix) with ESMTPS id A601520E39
for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at mailserver_removed
Authentication-Results: mailin05.mailserver_removed (amavisd-new);
dkim=pass (2048-bit key) header.d=mailserver_removed
Received: from mout01.mailserver_removed (unknown [IP_removed])
by mx03.mailserver_removed (Postfix) with ESMTPS id 4BbShD2vbWz10vX
for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200 (CEST)
Authentication-Results: mx03.mailserver_removed; dmarc=pass (p=none dis=none) header.from=mailserver_removed
Authentication-Results: mx03.mailserver_removed;
dkim=pass (2048-bit key) header.d=mailserver_removed header.i=@mailserver_removed header.b=fg3HyHlv;
dkim-atps=neutral
Received: from submission (mailserver_removed [IP_removed])
by mout01.mailserver_removed (Postfix) with ESMTPS id 3538D16005F
for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailserver_removed; s=2017;
t=1598357916; bh=5wBTOBRr4KCwVuyOigPQDcSedhfL4+FS1HfUwautdvo=;
h=To:From:Subject:Date:From;
b=fg3HyHlvDsd2Sq318oex+bPrDIQ14VSup/hypgktJd2T8EaPJRqPbnQ0+EaHRBqkI
yeC8zhPsbG7Abe5lFcE5SvgXHxgJxlUHqR8y7ziL1VM/oUx9LIUFqMMgvN/PhBK8wq
D/0YLwCg58eyfc7/AUju4VqQCbwEhJCPvtW62F4xzBe9ZsXc4lH0Itw0kADGiHNUy3
ZAc3sKvLdJUv8kVlmj5skkLhIf4wzqhmy+hrWztIC5kOYoYfKYj95gQx7t3X5uODIf
NmV5zfw4IT2X45n8XwtdYVq/e7vDKq6oO5yBCz0EAskbj/NS3auBdZeop0lALD6ArZ
MGMrPhXSALP6g==
Received: from customer (localhost [127.0.0.1])
by submission (mailserver_removed) with ESMTPSA id 4BbShC5PCWz6tmc
for <ADDRESS_REMOVED>; Tue, 25 Aug 2020 14:18:35 +0200 (CEST)
X-Priority: 3
To: ADDRESS_REMOVED
From: <ADDRESS_REMOVED>
Subject: SFOS PGP signage test
Content-Type: multipart/signed; charset=utf-8; micalg=pgp-sha1;
protocol=application/pgp-signature;
boundary="[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]"
Date: Tue, 25 Aug 2020 12:18:32 +0000
Message-ID: <koegxu.qfmcuz.2xnt17-qmf@submission01.mailserver_removed>
MIME-Version: 1.0
This is a multipart message in Mime 1.0 format
--[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
VGVzdCBtZXNzYWdlIHdpdGggUEdQIHNpZ25hdHVyZS4NCkNvbmZ1c2lvbiBvbmRlY2sgc29tZSBy
b3BlcyBhcmUgYW1pc3MuIA==
--[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
iQIVAwUBX0UBmVMTC9O9P [...]
======== SIGNATURE BLOCK REMOVED ====
===========[...]=====================
--[)}<qmf:1550879736twUS21C2j3w4+GDoWIx/fQ==)}<]--
I don’t know, I’ll see next week when I investigate. I’m sorry I don’t have time during this end of week… I’m wondering if I’m not missing a crriage return before the second boundary. I’ve extensively tested with my mailer (Claw-mail) but not much with others. Maybe Claw-mail was more easy with faulty emails…
I’ve investigated a bit this morning this issue. Reading the RFC 2046, it is stated that:
The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that
does not end with a CRLF (line break).
So my first guess about a line break missing before the signature part boundary is wrong.
After that, I tried to reproduce without any success : ( I don’t have Outlook, but I can use Outlook Web App from work. Sending a signed message from my phone to my work email address is properly displayed. Looking at the same mail from Thunderbird is working also, and from GMail also. Then, I copied the content you attached to your report and looked at it from Claw-mail with success. Redirecting this (so I should receive it as is) to my work email address also is working fine when viewed from OutlookWebApp.
I’m sadly a bit stuck now. I try to guess what could be wrong, but have no clue… I’m not using IMAP on my phone so a signed message is not copied to the sent folder and I cannot see it from outside the phone. I’ll set up an IMAP account on the phone so I can try to reproduce the failure you reported with Thunderbird from the sent folder.
I can try to reproduce it using another client (Geary) as well as another address.
I don’t have Outlook either (fortunately!) and since the behaviour is the same for Thunderbird, I figure it’s probably not the client. What do you think?
Maybe it’s Enigmail eating up the text or even my mail provider (which supports PGP natively). I’ll investigate some more once I find the time.
I can also try to reproduce it but I’m afraid I don’t really know which steps you took (where did you set what and which client (+version) did you use to create the mail)?
I agree. With your report, I’m sure I’m doing something wrong when composing the email to be sent to the server, but I cannot figure out what…
Thanks, I guess the email pristine content you reported in the first post was coming from a Ctrl+U in Thunderbird where it’s not properly displayed ? If not, can you copy-paste the source code of the email in your sent folder in Thunderbird ? And from which client does this content you copy-pasted come from ? Maybe it could help to figure out what’s wrong…
You need to have a pair of public / private PGP keys associated to your email address and to have installed the jolla-email-crypto-gnupg package from default Jolla repositories.
Copy the private one to the phone and import with gpg2.
In the setting UI, go to your email account page and scroll to the bottom, you should see that you can choose to sign your emails with your key.
Compose a new email from this account on device, it should ask you your PGP passphrase before sending the email.
View your sent email with another client and check that the text is properly displayed and that the signature is attached and possibly checked if your public PGP key is available to your client.
For me this procedure is working with my provider (Free in France) and the sent email is properly displayed and checked on various clients. For @rozgwi it’s not the case and the content of the signature is displayed instead of the mail content.
So it turns out it’s in fact Enigmail. As soon as I disable the add-on, the text appears.
Very curious . Maybe it’s related to the rewrite for the integration in the upcoming Thunderbird 70.
Anyways I’m sorry to have sent you on a wild-goose chase. Should’ve tried with disabled plugins first thing.
I found the culprit in the crafted email from SFOS, in the declaration of the multipart of the email, the protocol is not escaped within quotes. This is confusing EnigMail.
Indeed the parameter protocol has a value with a tspecial character (here ‘/’) that impose to quote the value, as described in this RFC : https://tools.ietf.org/html/rfc2045#page-12
I’ll look now in QMF code where I’ve done the mistake and correct it.
I’m waiting for review, if accepted, I’ll update the version in SailfishOS accordingly.
It seems that it’s an issue from QMF itself that for some reasons I don’t know about was not treating the ‘/’ character as a protected character in parameter value that requires quoting.
The merge request will not be accepted upstream immediately, or at least, it is accepted but cannot pass the CI because now the CI is running with Qt6, and the project is not ready yet for Qt6. I’ve created merge requests to allow the migration and please the CI, but there are a lot and the review will take time, see https://codereview.qt-project.org/q/project:qt-labs%2Fmessagingframework+status:open
In between, I’ve proposed to simply apply the patch on the version in SailfishOS and @pvuorela accepted it last week. So it should be fine on device starting from the next version (>3.4.0).
Displaying empty in the email app? The fix was accepted in 2021, but I guess only for Qt6? If the block displayed one could copy/paste it into something to decode, now pgp is completely broken it seems, so no patchmanagerial approach to detect a block and offer decrypt option can even work (unless there is some other intentional filter on pgp-encrypted contentType?)
