On Fri, Jun 04, 2004 at 12:20:34PM -0700, Matthew Elvey wrote:
On 6/4/2004 5:29 AM, Mark E. Mallett sent forth electrons to convey:
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.
What do you envision? I haven't thought of any others and don't think
there are any.
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.
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."
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.
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.
That's being much more cavalier with people's email than I'm comfortable
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
effective antispam solution in the fairly near future - effective enough
to drive a bunch of them out of the business.
That would be nice. Even if that comes to pass, "refuse" and other
actions will still be useful.
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(!?).>
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-