[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    [Imap-protocol] Registration of keyword which enables fetching external images
From:       Jan_Kundrát <jkt () flaska ! net>
Date:       2015-05-15 14:24:30
Message-ID: 5f24e38f-5968-4367-97f6-fa4008f582fd () flaska ! net
[Download RAW message or body]

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/
_______________________________________________
Imap-protocol mailing list
Imap-protocol@u.washington.edu
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
[prev in list] [next in list] [prev in thread] [next in thread]