Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt

["Mark E. Mallett" <[e-mail]>]

I guess I am going to open this can of worms..

When the "refuse" extension was last discussed at length on this list,
it ended with talk about the interaction between reject and refuse,
whether the script writer really ought to care about the actual refusal
mechanism, and how to fall over between the two verbs (or even whether
two verbs was a good idea).  I thought that the concensus was that some
sort of unified action (where the user didn't really have to know
whether a notice was given at SMTP time or post-SMTP time) would be
best.  I may be looking back at that dialog with blinders on, but quotes
in the archive are pretty direct.

Anyway: my preference would be for a "reject" action by which the script
writer specifies that the message is not wanted, without having to know
which of two verbs to use.  This action would cause a reject/refusal at
the earliest possible point; it would have a default fallback behavior
that would happen if that point was not SMTP-time, and this behavior
could be overriden via some extended syntax (either a tagged option or a
code block).

The benefits of a unified approach:

 - existing scripts using "reject" would inherit SMTP-time refusal as
   soon as it was made available in the environment;

 - scripts would continue to work if the site's mail system
   architecture changes;

 - most users would not have to know or care that there were two kinds
   of refusal/rejection; they would know that their script would do
   the best thing supported by the implementation;

 - the whole thing about "this might not work if multiple recipients
   are given" wouldn't be important to the script writer.

Basically:

   reject [:discard/:keep/:notify] "reason";

where with no tagged argument, 5xx at SMTP time is done if possible, and
if not possible, a site-imposed default action would be taken (which
might be either "discard" or "keep" or "send a notification").  The
tagged argument, if given, would override the site-imposed default.
There would also be a section in the RFC directing implementors to
attempt to detect and inhibit notifications to probable forged
addresses.  One could get more elaborate, naturally, e.g. by being able
to specify the extended SMTP result code (as discussed on the list) or
by having a fallback option be "fileinto" .


Drawbacks of a unified approach that I can think of:

 - Any new syntax would have to be enabled via a new capability.  Here,
   I would say that ' require "refuse"; ' would enable the new syntax,
   but the new behavior (i.e., of attempting to turn away the message at
   SMTP time, with site-specific fallback action) would not require the
   new capability.  The new behavior would simply be specified in this
   draft.

 - If a Sieve script is invoked when "RCPT TO" is seen, various other
   Sieve facilities are not available (header tests, fileinto, etc).
   There may be a need for the script writer to be aware of this.  But I
   think that can be solved in ways outside the script itself, and this
   problem is also present in the other approach as well.

In the event that I am just whistling in the wind here, I also have
comments on the actual draft... see next rock.

mm