On Thu, 2005-08-18 at 15:06 -0400, Mark E. Mallett wrote:
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").
I would prefer an option to make reject "stop" if successful, so you
could simply do:
reject :refuse :stop "Don't send e-mail to this address";
fileinto "INBOX.old-address";
stop;
seems easier than to add all possible actions as options to reject :-).
clearly this requires a small change to the following text:
Implementations SHOULD prohibit reject when used with other
actions.
a reject without :refuse would always be successful, since it does best
effort: SMTP time or send bounce message.
we might not need a :stop, we could make :refuse work that way always,
but I think it is better to be explicit about it.
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.
right. I don't see how this is a drawback? a capability which implies
another would be a first for Sieve, but I think it is a natural thing to
do.
- 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.
this problem isn't specific to the unified approach.
In the event that I am just whistling in the wind here, I also have
comments on the actual draft... see next rock.
well, I agree with your views, at least.
--
Kjetil T.