RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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