RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Verified (3)

RFC 3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003

Note: This RFC has been updated by RFC 3798, RFC 3885, RFC 5337, RFC 6533, RFC 8098

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 269
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Mieke Van de Kamp
Date Reported: 2003-03-31

Section 5.2 says:

   A reference is made to RFC 1123, section 2.3.3, which does not exist. 
 
   The correct section in RFC 1123 is 5.3.3.

Errata ID: 686
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Valdis Kletniek
Date Reported: 2004-08-10
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-06

Section 4.2 says:

   The "addr-type" portion MUST be an IANA-registered electronic mail
   address-type (as defined in [3]), while the "xtext" portion contains
   an encoded representation of the original recipient address using the
   rules in section 5 of this document.  The entire ORCPT parameter MAY
   be up to 500 characters in length.

It should say:

   The "addr-type" portion MUST be an IANA-registered electronic mail
   address-type (as defined in [3]), while the "xtext" portion contains
   an encoded representation of the original recipient address using the
   rules in section 4 of this document.  The entire ORCPT parameter MAY
                    ^
   be up to 500 characters in length.

Notes:

xtext encoding is described in Section 4, not in Section 5

Errata ID: 5575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: M. Shulhan
Date Reported: 2018-12-13
Verifier Name: RFC Editor
Date Verified: 2019-02-19

Section 4.2 says:

When initially submitting a message via SMTP, if the ORCPT parameter
is used, it MUST contain the same address as the RCPT TO address
(unlike the RCPT TO address, the ORCPT parameter will be encoded as
xtext).  Likewise, when a mailing list submits a message via SMTP to
be distributed to the list subscribers, if ORCPT is used, the ORCPT
parameter MUST match the new RCPT TO address of each recipient, not
the address specified by the original sender of the message.)

It should say:

When initially submitting a message via SMTP, if the ORCPT parameter
is used, it MUST contain the same address as the RCPT TO address
(unlike the RCPT TO address, the ORCPT parameter will be encoded as
xtext).  Likewise, when a mailing list submits a message via SMTP to
be distributed to the list subscribers, if ORCPT is used, the ORCPT
parameter MUST match the new RCPT TO address of each recipient, not
the address specified by the original sender of the message.

Notes:

Superfluous closing parenthesis at the end of paragraph.

Status: Held for Document Update (3)

RFC 3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003

Note: This RFC has been updated by RFC 3798, RFC 3885, RFC 5337, RFC 6533, RFC 8098

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4222
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Ned Freed
Date Reported: 2015-01-06
Held for Document Update by: Barry Leiba
Date Held: 2015-03-01

Section 5.1 says:

   (b) If an SMTP client issues a RCPT command containing any valid
       NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
       return the same response as it would to the same RCPT command
       without those NOTIFY and/or ORCPT parameters.  A conforming SMTP
       server MUST NOT refuse a RCPT command based on the presence or
       absence of any of these parameters.

It should say:

   (b) If an SMTP client issues a RCPT command containing any valid
       NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST NOT
       alter its response solely based on the use or nonuse of these
       parameters. A conforming SMTP server MUST NOT refuse a RCPT
       command based on the presence of any of these parameters for
       anything other than reasons of local policy.


Notes:

The text as written effectively precludes using the content of the ORCPT or
NOTIFY parameters in implementing local filtering policies in general and
AS/AV policies in particular. If, for example, a particular ORCPT value
is known to associated with a source of spam, rejecting messages on that basis
at RCPT TO time should not be prohibited. Similarly, a site may place a high
priority on avoiding the possibility of blow-back spam associated with the
use of NOTIFY=SUCCESS; it should again be possible to reject messages
requesting success receipts as a matter of local policy.

Errata ID: 6422
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Ned Freed
Date Reported: 2021-02-05
Held for Document Update by: Barry Leiba
Date Held: 2021-02-05

Section 9.3 says:

MTA names of type "dns" SHOULD be valid Internet domain names.
If such domain names are not available, a domain-literal
containing the internet protocol address is acceptable.  Such
domain names generally conform to the following syntax:

        domain = real-domain / domain-literal

        real-domain = sub-domain *("." sub-domain)

        sub-domain = atom

        domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"

where "atom" and "DIGIT" are defined in [2].

It should say:

MTA names of type "dns" SHOULD be valid Internet domain names.
If such domain names are not available, a domain-literal
containing the internet protocol address is acceptable.  Such
domain names generally conform to the following syntax:

        domain = real-domain / domain-literal

        real-domain = sub-domain *("." sub-domain)

        sub-domain = atom

where "atom" and "domain-literal" are defined in [2].

Notes:

Domain literals should not have been restricted to IPv4 addresses. Note that an alternate way to fix this that could be done without a revision or errata would be to published a short RFC that defines a new MTA name type, say "alit" that could then be used for address literals.

Errata ID: 6386
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Mark Johnston
Date Reported: 2021-01-14
Held for Document Update by: Barry Leiba
Date Held: 2021-01-14

Section 4 says:

   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
   parameters, they are not, in the language of that document,
   "structured field bodies".  Therefore, while parentheses MAY appear
   within an emstp-value, they are not recognized as comment delimiters.

It should say:

   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
   parameters, they are not, in the language of that document,
   "structured field bodies".  Therefore, while parentheses MAY appear
   within an esmtp-value, they are not recognized as comment delimiters.

Notes:

"emstp-value" should be "esmtp-value"

Status: Rejected (1)

RFC 3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003

Note: This RFC has been updated by RFC 3798, RFC 3885, RFC 5337, RFC 6533, RFC 8098

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4218
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jaime Hablutzel
Date Reported: 2015-01-03
Rejected by: Barry Leiba
Date Rejected: 2015-03-10

Section 10.5 says:

Note that RET, ENVID, and ORCPT all retain their original values.

...

>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 recipient okay

It should say:

Note that RET, ENVID, NOTIFY, and ORCPT all retain their original
values.

...

>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=FAILURE \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 recipient okay

Notes:

See the original conversation during the submission (section 10.1) where the NOTIFY parameter has a "FAILURE" value for "George@Tax-ME.GOV" recipient.

>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 <George@Tax-ME.GOV> recipient ok

See section 5.2.7.2, "single-recipient aliases".

Under normal circumstances, when a message arrives for an "alias"
which has a single forwarding address, a DSN SHOULD NOT be issued.
Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with
the message as it is redistributed to the forwarding address.

Where it saids that all ENVID, NOTIFY, RET, and ORCPT should be propagated.
--VERIFIER NOTES--
There are specific cases in which NOTIFY doesn't retain its value when a message is relayed (such as if the next hop doesn't support the extension) and the omission of NOTIFY from that list is deliberate.

Report New Errata



Advanced Search