wasm-demo/demo/ermis-f/imap-protocol/cur/1600094995.22589.mbox:2,S

53 lines
2.2 KiB
Plaintext

MBOX-Line: From jkt at flaska.net Fri May 15 07:24:30 2015
To: imap-protocol@u.washington.edu
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
Date: Fri Jun 8 12:34:54 2018
Subject: [Imap-protocol] Registration of keyword which enables fetching
external images
Message-ID: <5f24e38f-5968-4367-97f6-fa4008f582fd@flaska.net>
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/