Subject: Re: [sieve] New Version Notification for draft-george-sieve-vacation-time-00

From: Дилян Палаузов <[email-masked]>
Date: Wed, 03 Feb 2010 15:15:08 +0100

Hello,

 > The new draft is here:
 > http://www.ietf.org/id/draft-george-sieve-vacation-time-00.txt

My suggestions:
  - Rename "time" parameter to "seconds".
Motivation: the number of days follows after the parameter with the name 
"days". Similarly the number of seconds shall follow the parameter named 
"seconds", not "time".

  - Co-existence with "vacation" (probably section "IANA Considerations")
Clarify if
   require ["vacaion-time"]
on its own is valid.  More concrete, I will appreciate if it is made 
valid, meaning that require ["validation-time"] implies that requirement 
for "vacation" is also requested.

  - State that replies are sent by default with "From" as the envelope 
recipient (when feasible) currently receiving the message.

This updates section 5.4. of RFC 5230.  See discussion on (by that time) 
[email-masked] from 03.07.2007.

If you choose to incorporate the last two points, it will make the 
behaviour of vacation slightly different, depending on if it is required 
with "vacation" or "vacation-time", which will make practically 
incorrect the usage of 'require ["vacation", "vacation-time"];'.

Със здраве,
   Дилян

On 1/30/2010 3:46 PM, Barry Leiba wrote:
> Robins George and I have just submitted the following draft, which
> we'd like the Sieve working group to review and consider adopting.
> This comes from work with Alexey on an auto-reply draft (
> http://tools.ietf.org/id/draft-george-sieve-autoreply-00.txt ), which
> will also be updated soon.
>
> The new draft is here:
> http://www.ietf.org/id/draft-george-sieve-vacation-time-00.txt
>
> ...and the details are here:
>
> On Sat, Jan 30, 2010 at 09:34, IETF I-D Submission Tool
> <[email-masked]>  wrote:
>>
>> A new version of I-D, draft-george-sieve-vacation-time-00.txt has been successfuly
>> submitted by Barry Leiba and posted to the IETF repository.
>>
>> Filename:        draft-george-sieve-vacation-time
>> Revision:        00
>> Title:           Sieve Vacation Extension: Time parameter
>> Creation_date:   2010-01-30
>> WG ID:           Independent Submission
>> Number_of_pages: 5
>>
>> Abstract:
>> This document describes a further extension to the Sieve Vacation
>> extension, allowing multiple auto-replies to the same sender in a
>> single day by adding a ":time" parameter.
>
> Barry
> _______________________________________________
> sieve mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sieve

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 3 Feb 2010 15:36:42 +0100

I like it. Will implement.

I agree that :seconds is better than :time.

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.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Feb 2010 16:18:45 -0500

> I like it. Will implement.

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.

> 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.

Dilyan says...
> State that replies are sent by default with "From" as the envelope

No; this draft will make no incompatible changes to the base Vacation protocol.
Unless, of course, the working group really wants to.

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 ?

Barry

Barry

---

From: [email-masked]
Date: Wed, 03 Feb 2010 19:58:38 -0800 (PST)

> > 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.

> 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.

> 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.

> 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@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.

> draft-ietf-sieve-vacation-seconds-00 ?

WFM.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 4 Feb 2010 09:40:40 +0100

> The bottom line is that this is a can of worms I'd really rather not open.

AOL. But if the main vacation specification were to be updated (fix 
errata, proceed to draft, what have you), I'd be happy to see a sentence 
like this:

"If the sieve processor recognises an address belonging to the sieve 
script's owner in the To or Cc fields, then it's better to use that 
address for the vacation reply than any other addresses the script owner 
may also have."

I think that's what my code does, so evidently I thought this behaviour 
permitted by the existing RFC. But I wouldn't mind saying it explicitly.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Feb 2010 09:43:12 +0000

Arnt Gulbrandsen wrote:

> errata, proceed to draft, what have you), I'd be happy to see a 
> sentence like this:
>
> address for the vacation reply than any other addresses the script 
> owner may also have."
>
> I think that's what my code does, so evidently I thought this 
> behaviour permitted by the existing RFC. But I wouldn't mind saying it 
> explicitly.

