[Top] [All Lists]

[ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

2015-11-28 20:58:36
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.

---------- 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

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

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

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
 * Privacy-preserving mail loop prevention

ietf-smtp mailing list