sajolida wrote (07 May 2015 13:03:23 GMT) :
> intrigeri:
>> 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.
> Yes, when I first wrote it the introduction was not as good as it is
> right now.
> So I won't put a link on "workaround section" as it would jump to the
> section that's right below and most likely already visible. I personally
> don't like so much when I jump around a page for little reason.
Absolutely.
> What about "When sending an email from an IMAP account" then? It's a bit
> less convoluted?
Great.
>>> 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".
> I tried to improve on this.
Good.
>>> 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.
> I remove the "better". I'll keep this as an option because it's what I
> would do myself: as Claws Mail is known to do fishy stuff with my draft
> folder, I would go to the web mail to check what's actually in there.
OK... I see your level of distrust wrt. Claws Mail has reached "I
don't believe it properly shows me the content of a remote IMAP
folder". I can emphatize with this feeling, especially after all the
work you've put into it. Still, I'm not aware of actual facts that
back up this feeling enough to justify making this doc longer than it
needs. Anyway, I'll stop insisting now, no big deal, I can totally
live with the current situation :)
>>> Use the OpenPGP Applet
> [...]
> I also end up with *three* of each folder on my
> screen when doing that on Riseup (see screenshot for both
> tails@??? and tails-dev@???) but only two on pimienta.org.
> Maybe there's something wrong on Riseup.
I think that's the result of a email client misconfiguration wrt.
remote IMAP folders prefixing, that lead to create duplicate folders
remotely. Perhaps that's been done in the past by another of us,
perhaps you did it yourself when trying out all possible kinds of
Claws Mail configuration. Some clients guess what's the remote folder
name prefix (e.g. 'INBOX.') and hide it, some other clients don't try
to be that clever.
> But now I removed it.
Good.
>> 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.
> I tested it, and here are the results:
> - The received message opens well in Claws Mail.
> - The received message opens well in the applet.
> - The received message doesn't open well in Icedove.
I can't say I'm surprised.
> But how is this different from what we are already documenting on
> https://tails.boum.org/doc/encryption_and_privacy/gpgapplet/public-key_cryptography.html?
That's not intrisically different. However:
* our current doc for OpenPGP applet is aimed at webmail users, who
can't do PGP/MIME anyway
* the fact we document suboptimal practices for contexts that don't
support anything better is no good reason to extend such
recommandations to contexts that do support PGP/MIME :)
> Because we might have to mention something on this page...
Yep.
> I pushed my work into doc/9161-claws-advisory. Please have a second look
> if you want.
Done, looks good, great job!
Before publishing, you'll want to check that the attached images don't
show up in the Atom/RSS feeds.
Cheers,
--
intrigeri
