RFC Errata
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 GROUPArea 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.