You might want to take a look at this proposed WG charter and send
appropriate comments. It looks to me actively harmful, for a variety of
reasons including that tits proponents appear to be painfully unfamiliar
with the realities of modern e-mail systems where 90% of the mail is spam,
malware and phishes, and the main privacy threats to users are from the
criminals sending the spam.
R's,
John
---------- Forwarded message ----------
Date: Thu, 26 Nov 2015 08:46:29
From: Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com>
To: shutup(_at_)ietf(_dot_)org
Cc: Murray S. Kucherawy <superuser(_at_)gmail(_dot_)com>
Subject: [Shutup] Proposed Charter for the
"SMTP Headers Unhealthy To User Privacy" WG
Hi,
I will repost updated charter proposal after a few more people join the mailing
list, but in order to bootstrap the public discussion, here is the latest
version.
I've used the version provided by Patrik Wallstrom and addressed private
comments received from Murray Kucherawy. Other then fixing typos, he suggested
to describe what is out of scope and he also asked to clarify relationship with
DMARC WG which might be going in the opposite direction in regards to data
minimization in the Received header fields. I also replaced "SMTP protocol"
with "Email" in a couple of places where the former was not correct.
So the latest proposal is below:
--------------------------
Charter for SMTP Headers Unhealthy To User Privacy
Header fields in Email messages can reveal private information to an
observer that might be used for attacking an organization or an
individual. The goal of this working group is to reduce the amount of
private information exposed by Email header fields through:
* well-engineered improvements to the SMTP protocol and
* guidance for SMTP implementors and deployments on
privacy-preserving practices
Some examples of privacy-sensitive header fields:
SMTP [RFC5321] requires that each successive SMTP relay adds a
"Received" header field to the mail headers. These fields are used for
audit and debugging of mail transmission, mail loop prevention, and as
input to spam detection algorithms.
However, Received header fields also leak address and timing information
that can expose user location, internal network operational details,
and inter-organizational peering arrangements that may not otherwise
be public knowledge and may increase risks to those users and
organizations.
Other header fields also contain sensitive information that is not
strictly needed for SMTP transport but are sometimes used for debugging,
such as comment fields in header fields like Mime-Version [RFC2045], or common
extension header fields like User-Agent, X-Mailer, etc. Indication of a
specific Mail User Agent or toolchain may expose users to tailored
attacks.
When e-mail messages are end-to-end encrypted (e.g. PGP/MIME [RFC3156]
or S/MIME [RFC5751] multipart/encrypted messages), some header fields
expose substantial amounts of metadata that are not relevant or necessary
for functional SMTP service but are customarily expected by the recipient
of the mail, including Subject, From, To, Cc, References, and
In-Reply-To. While some work has been done previously to specify
protection for these header fields in encrypted messages [RFC2634], these
solutions are not widely deployed and messages using them often have
interoperability and end-user UI/UX problems due to their structure.
The working group will prioritize privacy-preserving Email header field
minimization techniques that are interoperable with existing e-mail
deployments and that avoid unnecessary degradation of mail service and
user experience.
The working group with liaise with DMARC WG to make sure that changes
to email handling are compatible with DMARC or at least discuss cons and pros
of using DMARC with changes suggested in this working group.
The working group can discuss related work, but work on any items other
then the 3 listed below would require rechartering.
Work items:
* draft-josefsson-email-received-privacy
* https://modernpgp.org/memoryhole/
* Privacy-preserving mail loop prevention
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp