mailing list archives

Hi,
I would like to propose a new IMAP keyword "$LoadExternals". When this 
keyword is set on a given message, MUA can safely assume that it can go 
ahead and automatically fetch external entities linked from any part of the 
concerned message.

Rationale -- when displaying HTML content, a reasonable MUA doesn't blidnly 
dereference URLs which point to a location that might be under the control 
of a third party (typical use case: external images or CSS). This is done 
for privacy reasons so that we don't leak information about the recipient 
by accident. However, once a request to a given external URL has been made, 
the privacy issue doesn't matter anymore (the information has leaked 
already). It is therefore typically safe to make this per-message setting 
permanent, and to do so in a manner which is interoperable across different 
MUAs.

The proposed mode of operation is the following:

- When $LoadExternals is not set, show an appropriate notification in a 
non-obtrusive manner, possibly listing the locations to fetch data from. Do 
*not* fetch remote content.
- When $LoadExternals is set, do not block requests to remote content. Show 
an appropriate non-obtrusive notification about this state and allow the 
user to uncheck this whitelisting.
- Server-side filtering scripts are allowed to set $LoadExternals based on 
implementation-defined heuristic or policy (such as using site-wide 
statistics about URLs and the likelihood of them being useful for tracking, 
or auto-whitelisting internal domains, etc).

Are there any other MUAs besides Trojita interested in this?

Is the $LoadExternals acceptable? I don't care about a particular name, but 
I think that avoiding needlessly long strings is reasonable. Suggestions 
are welcome.

Once we have some consensus about the need for this, I'll be happy to write 
a formal draft.

With kind regards,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Hi Jan,

> This is done
> for privacy reasons so that we don't leak information about the recipient
> by accident. However, once a request to a given external URL has been made,
> the privacy issue doesn't matter anymore (the information has leaked
> already). It is therefore typically safe to make this per-message setting
> permanent

Additional requests may leak additional information. Examples:

* I've viewed an offer letter 10 times and thus may be interested enough to be squeezed for more money.
* I was paging through last week's email to find something and my MUA downloads external images from "politically-sensitive-topic.org" while I'm now travelling overseas in a country where that topic is illegal.
* I allowed downloading linked images from my desktop MUA and now my other devices respect that setting, exposing information on the complete set of MUA software I use and the region I'm currently in.

-Neil

On Saturday, 16 May 2015 01:18:56 CEST, Neil Hunsperger wrote:
> * I've viewed an offer letter 10 times and thus may be 
> interested enough to be squeezed for more money.
> * I was paging through last week's email to find something and 
> my MUA downloads external images from 
> "politically-sensitive-topic.org" while I'm now travelling 
> overseas in a country where that topic is illegal.
> * I allowed downloading linked images from my desktop MUA and 
> now my other devices respect that setting, exposing information 
> on the complete set of MUA software I use and the region I'm 
> currently in.

Yes, these are all possible scenarios; I was simplifying stuff a bit. In 
spite of these, I think that there is some merit in having an opt-in basis 
for making this per-message settings permanent, and making this work across 
different MUAs sounds reasonable to me.

Trojita is periodically getting requests for making it load everything 
automatically. We are not going to do that, and we're also still opposing 
even a settings option for users to opt-in into that very insecure 
behavior. I hope that remembering these settings on a per-message basis is 
a reasonable middle ground.

The alternative to that is implementing this feature with a MUA-specific 
flag, which sounds like a worst scenario to me.

Are some other client developers interested in this?

With kind regards,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

On Wed, May 20, 2015 at 8:47 AM, Jan Kundr?t <jkt@flaska.net> wrote:

> Are some other client developers interested in this?


It seems reasonable to me to standardize a flag for this purpose, even if
many clients prefer to keep the setting local-only.  Thunderbird uses a
per-message "remoteContentPolicy" property that is persisted locally in the
msf files but never persisted to IMAP servers.  Once set, it allows
external images for the specific messages to be fetched going forward.
 (Some information leakage will be suppressed on repeated viewings because
of the network cache, but the images/etc. are likely to be rotated out.)

Note: I no longer actively contribute to Thunderbird, so if anyone is going
to change things to use the flag it won't be me.  I work on the Firefox OS
email app, and we currently have no plans to persist "show extenal images"
on a per message basis, but if we did, we would use the proposed flag since
we would synchronize the flag to the server when possible.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150520/a81581fd/attachment.html>

On Wed, May 20, 2015 at 12:07 PM, Andrew Sutherland <asuth@mozilla.com>
wrote:

> On Wed, May 20, 2015 at 8:47 AM, Jan Kundr?t <jkt@flaska.net> wrote:
>
>> Are some other client developers interested in this?
>
>
> It seems reasonable to me to standardize a flag for this purpose, even if
> many clients prefer to keep the setting local-only.  Thunderbird uses a
> per-message "remoteContentPolicy" property that is persisted locally in the
> msf files but never persisted to IMAP servers.  Once set, it allows
> external images for the specific messages to be fetched going forward.
>  (Some information leakage will be suppressed on repeated viewings because
> of the network cache, but the images/etc. are likely to be rotated out.)
>
> Note: I no longer actively contribute to Thunderbird, so if anyone is
> going to change things to use the flag it won't be me.  I work on the
> Firefox OS email app, and we currently have no plans to persist "show
> extenal images" on a per message basis, but if we did, we would use the
> proposed flag since we would synchronize the flag to the server when
> possible.
>

