[Top] [All Lists]

Re: Discard vs. DSN

1999-03-23 15:46:27
At 3:56 PM -0600 3/23/99, Pete Resnick wrote:

The problem arises if an implementation cannot implement discard without generating a NDN.

Then it hasn't implemented discard; it has implemented reject. As far as my reading of the draft goes, reject = discard + DSN and discard = fileinto "/dev/null". The inability to implement discard without DSN is a failure to implement properly.

I was reading 'reject' as delete & generate DSN with user-specified text. If honoring the user-specified text is optional, then the only difference between 'reject' and 'discard' is indeed that 'discard' does not generate a DSN.

Randy, maybe you can explain why your implementation can't implement either reject - DSN or fileinto "/dev/null". I would like to prevent DSNs with discards at all costs.

I didn't say my implementation couldn't. I said in one environment in which my implementation runs this is difficult. In this particular environment, my Sieve implementation operates as a delivery-time plug-in. If the plug-in tells the mail system not to deliver the message, it generates a standard DSN. This means I can't add the user-supplied text to the DSN, or avoid the DSN generation (unless the script causes delivery into a server 'trash' mailbox, which is what I do in my own personal script, which filters all my mail).

So which is it that I haven't implemented: 'discard' or 'reject'? I was assuming I had implemented 'discard' and not 'reject', but perhaps it is the other way around.

If the consensus is that this particular implementation and environment combination just isn't Sieve compliant, I can live with that. I don't know how common or uncommon the constraints of this environment are.

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