errata logo graphic

Found 4 records.

Status: Held for Document Update (3)

RFC5451, "Message Header Field for Indicating Message Authentication Status", April 2009

Note: This RFC has been obsoleted by RFC7001

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2617

Status: Held for Document Update
Type: Technical

Reported By: D. Stussy
Date Reported: 2010-11-09
Held for Document Update by: Sean Turner

Section 2.4.2 says:

   hardfail:  This client is explicitly not authorized to inject or
      relay mail using the sender's DNS domain.

It should say:

   fail:  This client is explicitly not authorized to inject or
      relay mail using the sender's DNS domain.

Notes:

Change [sixth paragraph] for consistency:
1) RFC 4408 (SPF) defines this state as "fail", not "hardfail".
2) The other subsections of 2.4 of this RFC define "fail".
The change makes the result state consistent and parallel to those as noted in other RFCs and for the alternative methods defined in this RFC.


Errata ID: 3195

Status: Held for Document Update
Type: Technical

Reported By: Dirk Geschke
Date Reported: 2012-04-17
Held for Document Update by: Barry Leiba
Date Held: 2012-04-18

Section 2.3 says:

     reasonspec = "reason" [CFWS] "=" [CFWS] value
                ; a free-form comment on the reason the given result
                ; was returned

It should say:

     reasonspec = [CFWS] "(" value ")"
                ; a free-form comment on the reason the given result
                ; was returned


Notes:

I am not sure if it is a mistake, but the examples look this way:

Authentication-Results: example.com;
dkim=pass (good signature) header.i=@mail-router.example.net;
dkim=fail (bad signature) header.i=@newyork.example.com

So I think the "reasonspec" is here "(good signature)" and "(bad signature)". All other examples show similar entries for "reasonspec".

[Verifier's note:
This change is INCORRECT. The free-form parenthesized comments are actually part of the "CFWS" production. The confusion is caused by having no examples that use the "reasonspec" production, and that should be fixed if the document is updated.]


Errata ID: 2818

Status: Held for Document Update
Type: Editorial

Reported By: Alessandro Vesely
Date Reported: 2011-05-31
Held for Document Update by: Sean Turner

Section B.5 says:

        Authentication-Results: example.com;
                  sender-id=hardfail header.from=example.com;
                  dkim=pass (good signature) header.i=sender@example.com
        Received: from mail-router.example.com
                      (mail-router.example.com [192.0.2.1])
                  by auth-checker.example.com (8.11.6/8.11.6)
                      with ESMTP id i7PK0sH7021929;
                  Fri, Feb 15 2002 17:19:22 -0800
        Authentication-Results: example.com;
                  auth=pass (cram-md5) smtp.auth=sender@example.com;
                  spf=hardfail smtp.mailfrom=example.com
        Received: from dialup-1-2-3-4.example.net
                      (dialup-1-2-3-4.example.net [192.0.2.200])
                  by mail-router.example.com (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        DKIM-Signature:  v=1; a=rsa-sha256; s=gatsby; d=example.com;
                  i=sender@example.com; t=1188964191; c=simple/simple;
                  h=From:Date:To:Message-Id:Subject;
                  bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
                  b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.com
        Message-Id: <12345.abc@example.com>
        Subject: here's a sample

        Hello!  Goodbye!

It should say:

        Authentication-Results: example.com;
                  spf=pass smtp.mailfrom=example.com
                  dkim=pass (good signature) header.i=@example.com
        Received: from msa.example.com (msa.example.com [192.0.2.1])
                  by mx.example.com (8.11.6/8.11.6)
                      with ESMTP id i7PK0sH7021929;
                  Fri, Feb 15 2002 17:19:22 -0800
        DKIM-Signature:  v=1; a=rsa-sha256; s=gatsby; d=example.com;
                  t=1188964191; c=simple/simple; h=From:Date:To:Subject:
                  Message-Id:Authentication-Results;
                  bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
                  b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
        Authentication-Results: example.com;
                  auth=pass (details omitted as precautionary measure)
        Received: from [192.0.2.200]
                      (dialup-1-2-3-4.example.net [192.0.2.200])
                  by msa.example.com (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.com
        Message-Id: <12345.abc@example.com>
        Subject: here's a sample

        Hello!  Goodbye!

Notes:

The corrected example shows how an MSA may prove that it handled submission by signing an A-R field. (I reordered the header, changed host names, changed A-R fields, removed i=, and added A-R in h=)

Some text in the same section may need minor revision. In particular, SPF pass, host name, senderid, and the origin of the DKIM key (in the corrected example, example.net may well be a MUA, while example.com has separate MSA and MX hosts.)


Status: Rejected (1)

RFC5451, "Message Header Field for Indicating Message Authentication Status", April 2009

Note: This RFC has been obsoleted by RFC7001

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 3182

Status: Rejected
Type: Editorial

Reported By: D. Stussy
Date Reported: 2012-04-09
Rejected by: Barry Leiba
Date Rejected: 2012-04-18

Section Header. says:


It should say:

Updated by RFC 6577.

Notes:

RFC 6577 (March 2012) indicates that it updates 5451, but 5451 does not indicate it is updated. This update is the same as errata ID 2617 (date reported 2010-11-09).
--VERIFIER NOTES--
The "updated by" information is in the metadata for the RFC, and that metadata is correct (see the version in the datatracker: https://datatracker.ietf.org/doc/rfc5451/ ). The text of an RFC does not change once it's published.


Report New Errata