OK, not to start controversies that may have already been decided, but:
On 3/29/99 at 3:51 PM -0500, Tim Showalter wrote:
Implementations of the language are expected to take place at time
of final delivery, when the message is moved to the user-accessible
mailbox.
[...]
A reject message MUST take the form of a failure DSN as specified by [DSN].
1. Why is a reject sending a DSN instead of a "deleted" MDN? Given
the first quote above, MDN makes a great deal more sense. It's still
in the form of multipart/report, but the semantics are much closer to
MDN than they are to DSN.
A rejected message may not be filed, redirected, or kept.
2. Why? Maybe I want to make a folder of messages that I have
rejected, or redirect them to a processor that updates my "bad people
to filter against" list. What's the problem with rejecting and doing
one of these other things?
The optional "reject" action resends the message to the sender,
wrapping it in a "reject" form, noting that it was rejected by the
recipient.
3. First, I think "resends" is the wrong word here; "returns" is
probably better. In either case, MUST the entire message be returned,
or MAY a truncated version be returned instead?
Discard MUST be silent; that is, it MUST NOT return a non-delivery
notification of any kind.
4. Does this change in the presence of a Disposition-Notification-To:
header field? Is it still MUST NOT send, or can I send a "denied"
MDN, as in (from RFC 2298):
"denied" The recipient does not wish the sender to be informed
of the message's disposition. A UA may
also siliently ignore message disposition
requests in this situation.
Finally, it may be a good thing to mention the "dispatched" and/or
"processed" MDNs in relation to Sieve. They seem applicable.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102