96 lines
4.2 KiB
Plaintext
96 lines
4.2 KiB
Plaintext
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>
|