page_title: Email authentication
section_title: Nature of the problem
hierarchical_section_title: Email authentication / Nature of the problem
caption_attribution_description: English: Email authentication can be complicated by the presence of an intermediate relay.
context_page_description: Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents who participated in transferring and possibly modifying a message.
  The original base of Internet email, Simple Mail Transfer Protocol, has no such feature, so forged sender addresses in emails have been widely used in phishing, email spam, and various types of fraud. To combat this, many competing email authentication proposals have been developed, but only fairly recently have three been widely adopted – SPF, DKIM and DMARC. The results of such validation can be used in automated email filtering, or can assist recipients when selecting an appropriate action.
context_section_description: SMTP defines message transport, not the message content. Thus, it defines the mail envelope and its parameters, such as the envelope sender, but not the header (except trace information) nor the body of the message itself. STD 10 and RFC 5321 define SMTP (the envelope), while STD 11 and RFC 5322 define the message (header and body), formally referred to as the Internet Message Format.
  SMTP defines the trace information of a message, which is saved in the header using the following two fields:
  Received: when an SMTP server accepts a message it inserts this trace record at the top of the header (last to first).
  Return-Path: when the delivery SMTP server makes the final delivery of a message, it inserts this field at the top of the header.
  A mail user agent (MUA) knows the outgoing mail SMTP server from its configuration. A MTA (or a relay server) typically determines which server to connect to by looking up the MX (Mail eXchange) DNS resource record for each recipient's domain name
  The path depicted below can be reconstructed on the ground of the trace header fields that each host adds to the top of the header when it receives the message:
   
  Return-Path: <author@example.com>Received: from D.example.org by E.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500Received: from C.example.net by D.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500Received: from B.example.com (b.example.com [192.0.2.1])  by C.example.net (which is me) with ESMTP id 936ADB8838C  for <different-recipient@example.net>; Tue, 05 Feb 2013 08:44:50 -0800 (PST)Received: from A.example.com by B.example.com with SMTP; Tue, 05 Feb 2013 17:44:47 +0100Received: from [192.0.2.27] by A.example.com with SMTP; Tue, 05 Feb 2013 17:44:42 +0100
  It is important to realize that the first few lines at the top of the header are usually trusted by the recipient.  In fact, those lines are written by machines in the recipient's Administrative Management Domain (ADMD), which act upon her or his explicit mandate.  By contrast, the lines that prove the involvement of A and B, as well as of the purported author's MUA could be a counterfeit created by C.  The Received: field shown above is an epoch-making piece of the header.  The Return-Path: is written by E, the mail delivery agent (MDA), based on the message envelope. Additional trace fields, designed for email authentication, can populate the top of the header.
  Normally, messages sent out by an author's ADMD go directly to the destination's MX (that is B → D in the figures).  The sender's ADMD can add authentication tokens only if the message goes through its boxes.  The most common cases can be schematized as follows:
caption: Email authentication can be complicated by the presence of an intermediate relay. A and B clearly belong to the author ADMD, while D and E are part of the recipient network. What role does C play?
exif: {}