Subject: MDNs vs. DSNs

From: [email-masked] (Sam Robertson)
Date: Wed, 08 Sep 1999 18:11:52 -0700

I'm probably resurrecting a dead horse here, but let's see.

Generating MDN's in our implementation is not possible at this point,
yet we want to support the reject action.  Aside from all the features
provided by supporting RFC 2298, why is an MDN an absolute requirement?

Is there anyway we might be able to change the wording in 4.1 to read:

   The optional "reject" action refuses delivery of a message by sending

   back an [MDN] or [DSN] to the sender.

   Example:  if header :contains "from" "[email-masked]" {
                reject "I am not taking mail from you, and I don't want
                your birdseed, either!";
             }

   A reject message SHOULD take the form of a failure MDN but MAY be a
DSN as specified  by
   [MDN] [DSN].

... continued specifics about MDN verbage ...

Regardless of whether we can change the wording at all, the second
sentence in the first paragraph of 4.1 should start with a capital R.

In addition, in defining the action 'redirect' we should define the
behavior without forcing someone to know what a .forward file using
sendmail under UNIX does.  In other words we should define it in
explicit terms???

Sam Robertson

---

From: Tim Showalter <[email-masked]>
Date: 09 Sep 1999 01:09:27 -0700

> provided by supporting RFC 2298, why is an MDN an absolute requirement?

We want a standard reply with well-known semantics.  MDN has standard
semantics, but they are weak enough to allow for what a reject action
implies.  Specifically, a "deleted" MDN allows for the ambiguity that
"maybe the recipient deleted your message, or maybe he deleted it and
kept it".

The semantics of a DSN are not defined this way.  There's no wiggle
room for what amounts to lying.

I find it rather strange that you can't generate an MDN.  Why not?
(What am I missing?)

>    back an [MDN] or [DSN] to the sender.

MDNs and DSNs are not interchangable, so I don't want to make this
change.

> sentence in the first paragraph of 4.1 should start with a capital R.

er, actually, I think the word "It" is missing in there.  Thanks.

> sendmail under UNIX does.  In other words we should define it in

It is defined in explicit terms in the next sentence.  I'd entertain
any suggestions of specific wording that you'd care to offer.

---

From: Ned Freed <[email-masked]>
Date: Sat, 11 Sep 1999 22:32:59 -0700 (PDT)

> "maybe the recipient deleted your message, or maybe he deleted it and

There's also another side to this coin -- suppose filtering is implemented in
the MUA (perfectly reasonable), the message had a NOTIFY=SUCCESSES in the
envelope, and the MUA's filters said "reject".  Then it is possible to get a
success DSN followed by a failure MDN. (Also reasonable.) But if a DSN
was generated, you'd have a success DSN followed by a failure DSN. Not
good.

> I find it rather strange that you can't generate an MDN.  Why not?

One case where this would be an issue is if reject was implemented in
an LMTP delivery agent as a return of a failure status. This would
result in a failure DSN and short of implementing a queue in the
LMTP delivery agent there would be no way to avoid this. (And remember
that the point of LMTP is to avoid having a queue.)

In order to work around such restrictions I suppose we could allow
use of DSNs if combining with any other action is blocked and
if the imeplementation is sure to block generation of a spurious
success DSN. But this is rather intricate, and I remain to be convinced
the added complexity is worth it.

				Ned