[Top] [All Lists]

Re: MDNs vs. DSNs

1999-09-11 22:40:21
Sam Robertson <samr(_at_)Netscape(_dot_)COM> writes:

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?

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".

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

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?)

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.


<Prev in Thread] Current Thread [Next in Thread>