Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 4 Jun 2004 08:29:13 -0400

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-

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 04 Jun 2004 12:20:34 -0700

>unavailable.  (You've identified one.)  As you say, existing scripts
What do you envision? I haven't thought of any others and don't think 
there are any.
We designed the spec consciously so that, e.g. MUAs can't implement 
"refuse".
In other words, if you want to <require "refuse">, tough, if your 
implementation can't handle it.
If it claims to, it's violating our spec.  We can't physically prevent 
this from happening though.
We state it strongly:

"A SIEVE implementation that cannot do so MUST NOT claim
  to support the refuse extension."

>what percentage this represents, I'd feel better if that were taken
This will happen if the implementation is defective (and in the listed 
exceptional case, which I'm not worried about).
I think what we've done already will prevent this from being a real problem.

>specify a preference for reject if for some reason they wanted to use
That's being much more cavalier with people's email than I'm comfortable 
with, especially if one is optimistic that we will have a pretty 
effective antispam solution in the fairly near future - effective enough 
to drive a bunch of them out of the business.
There's an RFC for unilaterally preventing joe jobs, and someone 
reinvented the same or came up with a similar solution at the recent 
ASRG MARID meeting.
I could look it up if you're interested. <comments to this point, and 
most others later are repeated from my email of 5/25 to which I haven't 
received a response(!?).>
For example, here's a problem: I admin a few mailing lists (verified 
opt-in, of course.)  One is political and has severe deliverability 
problems that I'm working to fix.  Not getting any indication that mail 
hasn't been delivered makes this task much harder.

The ideas below are good ideas for improving Sieve, but are out of scope 
for my draft.  It would be in scope for a new version of Sieve, and 
would require several extension specs be changed to work well with it.

I think we've made the best of a bad situation; don't see how we can 
improve the "refuse" spec.

>    if not refuse "This looks like spam" {
Yeah, this would be nice, but it's not something I'm able to take on.  
I'd support it.  IIRC, Sieve actions don't have return values.

>At any rate, those are some thoughts.

PPS I find your comments constructive and helpful, though my 
to-the-point comments and questions might make it seem otherwise.  Thanks.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 7 Jun 2004 01:14:25 -0400

> What do you envision? I haven't thought of any others and don't think 

a) All it takes is one such case for the point to apply.  The fact
that there is one at all is enough.

b) I alluded to some more broader cases and even gave a f'rinstance.
The key is "situationally unavailable."  In fact there are other
arguments that apply here that don't apply to (a).  I'll expand a
little below.

>  to support the refuse extension."

Well that's all very self-referential as an answer :-)

I'm suggesting that the spec should be adjusted to allow a best-effort
"refuse" with a fallback to another action, and your refutation is
that the spec doesn't allow it.  That's too circular of a way to
respond to the suggestion.

> with,

Actually it's the opposite of being cavalier: it's giving more options
to the script writer.  I'm trying to see how you classify it as
cavalier- perhaps you think I'm saying that the only action be
discard, and not the default one?  Figuring out what the best default
is is a matter that's best done before people start writing scripts.
Having a default doesn't preclude other deliberate actions.  I simply
suggest a default that encompasses the usual case; defaults constructed
in that way help minimize code and enhance clarity.

> especially if one is optimistic that we will have a pretty 

That would be nice.  Even if that comes to pass, "refuse" and other
actions will still be useful.

> received a response(!?).>

Sorry, maybe I wasn't clear.  I did respond- I said that any extended
back and forth discussion would be better on the list, and I promised
to restate my thoughts here.  Which I did (it took me a while, sorry).

Anyway, on to specifics about "situational unavailability" of "refuse."

Mainly I'm concerned not so much about individual scripts but about
script portability and overall system administration.  For language
growth I'd like to help ensure that scripts can be written in a way
that lets people move them from one environment to another without
having to completely rewrite them.  Unfortunately the "require" model,
while having a noble goal, tends to work against this.  With some
extensions (such as "spamtest"), there's not much that can be done
about it (other than having a way to conditionalize based on the
presence of cababilities, as I've said elsewhere).  But with something
like "refuse" I think there is- simply by allowing its best-effort use
with a fallback if it's unavailable.  Some cases:

a) Surely it would be good to encourage people to design their scripts
to use "refuse" now, even if the environment won't support it until
some time in the future.  When the environment does support it,
peoples' existing scripts would suddenly do better things.

b) On a server-wide administrative level, things change.  Imagine a
change to an SMTP server that makes "refuse" not work- either for
a short while, or for the long term.  Neither is hard to imagine.
This is what I had in mind when I said something about "refuse being
situationally unavailable."  Without a fallback capability, such
system-wide changes would be a nightmare.  

c) Similarly, one should allow for scripts to be pushed off to other
instances of mail servers which handle incoming mail for a large
environment, not all of which are architected the same.  

d) Part of designing language elements such as this is not having to
imagine every eventuality, but rather providing options that allow
flexibility in the face of currently-unknown future situations.
Planning for a best-attempt "refuse" with a fallback strikes me
as much better than an all-or-nothing "refuse" without one.

If SIEVE provided conditionals based on capabilities, there'd be no
need for this, and perhaps I wouldn't be suggesting it ('tho maybe I
would).  But it doesn't, and so I am.

Bottom line: I would prefer a "refuse if you can" kind of spec, for
all the reasons stated.  It would allow for more flexibility in
script writing, better script portability, better anticipation of
SMTP-time support for scripts now, and less headaches for system
administrators.

Yours,
-mm-