This is a fine draft. I have a few musings that I sent to Matthew
earlier that I'll twist around a little here- don't mistake these as
objections though, there's really not a lot to object to. Not sure I
made that clear earlier. But I do think there are some points to
raise, if not ponder.
In this draft there are some great justifications for script writers
to use "refuse" rather than "reject. However there's this:
There is an exception when a single message has multiple SMTP
recipients, and at least one but not all of them are refusing delivery
(whether the refusal is caused by execution of a Sieve "refuse" or for
another reason). In this case, the server MUST accept the message and
generate DSNs for all recipients that are refusing it.
This may not be the only fallback case. I could envision other cases
where smtp-time "refuse" was generally implemented, but situationally
unavailable. (You've identified one.) As you say, existing scripts
should continue to run.
I see a conundrum, in that script writers will feel assured that by
using "refuse" they will not be generating bounces. Without "refuse" a
conscientious script writer would probably have used "discard" or
"fileinto" -- anything other than "reject." However, in the presence
of a "refuse" option, the same conscientious script writer will likely
use "refuse." So under some conditions the very presence of this
option could increase the likelihood of generating rejects. No matter
what percentage this represents, I'd feel better if that were taken
into account.
I'd take that into account by being able to specify a fallback option
should "refuse" not be present. And if you give the ability to have a
fallback option, you could make the default fallback action be
"discard" rather than "reject" -- and force the script writer to
specify a preference for reject if for some reason they wanted to use
it.
I don't even think that's the best alternative: better would be some
more systemic-level enhancements to SIEVE that would allow certain
conditions to be tested and operated on. For example, being able to
test whether "refuse" succeeded would help:
if not refuse "This looks like spam" {
discard;
}
Less disruptive systemic changes could be devised; for example being
able to test the status of the implicit keep flag:
refuse "This looks like spam";
if not ikeep { discard; }
Or something like a "stop" if successful:
refuse :stop "This looks like spam";
discard;
This branches into a train of thought about general script portability:
I've mentioned in the past that it would be nice to be able to have
conditions depending on what mode a script was running in, or what
capabilities were supported, so that scripts could continue to run in
the face of changing environments. ("changing environments" was in
fact one of the cases I had in mind above, when I mentioned that there
could be other situations in which "refuse" is unavailable. One has
to think of the system administration too.) Other than that, I'm
obviously getting farther away from "refuse" -- but I often think that
some broader thinking about SIEVE extensions would help keep the
language more whole in the face of these optional capabilities.
(That's rather brusque but I don't want to go on here too long..)
At any rate, those are some thoughts.
-mm-