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".
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?)
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.
MDNs and DSNs are not interchangable, so I don't want to make this
change.
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.
er, actually, I think the word "It" is missing in there. Thanks.
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???
It is defined in explicit terms in the next sentence. I'd entertain
any suggestions of specific wording that you'd care to offer.