One document matched: draft-josefsson-email-received-privacy-01.xml

<?xml version="1.0"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2821 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml">
<!ENTITY rfc4409 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4409.xml">
<!ENTITY rfc5321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY rfc5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY rfc7624 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7624.xml">
]>

<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc category="info" ipr="trust200902"
     updates="5321, 4409"
     docName="draft-josefsson-email-received-privacy-01">

  <front>

    <title abbrev="Privacy for Received Header">
      Improving Privacy for the email "Received" Header
    </title>
    
    <author initials="S." surname="Josefsson" fullname="Simon Josefsson">
      <organization></organization>
      <address>
	<email>simon@josefsson.org</email>
      </address>
    </author>
    
    <author initials="L." surname="Nordberg" fullname="Linus Nordberg">
      <organization>DFRI</organization>
      <address>
	<email>linus@dfri.se</email>
      </address>
    </author>

    <date month="November" year="2015"/>

    <abstract>

      <t>
	The email "Received" header raises a privacy concern with
	email routing.  This document discusses the problem and
	describes a solution that relevant Message Transfer Agents
	(MTAs) and Mail Submission Agents (MSAs) may adopt.
      </t>

    </abstract>

  </front>
  
  <middle>

    <section title="Introduction">

      <t>
	As mentioned in <xref target="RFC7624">RFC 7624 section
	3.3.4</xref>, the <xref target="RFC5321">Simple Mail Transfer
	Protocol (SMTP)</xref> requires that each successive SMTP
	relay adds a "Received" header to the mail headers.  The
	purpose of these headers is to enable audit of mail
	transmission, and perhaps to distinguish between regular mail
	and spam.  An attacker that can observe sufficient email
	traffic can regularly update the mapping between public IP
	addresses and individual email identities.  Even if the SMTP
	traffic was encrypted on submission and relaying, the attacker
	can still receive a copy of public mailing lists.
      </t>

      <t>
	While not mentioned in RFC 7624, the Received header is used
	for loop detection, as discussed in <xref
	target="RFC5321">section 6.3 of SMTP</xref>.
      </t>
      
      <t>
	To give an example of a privacy violation, consider the
	following scenario.  When SMTP is used for <xref
	target="RFC4409">message submission</xref>, the SMTP server
	accepting the email from the user MUA will add a Received
	header that will record the IP address of the user's host.
	When the email is circulated further in the Internet
	environment, possibly ending up publicly archives, it will be
	possible to read this Received header.  This allows an
	attacker to learn the IP address of the host used by the
	individual who sent the email.  This consitutes a privacy
	violation.  The knowledge of the IP address of the user may be
	used to gather additional information about the user, or to
	simplify direct attacks against the host of the user.
      </t>

      <t>
	Privacy violations may also happen when adding additional
	Received headers after an email has been delivered to the MX
	for the destination domain, where anyone who can observe the
	Received header can learn additional information about the
	internal network topology of a single organization.  The
	privacy relevance of this information depends on each
	organization.
      </t>

      <t>
	There may be other situations where adding Received headers
	would leak unintended information to an observing party.  For
	example, an organization may use different SMTP relays
	depending on the category of a customer.  By knowing the
	mapping between SMTP relay and customer category, an observing
	party would learn the customer category for the organization.
      </t>

      <t>
	The privacy problem we are interested in resolving is the part
	of an SMTP agent (be it an MTA or an MSA) that persistently records
	the IP address of the client in the Received header.
      </t>
      
      <t>
	The purpose of this document is to propose a mechanism that
	implementers and operators of SMTP agents may adopt to
	mitigate the privacy violation.
      </t>

      <t>
	For ease of reference, the syntax of the Received header is
	defined in <xref target="RFC5322">RFC 5322 section
	3.6.7</xref> and the SMTP protocol requirement to add them is
	described in <xref target="RFC5321">RFC 5321 section
	4.4</xref>.
      </t>

      <t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described
	in <xref target="RFC2119">RFC 2119</xref>.
	</t>

    </section>

    <section title="Privacy-sensitive Received header Convention">

      <t>The "from clause" of the Received header MUST NOT be added by
      SMTP entities concerned with the privacy of their clients.</t>

      <t>With "from clause", we intend what in <xref
      target="RFC2821"/> is denoted as "From-domain" in the ABNF.  To
      illustrate what is intended, consider the following Received
      header that were added by a MSA and thus leaked the then-current
      IP address of the submitter's host.</t>

      <figure>
	<artwork>
Received: from latte.josefsson.org ([155.4.17.2])
 by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9QFWqNO022103
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
 Mon, 26 Oct 2015 16:32:53 +0100
	</artwork>
      </figure>

      <t>The from clause is the part of the header that
      reads "from latte.josefsson.org ([155.4.17.2])".</t>
      
    </section>

    <section title="Acknowledgements">

      <t>The following individuals provided valuable feedback: Philipp
      Winter, Georg Koppen, Jacob Appelbaum, Christian Huitema, Ned
      Freed, John Levine</t>

    </section>

    <section title="Security Considerations">

      <t>
	This document resolves a privacy concern with the Received
	header.  The privacy concern is discussed as a security
	consideration in <xref target="RFC5321">section 7.6 of
	SMTP</xref> however that document does not provide any
	mechanism for implementers who are concerned about the problem
	to "opt out".
      </t>

    </section>

    <section anchor="iana-considerations" title="IANA Considerations">

      <t>
	IANA is adviced to add this document to the Reference column
	of the "Permanent Message Header Field Names" registry for
	"Received".
      </t>

    </section>

  </middle>

  <back>

    <references title="Normative References">

      &rfc2119;
      &rfc4409;
      &rfc5321;
      &rfc5322;

    </references>

    <references title="Informative References">

      &rfc2821;
      &rfc7624;

    </references>

    <section title="Copying conditions">

      <t>
	Regarding this entire document or any portion of it, the
	authors makes no guarantees and is not responsible for any
	damage resulting from its use.  The authors grants irrevocable
	permission to anyone to use, modify, and distribute it in any
	way that does not diminish the rights of anyone else to use,
	modify, and distribute it, provided that redistributed
	derivative works do not contain misleading author or version
	information.  Derivative works need not be licensed under
	similar terms.
      </t>

    </section>

  </back>

</rfc>