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.