Re: [secdir] Secdir review of draft-ietf-appsawg-email-auth-codes

"Murray S. Kucherawy" <> Fri, 01 August 2014 18:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F2E11A02DB; Fri, 1 Aug 2014 11:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HVUm4Uk4NaS7; Fri, 1 Aug 2014 11:08:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D8521B2796; Fri, 1 Aug 2014 11:08:31 -0700 (PDT)
Received: by with SMTP id x12so4665696wgg.28 for <multiple recipients>; Fri, 01 Aug 2014 11:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3kpjEZi3cGQCvz9O00B64Vt13SS4fNgX1fHstkAB3co=; b=Vqovyw1VcNznWTnplaT4KaS4HsWKHztMIYLTab5B7PURxuXy+tHg8M05P5+K5omjzI dgQz9ThTziirKzBZAlFBv5e1EDh1sZ5+Kd9nMT0/gJ1EaSOVb6yfMgAqmDponv8kkWC8 5GqHInxhZiS71ZAhmUbrVDvp+Owlm+UvE49dzuHfxtpxkUp+RJpNexccJLdXUPfNQo4D S1I5BZrQqrvl9n6O0Jm5fVxKu5uHCh3GIuWc7qPifPU+keJg4Easu1V04QEWJUh+N9hQ hc5/RvrELUDhfQMKQmCUpc7TSrt58tLfS1NsQV0H0TenpWYu/kNIRiDrplH9+iNnbkDk G6EA==
MIME-Version: 1.0
X-Received: by with SMTP id g4mr10485263wja.37.1406916509385; Fri, 01 Aug 2014 11:08:29 -0700 (PDT)
Received: by with HTTP; Fri, 1 Aug 2014 11:08:29 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Fri, 01 Aug 2014 11:08:29 -0700
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: Paul Wouters <>
Content-Type: multipart/alternative; boundary="047d7b450a7cc54d7b04ff954650"
Cc:, The IESG <>, IETF Apps Discuss <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-appsawg-email-auth-codes
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Aug 2014 18:08:39 -0000

Hi Paul, thanks for the review.

On Fri, Aug 1, 2014 at 8:28 AM, Paul Wouters <> wrote:

> I do have one question with respect to the temporary failure codes.
> For SPF Failure Codes, a distinction is made between an SPF validation
> failure (X.7.22) and an SPF validation error (X.7.23).
> A failure is the result of a successful (SPF) check method to mark the
> email message as failed. An error means the (SPF) method to check for
> failure did not run successfully and it could not determine whether the
> message should pass or fail. For example, an error in the (SPF) check
> could be due to a temporary DNS problem.
> For the DKIM and Reverse DNS, which like SPF depends on a working DNS
> resolver for the mail server, there is no such split made. These can
> only return failures, not errors in determining success or failure.
> If there is value in indicating this distinction for SPF, I would assume
> the same distinction would be useful for DKIM and Reverse DNS. If there
> are good reasons not to do this, perhaps it would be good to explain
> those reasons in the document along with some advise for implementors
> on what (existing) extended message code to return in the case of
> temporary DNS failures in the DKIM and Reverse DNS case.

I think the case of interest for both is what to do when something
malformed is discovered.  In that respect, the two communities operate a
little differently.  Specifically, if a malformed SPF record is found in
the DNS, the intent here is to reject the message with the newly-registered
error code rather than something less precise.  For DKIM, however, a
malformed signature or key record typically leads to the message being
delivered with an annotation (RFC7001, for example) that there was no valid
signature on the message, rather than rejecting it.

For rDNS, I suspect most MTAs use x.4.3 to report that condition, which is
already registered.

I imagine there's no harm in adding an error code for DKIM and maybe for
rDNS.  As the document already says, there's no compulsion to use them if
operators choose to continue using whatever they're using today.