My code does the same.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Feb 2010 10:07:21 -0500

> if there's a reason not to follow that approach here I don't see it.

OK, I'll buy that.  Good.  So for the next version:

1. I will change ":time" to ":seconds".

2. I will change "vacation-time" to "vacation-seconds".

3. I will add text saying that "vacation-seconds" implies "vacation",
and that a script that includes "vacation-time" in the "require" list
MAY omit "vacation" from the list.

>> draft-ietf-sieve-vacation-seconds-00 ?

I'll hold off on updating the draft for a day or two, and if the
chairs tell me that they have approved
"draft-ietf-sieve-vacation-seconds" as a working group draft, I will
submit it that way.  Otherwise, I'll submit an -01 version with the
current name.

Other comments from participants (or chairs)?

Barry

---

From: Aaron Stone <[email-masked]>
Date: Thu, 4 Feb 2010 10:33:19 -0800

> 1. I will change ":time" to ":seconds".

Personal comments:

Since Ned has :hours, and here we're talking about :seconds, why not
also add :minutes?

> 2. I will change "vacation-time" to "vacation-seconds".

Thought experiment: what if :time referred to a time of day? All
vacation notices would be batched and sent at that time of day. What
might be a use case for this?

> MAY omit "vacation" from the list.

+1

> submit it that way.  Otherwise, I'll submit an -01 version with the

Chair's comment:
I'm in general favor of making it a WG document, but I'd like to think
out if there are more changes to vacation that anybody has in mind.
Should we open an "evacation" can of worms? (Probably not.) Should we
consider that a couple of vacation extensions might come together and
should be profiled as "vacation2" or something like that?

> Other comments from participants (or chairs)?

I like it!

Aaron

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Feb 2010 14:01:20 -0500

> Since Ned has :hours, and here we're talking about :seconds, why not

I'm happy to add :minutes and :hours to the draft if we think there's
value, but it seems to add unnecessary stuff.  :seconds can cover all
the minutes and hours we'd need.  At some level, ":hours 4" looks
nicer than ":seconds 14400", but they really are the same thing.  And
something like ":hours 1 :minutes 30" seems to work out better as
simply ":seconds 5400".

Ned?

> might be a use case for this?

Mm.  ":time 00:00:00" to send the (de-duped) batch at midnight.  I
can't really see the need for that.  For the most part, you'd want the
first notice ASAP, and just have duplicates suppressed after that,
until the interval expires.

The only reason I could see for delaying even the first notice until a
designated time would be if you wanted to be able to cancel them if
something has changed.  Like, maybe, "Don't tell people I'm gone
unless I'm not back by 3:00."  Even with that, what happens when you
get back at 3:01?  No, that just seems like a solution no one's asked
for nor needs.

> should be profiled as "vacation2" or something like that?

I'd be amenable to expanding the scope of this, but that would be at
the expense of delays caused by other stuff that might b harder.  This
is a simple change, and is needed (as Ned points out) if we want to
make more general auto-replies work through "vacation".  I'd rather
have this on its own, and then have "vacation2", if it happens,
incorporate this as a feature.

Barry

