[Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 26 November 2015 13:46 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6A54D1B39C0 for <shutup@ietfa.amsl.com>; Thu, 26 Nov 2015 05:46:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yzoWlUOT4hCQ for <shutup@ietfa.amsl.com>; Thu, 26 Nov 2015 05:46:55 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com []) by ietfa.amsl.com (Postfix) with ESMTP id C92E31B39BF for <shutup@ietf.org>; Thu, 26 Nov 2015 05:46:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1448545611; d=isode.com; s=selector; i=@isode.com; bh=klU7qq9TkRemSu4UDTwMEP8GCNhYVZUIQiDyoWHyQ6Y=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZFOZNw7KjRRMLJKWKLmdjsU9LTTy2czOVQP0YiC1EuqxTggikLclq2R22fKUsz/wAPaBCP oAwgWVpnpvqbPMjHQRaToTuyHjCWWS9sd7H4aWJq5GDV4QivPJAKVE3fu49Zj4JUWWFJQF +bGiX1G0brlHW9hfLIVV7D9UYk5PI5s=;
Received: from [] (dhcp-215.isode.net []) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VlcNSgArTxur@waldorf.isode.com>; Thu, 26 Nov 2015 13:46:50 +0000
Message-ID: <56570D35.1050806@isode.com>
Date: Thu, 26 Nov 2015 13:46:29 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
To: shutup@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/kpoqEaOmfRv2lztFNJckSD5J4cQ>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>
Subject: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2015 13:46:56 -0000

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