Subject: [yam] Issue #6: RFC 5321 Section 4.4: remove typo

From: SM <[email-masked]>
Date: Sun, 06 Dec 2009 01:02:45 -0800

Hello,

The following sentence in Section 4.4 of RFC 5321 also occurs in Section 3.9.2:

   "Note that the key difference between handling aliases
    (Section 3.9.1) and forwarding (this subsection) is
    the change to the backward-pointing address in this case."

The sentence in Section 4.4 is probably an editing glitch.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Sun, 06 Dec 2009 14:31:27 -0800 (PST)

> The sentence in Section 4.4 is probably an editing glitch.

It certainly seems completely out of place in section 4.4.

As long as we're messing with 4.4, perhaps we should also consider getting rid
of the false binary choice it offers (MUST send a single DSN for all recipients
or one DSN per recipient). There's nothing inherently wrong with sending, say,
one DSN for one recipient and a second for all the others. And this happens
all the time in practice when delivery problems are discovered at different
processing stages.

So I suggest changing:

   A single notification listing all of the failed recipients or
   separate notification messages MUST be sent for each failed
   recipient.  For economy of processing by the sender, the former
   SHOULD be used when possible.  Note that the key difference between
   handling aliases (Section 3.9.1) and forwarding (this subsection) is
   the change to the backward-pointing address in this case.  All
   notification messages about undeliverable mail MUST be sent using the
   MAIL command (even if they result from processing the obsolete SEND,
   SOML, or SAML commands) and MUST use a null return path as discussed
   in Section 3.6.

to something like:

   Notifications MUST be sent detailing all failed recipients. For economy
   of processing by the sender, a single notification listing all of the
   failed recipients SHOULD be used when possible. All
   notification messages about undeliverable mail MUST be sent using the
   MAIL command (even if they result from processing the obsolete SEND,
   SOML, or SAML commands) and MUST use a null return path as discussed
   in Section 3.6.

				Ned

---

From: SM <[email-masked]>
Date: Sun, 06 Dec 2009 15:43:37 -0800

Hi Ned,
>all the time in practice when delivery problems are discovered at different

I came across a case with sendmail where a DSN was sent to all the 
recipients if one of the recipients failed.  I don't know whetehr it 
is related to the false binary choice you mentioned above.  I support 
getting rid of that choice.

>   SOML, or SAML commands) and MUST use a null return path as discussed

Minor change:

   Notifications MUST be sent detailing all failed recipients. For economy
   of processing by the sender, a single notification listing all of the
   failed recipients SHOULD be used whenever possible. All
   notification messages about undeliverable mail MUST be sent using the
   MAIL command (even if they result from processing the obsolete SEND,
   SOML, or SAML commands) and MUST use a null reverse-path as discussed
   in Section 6.1.

I changed "null return path" to "null reverse-path".  I gather that 
you referred to Section 3.6 (Relaying and Mail Routing) as that's how 
it has been since RFC 2821.  Section 3.6.3 mentions non-delivery 
reports and DSN.  I used Section 6.1 (Reliable Delivery and Replies by Email).

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Sat, 12 Dec 2009 09:16:53 -0800 (PST)

> getting rid of that choice.

Hadn't run into that one before. Not good.

> reports and DSN.  I used Section 6.1 (Reliable Delivery and Replies by Email).

Seems like a reasonable change to me.

				Ned