I think we persist per sender, not per message... and we know proxy most of
that stuff, so I think a lot of users just show all messages... or we have
some complicated logic about when it's ok to show and when it's not which
is calculated on the fly and not exposed.

Not opposed to a standard, of course, just seems unlikely we'll use it.

Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150520/e6c1af94/attachment.html>

On 5/20/2015 2:29 PM, Brandon Long wrote:
>
>
> On Wed, May 20, 2015 at 12:07 PM, Andrew Sutherland <asuth@mozilla.com 
> <mailto:asuth@mozilla.com>> wrote:
>
>     On Wed, May 20, 2015 at 8:47 AM, Jan Kundr?t <jkt@flaska.net
>     <mailto:jkt@flaska.net>> wrote:
>
>         Are some other client developers interested in this?
>
>
>     It seems reasonable to me to standardize a flag for this purpose,
>     even if many clients prefer to keep the setting local-only. 
>     Thunderbird uses a per-message "remoteContentPolicy" property that
>     is persisted locally in the msf files but never persisted to IMAP
>     servers.  Once set, it allows external images for the specific
>     messages to be fetched going forward.  (Some information leakage
>     will be suppressed on repeated viewings because of the network
>     cache, but the images/etc. are likely to be rotated out.)
>
>     Note: I no longer actively contribute to Thunderbird, so if anyone
>     is going to change things to use the flag it won't be me.  I work
>     on the Firefox OS email app, and we currently have no plans to
>     persist "show extenal images" on a per message basis, but if we
>     did, we would use the proposed flag since we would synchronize the
>     flag to the server when possible.
>
>
> I think we persist per sender, not per message... and we know proxy 
> most of that stuff, so I think a lot of users just show all 
> messages... or we have some complicated logic about when it's ok to 
> show and when it's not which is calculated on the fly and not exposed.

Thunderbird also allows you to persist a show-remote-images per-sender 
as well (the UI says something like "Show content for this message" and 
"Remember for this sender" as options).

If an IMAP keyword were standardized, I'd probably recommend we'd use 
it, but I wouldn't prioritize implementing it. I believe that when we 
use the per-sender option, we don't bother to set the flag on the 
message itself, so I'm not sure that a keyword would be totally 
reflective of the current state in Thunderbird.

Ultimately, I'm convinced of neither the utility nor the inutility of 
this feature. The biggest benefit appears to be "synchronization of 
settings," but it's not exactly a sufficient synchronization due to the 
existence and use of coarser-grained (e.g., per-sender) policies, so I'm 
hesitant to support such a standard. On the other hand, I don't really 
have a coherent reason to object to the standard.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150521/cf4cec5e/attachment.html>

On Thu, May 21, 2015, at 11:36 PM, Joshua Cranmer wrote:
> On 5/20/2015 2:29 PM, Brandon Long
      wrote:
>>
>>
>> On Wed, May 20, 2015 at 12:07 PM,
            Andrew Sutherland <asuth@mozilla.com> wrote:
>>> On Wed, May
                      20, 2015 at 8:47 AM, Jan Kundr?t
                      <jkt@flaska.net> wrote:
>>>
>>>> Are some other client
                        developers interested in this?
>>>
>>>
>>> It seems reasonable to me to standardize a flag
                      for this purpose, even if many clients prefer to
                      keep the setting local-only. Thunderbird uses a
                      per-message "remoteContentPolicy" property that is
                      persisted locally in the msf files but never
                      persisted to IMAP servers. Once set, it allows
                      external images for the specific messages to be
                      fetched going forward. (Some information leakage
                      will be suppressed on repeated viewings because of
                      the network cache, but the images/etc. are likely
                      to be rotated out.)
>>>
>>> Note: I no longer actively contribute to
                      Thunderbird, so if anyone is going to change
                      things to use the flag it won't be me. I work on
                      the Firefox OS email app, and we currently have no
                      plans to persist "show extenal images" on a per
                      message basis, but if we did, we would use the
                      proposed flag since we would synchronize the flag
                      to the server when possible.
>>
>> I think we persist per sender, not per message... and
              we know proxy most of that stuff, so I think a lot of
              users just show all messages... or we have some
              complicated logic about when it's ok to show and when it's
              not which is calculated on the fly and not exposed.
>
>
    Thunderbird also allows you to persist a show-remote-images
    per-sender as well (the UI says something like "Show content for
    this message" and "Remember for this sender" as options).
>
>
    If an IMAP keyword were standardized, I'd probably recommend we'd
    use it, but I wouldn't prioritize implementing it. I believe that
    when we use the per-sender option, we don't bother to set the flag
    on the message itself, so I'm not sure that a keyword would be
    totally reflective of the current state in Thunderbird.
>
>
    Ultimately, I'm convinced of neither the utility nor the inutility
    of this feature. The biggest benefit appears to be
    "synchronization of settings," but it's not exactly a sufficient
    synchronization due to the existence and use of coarser-grained
    (e.g., per-sender) policies, so I'm hesitant to support such a
    standard. On the other hand, I don't really have a coherent reason
    to object to the standard.

FastMail likewise shows content based on the sender. If this flag
existed, we would automatically set it for addresses in your addressbook
upon delivery, but probably not update it when you changed your
addressbook afterwards, so it would be of partial value I guess. Our
client uses the current addressbook so that older messages from a known
sender get images as well.

Bron.


--
Bron Gondwana brong@fastmail.fm


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150522/0030ec6b/attachment.html>