Subject: [dmarc-ietf] Fwd: RFC 7372 on Email Authentication Status Codes

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Sep 2014 20:08:46 -0700

For later reference when registering enhanced status codes for DMARC.

-MSK

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Sep 15, 2014 at 5:23 PM
Subject: RFC 7372 on Email Authentication Status Codes
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked],
[email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 7372

        Title:      Email Authentication Status Codes
        Author:     M. Kucherawy
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2014
        Mailbox:    [email-masked]
        Pages:      8
        Characters: 14224
        Updates:    RFC 7208

        I-D Tag:    draft-ietf-appsawg-email-auth-codes-07.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7372.txt

This document registers code points to allow status codes to be
returned to an email client to indicate that a message is being
rejected or deferred specifically because of email authentication
failures.

This document updates RFC 7208, since some of the code points
registered replace the ones recommended for use in that document.

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

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Sven Krohlas <[email-masked]>
Date: Wed, 17 Sep 2014 10:43:54 +0200

Hi,

> registered replace the ones recommended for use in that document.

I hope this is not off topic here:

RFC 7372 proposes to use a 550 response code for reverse DNS auth
failures, see section 3.3.

Reverse DNS checks are usually done early in the connection (like IP
blocks) in the connection establishment stage of the SMTP dialog.

RFC 5321 allows only a 554 error response there, see section 4.3.2.

So, shouldn't a 554 code be used here? Or does RFC 5321 need an update?

Greetings,
-- 
Sven Krohlas

Mailsecurity Agent
Mail Application Security

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Sep 2014 06:43:13 -0700

> So, shouldn't a 554 code be used here? Or does RFC 5321 need an update?

The definitions in 5321 are:

   550  Requested action not taken: mailbox unavailable (e.g., mailbox
      not found, no access, or command rejected for policy reasons)

   554  Transaction failed (Or, in the case of a connection-opening
      response, "No SMTP service here")

550 seems right to me.  It's a rejection for policy reasons, not a general
transaction failure or the total absence of SMTP service.

-MSK

---

From: [email-masked]
Date: Wed, 17 Sep 2014 13:41:30 -0700 (PDT)

> I hope this is not off topic here:

(chair hat on)

It is. I've cc'ed and directed replies to the ietf-smtp list, where 
this sort of discussion belongs.

(chair hat off)

> failures, see section 3.3.

Correct.

> RFC 5321 allows only a 554 error response there, see section 4.3.2.

You're misreading RFC 5321. Nowhere does it say that its lists of possible
responses are exhaustive. So it is perfectly permissible for RFC 7372 to
specify additional possible responses as long as they fit into the overal
theory of reply codes.

This sort of thing has been done many times.

> So, shouldn't a 554 code be used here? Or does RFC 5321 need an update?

Neither. See above.

				Ned