Hi,
sajolida wrote (05 May 2015 11:31:24 GMT) :
> So here is a draft of the security advisory, please review and comment:
> https://tails.boum.org/blueprint/claws_mail_leaks_plaintext_to_imap/
Thanks!
> stores plaintext copies of all emails that are meant to be encrypted
> on the remote IMAP server
Perhaps instead "stores plaintext copies of all emails, including
those that are meant to be encrypted, on the remote IMAP server"?
> By default in Tails, drafts are not stored automatically on
> the server.
I find this part (and especially "automatically") a bit vague.
Perhaps instead mention what can lead to drafts being stored remotely?
I'm unsure.
> Unfortunately, we were not yet able to fix the problem automatically
> and everybody.
s/and everybody/and for everybody/
or
s/and everybody/for everybody/
perhaps?
> This would likely require to either modify Claws Mail or to migrate
> to a different application.
I think we can be bold and remove "likely" here. (Technically, we
could wrap claws-mail to fix existing configurations, but this won't
work for new configurations created with Claws Mail's wizard.)
Perhaps "Refer to the workarounds section" should be a link?
I would move the "Technical details" section to the end, or at least
to after the "Workarounds" one. Most users won't care, and it's
largely duplicating information that's in the introduction already.
> When sending an email through IMAP
I'd rather not spread an incorrect understanding of how email works.
Perhaps instead "When sending an email from an email account
configured to use IMAP"?
> It connects to the IMAP server and stores a plaintext copy of the email in the Queue folder on the server.
s/on the server/there/ to avoid a repetition? If you don't think
that's clear enough, keep it as-is.
> either manually, either by the autosaving feature
Perhaps s/either by/or/?
> Delete drafts
I find it confusing to see this section (that is only about cleaning
up *past* leaks, right?) mixed with other ones that are about
preventing *future* leaks. So either clarify what's the expected
result of this action (and what it is _not_), or expand it a little
bit to cover future leaks, e.g. by pointing to the next sections.
Also, this section is meant to be followed in all cases, regardless of
the strategy chosen below, right? I think this should be made clearer,
otherwise some users may erroneously believe that they have to pick
among 4 options, one being "Delete drafts".
> or, better, through the web interface of your email provider.
I don't know why it would be better. I think I'd simply remove this
2nd option.
s/gEdit/gedit/ (that's how it's called on the upstream website, in
the application itself, and everywhere else in our doc).
> Use the OpenPGP Applet
I have two concerns with this section:
1. The "Use local Drafts and Queue folders" option seems vastly better
than this one in all aspects I can think of. So:
* why do we document the OpenPGP Applet option at all?
* why do we document it _before_ the local folders one? (I bet
most users will just pick the first option that seems to apply
to their use case.)
2. I'm a little bit wary of recommending usage of PGP/inline.
Were these instructions tested with messages whose cleartext body
contains non-us-ascii chars? I suspect such messages won't be
correctly displayed, once decrypted, by a number of email clients,
due to the lack of encoding charset information.
> As for the possible long term solutions to this problem, we are considering:
>
> * Getting the development team of Claws Mail to fix the problem
> upstream and release a security update for Debian
There's a problem with this sentence: the way "release" is conjugated
here, I understand that we want to get Claws Mail developers to
release a security update for Debian, which is of course not the case.
Perhaps s/release/releasing/ so that it's clearer that "we are
considering [...] releasing a security [...]"?
> We contacted them about this problem already but please help them
> provide a technical solution if you can.
I don't like "but" here. Perhaps s/already but please/already.
Please/?
Awesome work, congrats!
Cheers,
--
intrigeri
