Matthew Elvey (FM) wrote:
> I like Cyrus' idea of the refuse extension simply changing the semantics
> of "reject" for several reasons.
> It's the best way to make mass search-and-replace unnecessary when
> switching from an MTA that can support "refuse" to an MUA that can't.
> It makes it easier for folks to switch to using "refuse".
We are basically in agreement.
The only thing that concerns me is that currently "refuse" might
generate a DSN, while "reject" is required to generate an MDN.
Does it matter that the behavior changes when a Sieve script is moved
between MTA and MUA or vice versa?
I don't remember now why the Seive RFC was written to use MDNs.
It is because MDNs are the only generally appropriate mechanism that both MTAs
and MUAs can legitimately use. Remember that the place where sieves get applied
is left intentionally fuzzy; it can be anything from just before the time of
final delivery to much later. A DSN is not an appropriate construct to use
after final delivery: The necessary information to construct the DSN may not be
available, it looks bad if final delivery produced a success DSN only to be
followed by a subsequent faileded DSN, etc.
You can only get away with using DSNs for this if you restrict the time of
application of the sieve to just before or during final delivery.
> I can't think of a situation where you would want both reject and refuse
> available at the same time.
The main problem with the idea of relaxing the rules for reject to allow it to
generate DSNs or a 5xy error when running on an MTA is that a script will
behave in a fairly different way depending on whether you run it on an MUA or a
MTA. I really don't like this. And if you use a require tag to mean "change the
semantics of reject to refuse" and make it so the tag only works on MTAs,
you're back to having to change the scripts when you move them around. Its just
generally cleaner to have two different actions here and have one of them be
MTA-only.
Ned