RFC Errata
Found 4 records.
Status: Held for Document Update (3)
RFC 5451, "Message Header Field for Indicating Message Authentication Status", April 2009
Note: This RFC has been obsoleted by RFC 7001
Note: This RFC has been updated by RFC 6577
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 2617
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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)
RFC 5451, "Message Header Field for Indicating Message Authentication Status", April 2009
Note: This RFC has been obsoleted by RFC 7001
Note: This RFC has been updated by RFC 6577
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 3182
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
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.