This is a question:Why K9 can open an encrypted email in sent folder?

[ironox]

Please search to check for an existing issue (including closed issues, for which the fix may not have yet been released) before opening a new issue: https://github.com/k9mail/k-9/issues?q=is%3Aissue

Expected behavior

Because we have to encrypt the message with the recipient's public key, we should not be able to open the encrypted message sent.

Actual behavior

K9 can open a email encrypted by PGP in sent folder.

Steps to reproduce

1.send an email encrypted by PGP to someone 2.open the email in sent folder

Environment

K-9 Mail version: K-9 version 5.70 commit 262e0840ba131f6c0fdcd220a282184aa92ac7d6

Android version: Android 8.1.0 Account type (IMAP, POP3, WebDAV/Exchange): IMAP

Please take some time to retrieve logs and attach them here:

[d-g]

Aaron notifications@github.com wrote:

Expected behavior

Because we have to encrypt the message with the recipient's public key [only], we should not be able to open the encrypted message sent.

May I ask, who impose on you such a constraint and how he explained such a weird demand?

Normally expected behaviour is, of course, to encrypt both to recipient and to sender. So is for me.

Sure, it has some anonymity-related downsides, but they are so marginal (or I am mistaken?), so I bet no one would care to implement such an option in K-9, until lacks of much more basic features of a decent MUA will be filled.

[ironox]

Aaron notifications@github.com wrote:

Expected behavior Because we have to encrypt the message with the recipient's public key [only], we should not be able to open the encrypted message sent.

May I ask, who impose on you such a constraint and how he explained such a weird demand? Normally expected behaviour is, of course, to encrypt both to recipient and to sender. So is for me. Sure, it has some anonymity-related downsides, but they are so marginal (or I am mistaken?), so I bet no one would care to implement such an option in K-9, until lacks of much more basic features of a decent MUA will be filled.

Hi, d-g, Thank you for your patience。 No one has imposed this constraint on me. I am all based on my own poor knowledge.

so my real question is how K9 implements this feature?

if K9 encrypt email both to recipient and to sender, there should be two encrypted emails. one for the sender, the other for the recipient. but I can see only one encrypted email for both in source code(I don't know if I am wrong again:).)

[d-g]

Aaron wrote:

so my real question is how K9 implements this feature?

(N. B. I am not sure about K-9’s developers views of this, but typically bugtrackers are intended for actual bugreports, not for the questions. K-9’s users mailing list is k-9-mail@googlegroups.com — feel free to join.

Not to mention, that using bugtrackers on github.com as substitutes for ML is pain.)

so my real question is how K9 implements this feature?

Anyway, I did not read it, but I believe, that exactly as any other MUA does: it requests a PGP agent (in our case — openkeychain) to encrypt a mail to all recipients and to sender. :-)

if K9 encrypt email both to recipient and to sender

Don’t wait for answers — investigate. Write a mail with K-9:

--8<---------------cut here---------------start------------->8--- Date: Thu, 11 Apr 2019 02:11:36 +0300 From: Dmitry Alexandrov 321942@gmail.com To: Aaron Chen ironox@gmail.com Subject: Test PGP User-Agent: K-9 Mail for Android Message-ID: B94AB0E9-D2E5-405D-A5B3-DFEBA46F1ACF@gmail.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/encrypted; boundary="----ZNSOEVA0MKIH9PW3S8X9ZV4Y0AECQ6"; protocol="application/pgp-encrypted"

------ZNSOEVA0MKIH9PW3S8X9ZV4Y0AECQ6 Content-Type: application/pgp-encrypted Content-Transfer-Encoding: quoted-printable

Version: 1 ------ZNSOEVA0MKIH9PW3S8X9ZV4Y0AECQ6 Content-Type: application/octet-stream; name="encrypted.asc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="encrypted.asc"

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