(P.S.  Please review notify-presence, as well, with the same thoughts
in mind (I'm about to post an update to that one.)

---

From: Derek Diget <[email-masked]>
Date: Thu, 04 Feb 2010 18:44:28 -0500 (EST)

On Feb 4, 2010 at 14:01 -0500, Barry Leiba wrote:
=>
=>> Thought experiment: what if :time referred to a time of day? All
=>> vacation notices would be batched and sent at that time of day. What
=>> might be a use case for this?
=>
=>Mm.  ":time 00:00:00" to send the (de-duped) batch at midnight.  I
=>can't really see the need for that.  For the most part, you'd want the
=>first notice ASAP, and just have duplicates suppressed after that,
=>until the interval expires.
=>
=>The only reason I could see for delaying even the first notice until a
=>designated time would be if you wanted to be able to cancel them if
=>something has changed.  Like, maybe, "Don't tell people I'm gone
=>unless I'm not back by 3:00."  Even with that, what happens when you
=>get back at 3:01?  No, that just seems like a solution no one's asked
=>for nor needs.

De-lurking...I am not the experts you all are.

Should there be something said on how implementations handle deltas to the 
:time (or :seconds) window with respect to the previous response history 
database?  Does a change to the sieve remove/wipe the previous response 
tracking history?  I don't see any mention of that in RFC 5230.  For 
example...

Fred has a vacation rule with responses set for every 10800 seconds (he 
is in a morning meeting).  Wilma sends a message to Fred at 10:30 and 
receives a vacation response since it is the first message she has sent 
to Fred that day.  Fred gets out of his meeting and modifies his 
vacation sieve at 11:50 as he heads out to lunch with a :time now set to 
5400.  (He might or might not change the reason string.)  Wilma sends 
another message to Fred at 12:00 that would "match" her first message 
and not have caused a response under the original rule.  Does Fred's 
modification of the filter cause the sieve system to remove/wipe/clean 
its response tracking history and thus cause a new response to Wilma's 
12:00 message?

The reason I ask is that I see with user's being able to set vacation 
replies using seconds they might connect their 
Twitter/MySpace/Facebook/etc account status with vacation rules.  They 
update their ${SOCIALSITE} status and it updates their vacation sieve 
rule with their new status message. :) or :( depending our the side of 
fence you stand.  And I could see same thing in the IM/presence world, 
too.

If this is addressed somewhere sorry for wasting your time.

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: Aaron Stone <[email-masked]>
Date: Thu, 4 Feb 2010 17:43:59 -0800

> De-lurking...I am not the experts you all are.

Welcome!

> If this is addressed somewhere sorry for wasting your time.

The question of when to respond is addressed, but your question is
entirely valid. In short, no, the response tracker should be separate
from the script.

>From RFC 5230, Section 4.2, "Previous Response Tracking":
   ...
   Tracking is not just per address, but must also take the vacation
   response itself into account.  A script writer might, for example,
   have a vacation action that will send a general notice only once in
   any two-week period.  However, even if a sender has received this
   general notice, it may be important to send a specific notice when a
   message about something timely or something specific has been
   detected.

   A particular vacation response can be identified in one of two ways.
   The first way is via an explicit :handle argument, which attaches a
   name to the response.  All vacation statements that use the same
   handle will be considered the same response for tracking purposes.

   The second way is via a synthesis of the :subject, :from, :mime, and
   reason vacation command arguments.  All vacation actions that do not
   contain an explicit handle and that use an identical combination of
   these arguments are considered the same for tracking purposes.
   ...

In the "second way" paragraph, the parameters :subject, :from, :mime,
and the reason are specified as the ones to use in constructing a
tracking handle. Omitted from the list is :days, probably for exactly
the reason you're asking about. I think what most implementations will
do is (implementers please correct me!):

  Receive message
  Run the sieve on the message
     Vacation action:
        Calculate the handle for the action
        Look up the handle - recipient pair last response time
        Is the current time - last response > :days?
            Yes: send a vacation response
            No: take no action

Later in Section 4.2:
   ...
   Implementations are free to limit the number of remembered responses;
   however, the limit MUST NOT be less than 1000.  When limiting the
   number of tracked responses, implementations SHOULD discard the
   oldest ones first.

No mention is made of keeping or wiping the response tracking log when
the sieve is updated, but it reads like we're just assuming that you
wouldn't do that :)

Cheers,
Aaron

---

From: [email-masked]
Date: Thu, 04 Feb 2010 18:48:45 -0800 (PST)

> address for the vacation reply than any other addresses the script owner

Sounds like a good idea to me.

> permitted by the existing RFC. But I wouldn't mind saying it explicitly.

It's certainly permitted, but not sppecifically suggested.

				Ned

---

From: [email-masked]
Date: Thu, 04 Feb 2010 20:24:57 -0800 (PST)

> Ned?

I agree. Seconds is sufficient; I don't see any need to formally define
:hours (it's only used internally by our product anyhow).

> until the interval expires.

I have to agree, although I note that we could, if we wanted to, define
this in terms of the FUTURERELEASE extension.

But perhaps a better place for that would be with notify mailto;, not vacation.

> get back at 3:01?  No, that just seems like a solution no one's asked

There's also the issue that cancellations of this sort may be very difficult
to implement. I would certainly want it to be a separate extension in any case.

> incorporate this as a feature.

Agreed as well.

> in mind (I'm about to post an update to that one.)

I was planning to do that. Unfortunately this whole SUNW->ORCL injection thing
has me a tad preoccupied :-)

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 5 Feb 2010 10:49:25 +0100

> its response tracking history and thus cause a new response to Wilma's

No. But if no response was sent at 10:30, then one will be sent at 
12:00: _Sending_ the messages is what triggers the suppression.

Suppose Fred changes the reply body. In that case, Wilma gets a reply at 
10:31 saying "I'm in a meeting until about 11:30" (or whatever time Fred 
guesses the meeting will end) and at 12:01 she gets "I'm at lunch until 
13:20". Sieve chooses to send both, since the reply body is different. 
(Fred could override that.) Fred's working day is shot, but Sieve is 
doing fairly well.

The other case is that Fred doesn't change the reply body. In that case, 
Wilma gets a reply about 10:31 saying "I'm in a meeting until 11:30" or 
just "I'm in a meeting", no reply at 12:01, and when Fred returns from 
lunch about 13:20, he reads her mail and may reply. Wilma may be a 
little angry, but it was Fred who misled her, not Sieve.

If Sieve had reset the reply suppressor at 11:50, Sieve would send 
another mail at 12:01 saying "I'm in a meeting until 11:30", and I don't 
think Wilma would be any happier.

AFAICT, Sieve is doing acceptably. But for these short absences, it's 
important to say when you expect to be back.

Arnt

---

From: [email-masked]
Date: Fri, 05 Feb 2010 14:00:11 -0800 (PST)

> tracking history?  I don't see any mention of that in RFC 5230.  For

I agree completelhy with what Arnt said, but I thought I should point out
that this is covered in RFC 5230 section 4.2. In sumnmary, responses are
tracked on the basis of both the message content and recipient. There's the
further nuance that the content that's tracked is what's there *before*
variable subs.

As for how this would interact with a hypothetical hold-until sort of
capability, I really haven't thought it all the way through, but there's
definitely an interaction, and it's an ugly one: Ideally you'd want the
duplication check done at the point where the hold is over. But in order
to get the interaction with variables right you'd have to save both the
expanded and unexpanded message for use in this comparision.

Now, you can probably cheat by just storing the hash, but in my implementation
at least we do this check as part of Sieve evaluation. I'm not eacfly sure how
we'd arrange to defer this check, but it most certainly is no longer an obvious
"just use FUTURERELEASE" thing now.

				Ned

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 06 Feb 2010 16:23:15 +0100

Hello,

A propos the default sending address of vacation messages:

> domain within which the extension can be used, probably to an unacceptable

Vacation responses are sent if it is recognized that the current 
recipient is mentioned in To/CC/Bcc/Resent-To/Resent-Cc/Resend-Bcc 
headers.  This recognition matches the known addresses of the recipients 
(mailbox name and everything mentioned in :addresses) towards the 
To/CC.. headers.  If a match is found, then the vacation is sent... 
using the found address in the From header.

My idea was to send by default (vacation without :from parameter) the 
vacations From the address of the recipient, not From the address of the 
current mailbox.  Even if the SMTP envelope is not available at the time 
the sieve script is evaluated, the engine can still figure out the 
suggested From address, as indicated above.

> be met.

Considering the above way of determining the From address, why cannot 
the requirement

be met?

Can the variable expansion be explicitly disabled in the :from parameter 
of vacation?

Със здраве,
   Дилян

---

From: Barry Leiba <[email-masked]>
Date: Sat, 6 Feb 2010 11:52:32 -0500

> Considering the above way of determining the From address, why cannot the
> requirement
>

A few of us have already expressed preference for Arnt's text:
"If the sieve processor recognises an address belonging to the sieve
script's owner in the To or Cc fields, then it's better to use that
address for the vacation reply than any other addresses the script
owner may also have."

Dilyan, would you not like that text, or something similar to it?  I
think it's basically what you're asking for also, yes?

I think we can submit that text as a clarification to the existing
Vacation RFC, through the errata process.

Barry

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 06 Feb 2010 18:39:27 +0100

Hello Barry,

The proposed text is fine for me.  I just couldn't get the 
(intermediate) argument of Ned from 04. February.

Със здраве,
   Дилян

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 6 Feb 2010 16:46:41 +0100

>    SHOULD be set to the address of the owner of the Sieve script.

Not sure when I'll get around to it, but I do mean to someday implement 
group-wide and system-wide sieves, ie. sieves written by someone, 
processing someone else's mail. I don't understand what that SHOULD 
means in that context.

Arnt

---

From: Aaron Stone <[email-masked]>
Date: Sat, 6 Feb 2010 09:56:12 -0800

2010/2/6 Arnt Gulbrandsen <[email-masked]>:
> group-wide and system-wide sieves, ie. sieves written by someone, processing
> someone else's mail. I don't understand what that SHOULD means in that
> context.

Event in that context, I'd still infer address based on the recipient
-- the system level script should still know whose mailbox the message
will be delivered to.

Aaron

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 6 Feb 2010 19:04:37 +0100

> -- the system level script should still know whose mailbox the message

So would I. I don't think 2119-esque words should tell me to do anything else.

Arnt

---

From: Aaron Stone <[email-masked]>
Date: Sat, 6 Feb 2010 10:12:31 -0800

> So would I. I don't think 2119-esque words should tell me to do anything else.

Wait, I'm confused. Is it the SHOULD itself that you disagree with, or
that the text sets up confusion for sieves outside of the context of a
user's own sieve?

Aaron

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 6 Feb 2010 19:20:44 +0100

Aaron Stone writes:
> that the text sets up confusion for sieves outside of the context of 
> a user's own sieve?

IMO that particular confusion is OK. There's lots of text that assumes 
the message recipient owns the sieve script already. I just don't want 
to add a SHOULD that assumes so.

In general I appreciate simple text, and will often choose readability 
over exact accuracy. But SHOULDs and MUSTS should be accurate rather 
than readable.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Sat, 6 Feb 2010 15:46:40 -0500

...
> Vacation RFC, through the errata process.

Note that Arnt's text does not have any normative language, no 2119
words, in it.  I'm proposing that we add informative text, though an
erratum, that suggests a good way to determine what address to use.

Good implementations will take that into account.  But no one's saying
SHOULD or MUST, here.

Shall I submit an erratum against RFC 5230?  I'll appreciate a couple
of "+1", but in the absence of any "-1" I'll do it in a couple of
days.

Barry

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 6 Feb 2010 21:51:48 +0100

> of "+1", but in the absence of any "-1" I'll do it in a couple of 

If anyone says +1, I'll +1 too. But for me it's really just a matter of 
making minor issues go away so that attention can float towards major 
issues.

(This is (starting now) known as "getting the bikeshed painted".)

Arnt

---

From: [email-masked]
Date: Sat, 06 Feb 2010 10:06:40 -0800 (PST)

> Vacation RFC, through the errata process.

We can try, but if recent experiences by others are any indication, this is
unlikely to be accepted as an erratum because it's making a new
recommendation, not correcting an error. There is increasing concern that
the errata process is being used to bypass proper standards review.

I think this is a reasonable change to make, but I'd rather make it in a
revision, not an errata.

				Ned

---

From: [email-masked]
Date: Sat, 06 Feb 2010 15:18:25 -0800 (PST)

> > someone else's mail. I don't understand what that SHOULD means in that

This really isn't that hard. We've had user sieve sieves, channel sieves,
system-wide sieves, domain sieves, head of household sieves, mailing list
sieves, and various other sorts. But in every case there's a fairly obvious
choice for an owner address, e.g,. for a domain sieve it's the domain
postmaster and if there isn't one of those, the system postmaster.

The tricky thing in a multiple sieve environment isn't figuring out who owns
the sieve but rather how to combine the results of multiple sieves. Jutta
Degener's long-expirted multisieve draft laid out the approach we follow, more
or less.

> -- the system level script should still know whose mailbox the message

IMO that's a *really* bad idea. You're forging mail when you do this.

				Ned

---

From: [email-masked]
Date: Sat, 06 Feb 2010 15:26:26 -0800 (PST)

> using the found address in the From header.

Not necessarily. See the :addresses parameter. And before you say that messages
should be sent willy-nilly using the value of an addresses parameter, think for
a moment about things like sender-id and DKIM.

> suggested From address, as indicated above.

Not true. See above.

> be met?

Of course it can, and this is why the RFC is worded the way it is instead of
saying that the message should, in the absence of a :from parameter, be
sent from the address of whatever matched in To/CC/Bcc.

Again, I have no problem with the text being amended to say that it is best to
use the variant of the owner's address that matched in  To/CC/Bcc if possibe. I
would strongly object to saying that whatever address matched SHOULD be used.

> Can the variable expansion be explicitly disabled in the :from parameter

I considered this when the RFC was written, but I think it is neither necessary
nor sufficient. There are cases like the selection of a subaddress value where
variables could be useful, and not having variables doesn't prevent one from
using this mechanism to forge mail. That's why the RFC leaves the question
of permission checks on :from up to the implementation.

				Ned

---

From: Aaron Stone <[email-masked]>
Date: Sat, 6 Feb 2010 15:41:58 -0800

> I think this is a reasonable change to make, but I'd rather make it in a

Is there a common "things that might get changed in the next revision"
tracker? I've seen different working groups use all sorts of outside
trackers; having one in-house might be nice.

Aaron

---

From: Aaron Stone <[email-masked]>
Date: Sat, 6 Feb 2010 15:46:16 -0800

> IMO that's a *really* bad idea. You're forging mail when you do this.

Hmm. Fair point. If a system sieve were to use the vacation mechanism
to report that a user has been suspended, or a mailbox is over quota,
etc., the reply ought to come from a system address. Arnt, did you
have another use case in mind? (And is this a reasonable issue to
discuss or just a rathole to discuss the depth of?)

Aaron

---

From: [email-masked]
Date: Sat, 06 Feb 2010 16:43:08 -0800 (PST)

> trackers; having one in-house might be nice.

Sure, see for example:

    http://trac.tools.ietf.org/wg/yam/trac/report/1

There's even one set up for the Sieve WG already;

    http://trac.tools.ietf.org/wg/sieve/trac/report/1

All you have to do is use it. You do have to create a login account first, but
that's simple enough.

				Ned

P.S. I'm a believer in using issuer trackers for code but i think the jury is
out on using them for document development in the IETF. That's no reason not to
try them, however.

---

From: [email-masked]
Date: Sat, 06 Feb 2010 17:01:37 -0800 (PST)

> have another use case in mind?

Always remember that :from can be used to override the default, and if need be
you can use variables to fill in the from field from the original message. And
presumably any persmissions check would be fairly permissive for a system-level
Sieve.

> (And is this a reasonable issue to

Well, it does appear that the WG has opted for the include file appproach
rather than the multisieve approach for standardization. (I'm not saying it's
either-or here, but there's considerable overlap in the functionality they
provide.)

I'm not a big fan of the include approach, perhaps because I've spent way too
much time fighting with *&^%*&^% C and C++ system includes when dealing with
multiple platforms. But that's just a personal bias.

OTOH, it's not like we've been inundated with WG traffic over the past year...

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Sat, 6 Feb 2010 22:30:41 -0500

> I think this is a reasonable change to make, but I'd rather make it in a

Submitting an errata report doesn't necessarily result in "accepted";
it could end up as "defer to next revision".  But it means that the
erratum is tracked along with the RFC, and when we do come up to doing
a revision, it's right there to remind us.

Barry

---

From: [email-masked]
Date: Sat, 06 Feb 2010 20:16:03 -0800 (PST)

WFM.

				Ned

---

From: Aaron Stone <[email-masked]>
Date: Sun, 7 Feb 2010 21:20:08 -0800

> either-or here, but there's considerable overlap in the functionality they

I've been planning to revive the multiscript document, as system-level
sieves are an idea many of us have batted around. I believe it's
[mostly] orthogonal to includes.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Feb 2010 10:45:18 -0500

Having not (yet?) gotten permission to make it a working-group
document, I've updated vacation-time with the individual-submission

> MAY omit "vacation" from the list.

The new version is here:
http://www.ietf.org/id/draft-george-sieve-vacation-time-01.txt

I'd still like to make it draft-ietf-sieve-... before we send it to the IESG.

Barry

---

From: [email-masked]
Date: Tue, 09 Feb 2010 15:03:08 -0800 (PST)

> http://www.ietf.org/id/draft-george-sieve-vacation-time-01.txt

Overall this is looking good. I only see a couple of issues with it, both
having to do with compliance language.

The first paragraph of section 2 says, "Only one of ":days" and ":seconds" is
allowed -- both MAY NOT be specified (it is a compile-time error to do so)."

"MAY NOT" is not legitimate compliance language, nor does it make any sense as
such. Obviously a script can specify both parameters; but doing so is supposed
to generate an error. To the extent there's a compliance issue here, it's what
the Sieve processor has to do.

It would also be inapprorpiate to require this to be handled as an error at
compile time - use of ihave precludes that, for one thing.

I therefore suggest changing this to:

  Only one of ":days" and ":seconds" is allowed -- use of both parameters in
  the same vacation action MUST result in a Sieve processing error.

Next, the capitalized "MAY" in the sentence

  Note that "vacation-seconds" implies "vacation", and a script with
  "vacation-seconds" in a "require" list MAY omit "vacation" from that list.

is also inappropriate, since it isn't talking about what a conforming Sieve
implementation can do, but rather about the allowed semantics of Sieve scripts.
It should simply be changed to lower case.

Other than these two issues, IMO this looks good to go.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Feb 2010 20:31:22 -0500

>  the same vacation action MUST result in a Sieve processing error.

That's in my XML for the next version.

> It should simply be changed to lower case.

I've changed it to "can", which avoids the inevitable question of
whether the "may" should be changed to "MAY".

Barry

---

From: [email-masked]
Date: Tue, 09 Feb 2010 20:15:08 -0800 (PST)

> whether the "may" should be changed to "MAY".

That's a really good idea. I always seem to forget about that issue.

				Ned

---

From: Aaron Stone <[email-masked]>
Date: Tue, 9 Feb 2010 22:19:36 -0800

Replying on-list -- let's discuss at Anaheim which documents we'd like
to add to the charter. There are a couple of very good looking
documents that we'll probably want to make WG documents given a little
discussion in person.

Barry sent a list of docs he'd like added, and anybody else with a
document you'd like considered please let Cyrus and me know!

Aaron