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