MBOX-Line: From brong at fastmail.fm  Thu May 21 07:22:27 2015
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:55 2018
Subject: [Imap-protocol] Registration of keyword which enables fetching
 external images
In-Reply-To: <555DDF50.1070108@verizon.net>
References: <5f24e38f-5968-4367-97f6-fa4008f582fd@flaska.net>
	<14D026C7F297AD44AC82578DD818CDD047B37C34E0@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
	<c4a7510f-bd4a-49cb-abda-e6b1b1448078@flaska.net>
	<CALFQBW3kRQo3S27Sq9a5r__AvLshN36n5FP8U9P23zSrcqeeWA@mail.gmail.com>
	<CABa8R6uW8vXuvoAVoSYy_JOs8U9jNeGFgL7b0Siz3OSmxrq0cA@mail.gmail.com>
	<555DDF50.1070108@verizon.net>
Message-ID: <1432218147.630295.274806297.1385F9F3@webmail.messagingengine.com>

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>
