[Randy:]
If 'discard' MUST NOT cause failure DSN generation, this could be
difficult in certain plug-in environments (such as one of the
platforms where my Sieve implementation runs).
We can either (1) make 'discard' optional, (2) say that 'discard'
SHOULD NOT cause failure DSN generation, or (3) say this is just
Too Bad.
[Tim:]
I am in favor of (3). Generating DSNs in some cases, most specifically
spam, is not a good idea.
[Randy:]
I don't understand this.
In one particular environment where my Sieve implementation runs, 'discard'
causes the same action as if the message is undeliverable for any other
reason (a failure DSN for 'other' is generated). Why is this bad
specifically in the case of spam?
Because the message is probably undeliverable, so a failure notice has
to be sent. This is inconvienent if the failure can be considered
permenant, but is worse if the domain is valid and fails with a
temporary failure somewhere and just hangs around for five days in the
queue. (Consider what might happen if a shared filter was in use at CMU
and someone spammed our passwd file.)
Does this help?
How does a requirement for silent discard follow from purposes for Sieve
other than message disposition? Discard *is* message disposition,
regardless of any other uses for Sieve (and I use Sieve for message
annotation as well as disposition).
I don't follow this at all. Perhaps my statement was poorly worded or
poorly thought out.
My thought is that your implementation seems to only control where a
message gets sent, in addition to actions that may be unrelated to
delivery. This annoys me because it seems to limit both discard and
multiple fileinto, things well-known existing systems (say, procmail)
are capable of and that I consider useful.
Let me ask this: if discard sends a DSN, how is it meaningfully
different from reject? Reject seems to present a strict superset of
discard functionality as you've described it (you get to tell the sender
where to go in addition to refusing the message).
I'd like discard so, say, I can ignore certain people. I don't want to
reject their mail, I just want to ignore it.
--
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>