hQIMA/0AtwTvniNRAQ/+NHtt5Qe5g/rIyn123f5CyOCv6f9ySVGnWTV/7J5Hl8DR 9vxDK3V5Uw332x4vavuvAvAgw49Rx3kalMC7I8QKtIUwTljFXZZlKU42BeX4dZR6 sbAQTKuE4fmB5HXmM4dXOu09YDeiupyp/Di1b5++FRYDbyG3vOzr0gNbcFIqqRhq jno/u7PdalL6UzOKfamKZ4iuwzl/tGBeum418DsOF3tk97q6W6V7aYAEFUpnjueH XDwxSxpxR+9wyziM0YrrPWrsb7ERup4DVk61zW0NdzSJtzTfzvz74C5gSqPeew5D kv3hrdqAdg3XHvM4N+unm25f5ivfRF/jSzIMwXPpCsyhNPg+nJ7SILmXt/47sMqT 9IEsRQlUA50SJLNEXiQTcy1ttNyyrHlrjpuR291KYClGb6FO+PaDPO9cJnYbMwcU CZIuBPRvw329EXm6iG7RfilLhGVo6BOdjLHFrKluZ1PdcSlHiSdfnKl7eLwQtacP uVTPYdVeqDkZllO4/tGeFF7oXaQYnB8gLghLmZ3/isVOfcJWU1si5h10nCWhJeFc SEG49nHhDjQGaA7CCD+e56VGRLvnYDSQo87dtyr5w0c/A6hPI0Marq6mlPEsVXTc YwxLsIgpfHF2HkBP7wn1jjaQ9TWxsjPwC7NmVzsqw4PzoHTd8tPZ6zeZHQwI8eOF AQwDURksFJEK4JEBB/9Z/WxAxR85b/9d7JJ3elWdv77Qxdy1O6WLFnbDTeJimFH0 PU1U1Sv+ODgJPb/Nozvj88oNS3JdtHrgM1JSWI/BkR2TXPgioLbsty/3A2dVAWWM yDmObIrm2igKvtJYrRCaVv4BCNogKVnUavcQfgAk1mB3vcbmki/v3rA5QiKjxg0K 0Wn0Zf+v6fBOr7TZJvy0p6lxtbc9K6SN0WwysBMLP36yq3UXtBc0jxmvqwQ9ybea a41XcB6lmP4S5RpkimwmrcMIDSzN94/AU2ZZRK8L5hOXoNl+PzB0R3oAdiHBak3s VqiBahnINDZgHezLF2fdNl5W+PdpWsMFQoaG4T/n0sEtAUvGnIRZSqwhzXP6KSfB JURrCkQSmD1pIkvfdI0UmZ3EPUCgRJ2AeGPf66QnvNhud3fGqbNfxg8EvsJNizeq RWUtpvpJs5ulJ2jFjcRz9XrYAJt+hchNunSBTQFYs/WJq1D1HcGxOmqH18olMFZ5 xwmjMmVbNjfAhGqKSddls9s+xdkWjvy2WnIkjzy5AuLDDz7UEaKCkgVKqRhv2R6Q UxwMKxoscvsGmr/5fCcrd45JSGAq12OFyGSMEtAWAB95zhCqB7OHcnMavqzvsiKK Wkf/wv+TwmHrvvQl8+/IVWBFJe05imZKx2YS6aj/6tX3DHbypD71DBP+1P2Jog69 sfzOi8glPj9Trr15vC8I+FMSUEMVx8MeJUtXq9Spduq0/nS+Ukxn/NCO8JFgW0jV I9e5qMzn/nLjG6MmBqD+ygpOA8wyChSb1hwOupqENFcEzXaTnW5CBQgsk8Sk5lus ZvBBc07kC0ph815+DQOm8XjHuW3gXp2lW0JEPieBjhQTHuZ2x2hs3RG9nf2OG6lC lcYKHsM1+vglWNCYlsO3ZZp42+pwt95LkAtgx/hm1Sfp7RCyLtGdFrWYlL6nFVTv oHJuUx1KTR0FI5MBB/b54W7pvotuZgsr2nY8OvEmPdqEcfdaRmUBh2kJmJkZ2A== =RF0+ -----END PGP MESSAGE-----

------ZNSOEVA0MKIH9PW3S8X9ZV4Y0AECQ6-- --8<---------------cut here---------------end--------------->8---

and feed it to GPG to see it yourself:

--8<---------------cut here---------------start------------->8--- $ gpg -v -o /dev/null pgp-encrypted.example.eml gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: public key is FD00B704EF9E2351 gpg: public key is 51192C14910AE091 gpg: using subkey 51192C14910AE091 instead of primary key C9DA09DE19C1B230 gpg: using subkey FD00B704EF9E2351 instead of primary key 0FC5B1878F11B1C0 gpg: encrypted with 4096-bit RSA key, ID FD00B704EF9E2351, created 2018-10-18 "Aaron Chen ironox@gmail.com" gpg: using subkey 51192C14910AE091 instead of primary key C9DA09DE19C1B230 gpg: encrypted with 2048-bit RSA key, ID 51192C14910AE091, created 2016-10-03 "Dmitry Alexandrov 321942@gmail.com" gpg: AES256 encrypted data gpg: original file name='' gpg: Signature made Thu 11 Apr 2019 02:11:37 MSK gpg: using RSA key C9DA09DE19C1B230 gpg: issuer "Dmitry Alexandrov 321942@gmail.com" gpg: using pgp trust model gpg: Good signature from "Dmitry Alexandrov 321942@gmail.com" [ultimate] gpg: binary signature, digest algorithm SHA512, key algorithm rsa2048 --8<---------------cut here---------------end--------------->8---

there should be two encrypted emails. one for the sender, the other for the recipient.

Who said you that? A ciphertext does not even need to be twice as large as when encrypted to single person, cf. The GNU Privacy Handbook / Concepts [0] (when reading other sections, keep in mind that is was written 20 years ago).

[0] https://gnupg.org/gph/en/manual.html#CONCEPTS

[cketti]

Please use the mailing list for support requests.