Skip to main content

Email Authentication Status Codes
draft-ietf-appsawg-email-auth-codes-07

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Email Authentication Status Codes' to Proposed Standard (draft-ietf-appsawg-email-auth-codes-07.txt)

The IESG has approved the following document:
- 'Email Authentication Status Codes'
  (draft-ietf-appsawg-email-auth-codes-07.txt) as Proposed Standard

This document is the product of the Applications Area Working Group.

The IESG contact persons are Barry Leiba and Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/


Ballot Text

Technical Summary

   This specification registers Enhanced Status Codes for
   email authentication failures.  The intended status is Proposed Standard as
   the specification seeks to improve interoperability by allowing the SMTP
   server to provide more information to the SMTP client.

Review and Consensus
  
   The document was discussed by seven participants within the Applications
   Area Working Group and it has the consensus of the working group.  Most of
   issues raised were resolved.  An outstanding issue is the term
   "author-aligned".  It was agreed to resolve that during the Last Call.

   The significant issue was how to handle cases where multiple authentication
   checks failed.  Alexey Melnikov was not convinced about having an enhanced
   status code for that case, but in the end is okay with doing that as it provides more
   information.  There was agreement to assign an enhanced status code for such a
   case.

   There was some discussion about whether to register additional enhanced status
   codes for DMARC.  The working group agreed to handle that as part of the
   DMARC work.

   There was a very strong objection to including enhanced status codes for DKIM
   as it violates a recommendation in RFC 6376.  There was agreement to have text
   in this document to make it clear that is not recommended behaviour and
   it is a local policy decision, and this allayed the objections.

Personnel

   The document shepherd is S. Moonesamy.  The Responsible Area Director is
   Barry Leiba.

RFC Editor Note