[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> >> For the former: the lemonade extension adds a reserved variable which
> >> I'm currently calling "IMAPSieve.cause". Its value is the action
> >> that caused the script to be run ("APPEND", "COPY", and so on). It
> >> occurs to me that it'll be awkward for scripts to have to wonder
> >> what the absence of that variable means. Wouldn't it be a good idea
> >> to have a reserved namespace called "Sieve.", and to have a variable
> >> called "Sieve.cause" that's ALWAYS available if variables are
> >> supported? In the normal case, its value would be "DELIVERY", and
> >> extensions like mine can specify other values. (This might also add
> >> an IANA item....)
> > okay, so you think this namespace should be defined in the variables
> > draft? I'm not too wild with the idea, since I really wanted -08
> > which I submitted yesterday to finally reach RFC status.
> Oh, well. So it can be the -09 version that does; is that such a big
Frankly, yes. We need to finish up this spec and get it out the door. The list
of potential additions of this general sort is for all intents and purposes
> > I would expect the
> > extension to be required by anyone wanting to inspect that variable,
> > and so I don't see much benefit to making it a globally available
> > variable.
> The problem is that when a script is written to ask "Why did I get
> called?", it will have to assume that if it doesn't know, it's because
> it got called by "mail delivery". Since we're at a point where we
> could get that modified in the variables draft now, I think we should.
I'm dubious about the notion that there will be lots of scripts intended to be
run in a variety of different contexts that need to test this sort of thing.
However, I have no objection to making such a test available, although I think
the right way to do it is as a separate extension and test, not as a magic
variable. For one thing, this means that in order for such a test to work you
have to have the variables extension, and I worry that variables may not be
implemented or enabled in some performance-sensitive environments.
> So I'm suggesting that the variables spec define a base namespace (I'm
> suggesting "Sieve."). And I'm suggesting that the variables spec
> define a variable that MUST be set (I'm suggesting "Sieve.cause",
"place" seems to me to be a more natural name for this, but I'm not wedded
to any particular term either.
> I'm not particular about the name) that gives the reason the script was
> called. I'm suggesting that the value for mail delivery be "DELIVERY".
> And I'm suggesting that the variables spec say that other extensions
> may add other values, if they create other causes for having Sieve
> scripts called. It seems a simple change, and a useful one in the long
I don't necessarily see running sieves in different environments as
necessitating additional extensions. It seems to me a simple "places" registry
would be sufficient. And it probably should allow for vendor-supplied places
since I suspect there will be non-standard uses of sieve. (In fact I know there
will be because we already have two in our product and another two are
I also think additional environmental information might be useful to provide
to script. Indeed, I suspect that knowing, say, the name of the system you're
running on might be even more useful to scripts than being able to distinguish
between delivery and other places sieves are used.
I would therefore suggest an extension specifying an "environment" test as a
better approach. I suspect we can come up with half a dozen things such a test
could operate on.