--On Wednesday, August 11, 2004 4:30 PM -0700 Matthew Elvey
Allowing the user to specify the response code is a bad idea -
featuritits. It provides very little to no benefit, violates KISS, and
What if the user specifies 200 as the response code? :)
I want refuse to have all the features it must have, and no more.
Actually we are talking about enhanced error codes here, so the user cannot
touch the response code (i.e. it will always be a 5xx response).
If you want to really apply KISS then I would argue that the sieve script
shouldn't even have a way to set the SMTP error text, let alone the
response or enhanced codes. Why not leave the SMTP error message to the
SMTP server implementation? That eliminates the need to have two text
parameters for ascii and non-ascii - you just need the one for 'non-ascii'
which only gets used for DSN/MDN.
I also strongly dislike the idea of changing the behaviour of the command
based on whether non-ascii text is present in the reason string or not.
Here is my suggestion in a little bit more detail:
Relax the behaviour of the reject command to allow it to also be used for
SMTP errors and to allow generation of DSNs in addition to MDNs as needed.
New syntax would be:
reject [":auto" / ":dsn" / ":mdn"] <reason: string>
":auto" - the sieve implementation decides which of SMTP error, DSN
or MDN is appropriate to use when the action is executed. This is
also the default behaviour if none of the optional tags is
specified. The 'reason' string is used in a DSN or MDN if one of
those is generated. The 'reason' string is not used in any SMTP error.
":dsn" - a DSN is always generated when the reject action is
executed. The 'reason' string is used in the DSN.
":mdn" - a MDN is always generated when the reject action is
executed. The 'reason' string is used in the MDN.
This deals with the KISS issue and having the command do different things
based on ascii/non-ascii in reason. A user has the option to explicitly
require a DSN or MDN if they know they always want the reason string to get
back to the sender, bypassing the possibility of a meaningless SMTP error.