One document matched: draft-josefsson-email-received-privacy-00.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 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-00">

  <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="October" year="2015"/>

    <abstract>

      <t>
	The email "Received" header has a problematic privacy concern
	affecting email routing before or after handling by public
	SMTP relays.  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 discussed 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>
	For example, when SMTP is used for <xref
	target="RFC4409">message submission</xref>, this allows an
	attacker to learn the IP address of the host used by the
	individual who sent the email.  This consitutes a privacy
	leak.  The knowlege 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 leaks 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>
	Therefore we generalize the privacy problem we are interested
	in resolving to that which affect SMTP transfer or submission
	agents that the organization operating it considers
	appropriate to not leak potentially privacy sensitive
	information about.
      </t>
      
      <t>
	The purpose of this document is to propose a mechanism that
	implementers and operators of SMTP agents may adopt to remove
	the privacy leak.
      </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>If the operator of an SMTP protocol entity, including
      transfer agents and submission agents, desires for improved
      privacy of the submitting entity, it MUST NOT add a Received
      header as discussed in section 4.4 of RFC 5321.</t>
      
    </section>

    <section title="Acknowledgements">

      <t>Thanks to Philipp Winter for valuable feedback.</t>

    </section>

    <section title="Security Considerations">

      <t>
	This document resolves a privacy concern with 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 with the problem to "opt out".
      </t>

      <t>
	The header is primarily intended to aid debugging, and
	according to RFC 5321 systems SHOULD be robust against
	unexpected information in the header.  Therefore, we believe
	no security considerations are introduced by the proposal in
	this document.
      </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.
      </t>

    </section>

  </middle>

  <back>

    <references title="Normative References">

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

    </references>

    <references title="Informative References">

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