Hi Mike, thanks for a long and detailed mail with plenty of valuable
suggestions. I have a couple of comments and questions to some of them.
1.) Support both PGP/MIME and also Inline PGP for both incoming
and outgoing mail
It's 2013 already. The specification for PGP/MIME has been around since
1996 (RFC 2015, since updated by 3156). What is the reason on why would
anyone bother with inline signatures today?
I've read some random blog posts about Outlook Express not displaying these
messages at all. Frankly, the same happens when one sends a mail with an
unrecognized X.509 certificate. Users normally work around this brokeness
by not encrypting messages going to such recipients at all. I'm not
convinced that supporting the inline hack is worth any effort.
It might be interesting to produce the messages like this, however:
1 multipart/alternative
1.1 text/plain for outlook
1.2 multipart/signed
1.2.1 text/plain
1.2.2 the signature
Do you happen to know whether this works? Is the state of "work/doesn't
work in OE" depending on the order of 1.1 and 1.2? What's the OE's market
share today, i.e. do we have to cater for it at all?
3.) When composing a message, if a Draft is going to be saved
in an IMAP folder.
Note that Trojita does not support drafts stored in an IMAP folder yet :).
4.) When sending an email to somebody who doesn't have a PGP key, we
can't
encrypt. This is less than ideal, from a privacy perspective.
However,
that doesn't mean we also have to save the "Sent Items" version
unencrypted. An option to encrypt anything that gets added to the
"Sent Items" folder with the users own public key, would be great.
This unfortunately completely breaks any efficient sending method like
BURL.
5.) An option for making Trojita automatically and transparently replace
any unencrypted email on the server with an encrypted version.
I don't think this is a job for a MUA. If you do not trust your IMAP
server, an after-fact opportunistic encryption wouldn't help you anyway.
Even if you are willing to accept that risk, I would suggest simply running
a separate agent responsible for this transformation. You might want to
write one based on Trojita, sure.
Also keep in mind that this approach has rather wide ranging implications
on efficiency, in particular on any server-side operation. Trojita relies
on these a lot, and will happily use them more in future. You might or
might not get some increased level of security, but you'll definitely get a
slowdown in the speed of operation, pay the price of higher latency and
consumer more bandwidth. I'm sure you know this, but it's good to make sure
people are aware of the drawbacks before they jump into the "let's encrypt
everything" stage.
9.) A warning if we try to send an unencrypted email in response to an
encrypted email. And *also* a warning if we receive an unencrypted
email
that was in reply to an encrypted email, so we notice if
some information
we didn't expect to be leaked was leaked.
Now this is clearly interesting from the user's point of view. However, how
do you propose to track this relation, technically? Where shall Trojita
keep the mapping about mails and responses to them? I'm of course aware of
Message-Id/In-Reply-To/References, but this index maintenance cannot be
offloaded to the server anymore (you don't trust it after all), which means
a TON of transferred data.
10.) Don't restrict encrypting ability to the UIDs in the key. For
example
this email will be sent from troj...@lists.grepular.com, but will be
signed using a key which doesn't have a troj...@lists.grepular.com
UID
I was under impression that the signer identity is checked against the From
header, not against the actual sender. Note that the ML messages are From:
you, not From: trojita-ml, so there is no issue here AFAIK.
12.) If there is a photo attached to a public key, display it within the
trojita GUI, along with the message.
Plenty of arguments against this on the net center around an argument that
this feature provides a false sense of security. I don't have much of an
opinion here.
13.) Take advantage of PKA records. For example, you can automatically
look
up what the corresponding PGP key for my personal email
address is without
talking to any key servers:
How is this supposed to be integrated with DNSSEC? How do I validate the
DNSSEC responses from a Qt application?
14.) Support PGP at any layer of MIME depth. For example, you might have
an ascii armored inline pgp signed message that is an attachment
within a PGP/MIME encrypted email. You might also have a single part
email which contains some unencrypted and unsigned text, followed by
some ascii armored signed or encrypted text, followed by some other
non encrypted/signed text.
You will actually get this one for free due to the way how Trojita's MIME
rendering works.
(Note that real support for signing/encryption will require a client-side
MIME parser. There's no such thing in Trojita yet.)
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
