I like it. Will implement.
Well, to be honest, we implemented :hours not long after vacation was specified
in order to be able to replace an existing LDAP-based autoreply facility.
Adding :seconds is of course quite doable for us as well, so this seems like a
perfectly reasonable extension to me.
Cool.
I agree that :seconds is better than :time.
Me, too. I thought about that when I submitted it, but wound up
sticking with "time". On the queue for changing.
Agreed. Do we also want to change the extension name to, say, vacation-seconds?
I'd prefer the change over the original but would be OK with either name.
IMO, if a script requires vacation-time but not vacation, that's an error
and the managesieve may reject the script, or the runtime may fail it.
I agree, and that's what I said to Dilyan when he mentioned that to me
privately. But I also suggested that he post it to the mailing list,
to see what others think.
Well, the obvious existing model for this sort of thing is spamtest and
spamtestplus. In that case specifying spamtestplus implicitly sets spamtest.
The rationale, as I recall, is that since spamtestplus makes no sense
without spamtest, why make the require clause even longer than it needs to be?
if there's a reason not to follow that approach here I don't see it.
That said, if we decide that vacation-time (or whatever we call it) not
implicitly set vacation, I'd be opposed to having vacation-time by itself be an
error. I see no harm in saying require "vacation-test" by itself as long as
there's no use of vacaation in the script.
Dilyan says...
State that replies are sent by default with "From" as the envelope
recipient (when feasible) currently receiving the message.
No; this draft will make no incompatible changes to the base Vacation
protocol.
Unless, of course, the working group really wants to.
First of all, since Sieves aren't always evaluated by SMTP servers prior to
final delivery and may in fact be evaluated by MUAs after final delivery, the
envelope recipient address may not be available for use in this way. As such,
we cannot possibly impose such a requirement without also restricting the
domain within which the extension can be used, probably to an unacceptable
degree.
In any case, RFC 5230 section 5.5 says:
Unless explicitly overridden with a :from parameter, the From field
SHOULD be set to the address of the owner of the Sieve script.
This language was chosen for a reason: The neceessary information is always
available, and in most cases is the same as the envelope recipient.
In cases where a Sieve owner has multiple addresses I understand the desire
for the message to come from whatever address the originator used in order
to lessen confusion, but the reality is that such a requirement cannot possibly
be met. In addition to the MUA case where the actual recipient address is
often no longer available, there's also the case where a message has been
forwarded through one or more aliases, possibly including aliases outside
the administrative domain. So even tricks like:
require ["envelope", "vacation", "variables"];
if envelope :matches "to" "*" {set "rcptto" "${0}";}
else {set "rcptto"" "error(_at_)error";}
vacation :from "${rcptto}" ...
which would meet the technical MUST being proposed (by using an extension often
isn't available in an MUA implementation) but doesn't actually address what I
believe is the underling intent of the requirement.
The bottom line is that this is a can of worms I'd really rather not open.
The other question is if the working group will adopt this. Should
the updated version (changing "time" to "seconds") become
draft-ietf-sieve-vacation-seconds-00 ?
WFM.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve