On 6/4/2004 5:29 AM, Mark E. Mallett sent forth electrons to convey:
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.
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."
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.
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.
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, 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.
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;
}
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.
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-
PPS I find your comments constructive and helpful, though my
to-the-point comments and questions might make it seem otherwise. Thanks.