errata logo graphic

Found 4 records.

Status: Verified (2)

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

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

Errata ID: 269

Status: Verified
Type: Technical

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

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


Status: Held for Document Update (1)

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

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

Errata ID: 4222

Status: Held for Document Update
Type: Technical

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.


Status: Rejected (1)

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

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

Errata ID: 4218

Status: Rejected
Type: Editorial

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