I would argue that there is a need, or at least desire, to have both "reject"
and "refuse".
For one thing, you can't internationalize "refuse". We have people who want to
ensure for some
more "friendly" bounces that the original sender will see some "friendly"
explanatory text. So they
want to use "reject" so that they can: (a) ensure that their own text is
presented to the original sending
user (SMTP rejection text, in contrast, may or may not end up getting presented
to the original sender),
and possibly (b) use another language/charset (language-appropriate subset of
UTF8) for their rejection
text, possibly customizing the choice of language/characters based on
characteristics of the message
being rejected.
But in other cases, with more "unfriendly" bounces, rejecting the message at
the SMTP level is more
desirable. When it's more important to limit load on or protect your own
server vs. being "friendly" to
the original sender, then "reject" can be more appealing.
I can therefore envision cases of Sieve scripts that might wish to use both.
Regards,
Kristin
kristin(_dot_)hubner(_at_)sun(_dot_)com
----- Original Message -----
From: Cyrus Daboo <daboo(_at_)cyrusoft(_dot_)com>
Date: Friday, February 13, 2004 7:59 am
Subject: Re: New Sieve extension "refuse" proposal -
draft-elvey-refuse-sieve-01h
Hi Matthew,
--On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey
(FM)"
<matthew(_at_)elvey(_dot_)fastmail(_dot_)fm> wrote:
| Hello, folks. Please review and provide feedback on the "refuse"
| extension, designed to mostly replace Sieve's "reject" command.
Question - is there any situation where you would want both reject
and
refuse available at the same time? i.e. couldn't we just get away
with an
extension that simply indicates that the existing reject command
will
actually run during the SMTP transaction and will generate an SMTP
error
instead of an MDN? Or, if modifying the base-spec reject behaviour
is
really not allowed in this way, how about having refuse do either
SMTP
error or MDN as appropriate for the system? That would mean that
users can
write one script using a single command and have it work on any
SIEVE
system, whether SIEVE runs at SMTP time or post-SMTP. I would hate
to have
to change reject<->refuse every time I moved or copied a script
across
different systems.
--
Cyrus Daboo