Re: Updated Sieve notification draft

[Michael Haardt <[e-mail]>]

On Fri, Sep 30, 2005 at 08:05:05AM -0700, Ned Freed wrote:
> > After reading this thread and having another go or two at the document,
> > I now get the idea that "notify" merely enables notifications to be sent
> > when *other* actions are taken.
> 
> I cannot believe this was the intent, but it is it needs to be changed ASAP.

Sounds we all agree in how it should work, but the draft really is
somewhat confusing in describing the notification model.

> > Also it's not clear if a single notification (one per :id, presumably)
> > is sent that summarizes all actions that have been taken, or if one
> > notification must be sent per action (per :id).
> 
> Notifications should contains what the action says they should contain.

We may add a site-specific default notification text, if no message is
given.

> My personal view is that denotify should be yanked from the specification. I
> see no more reason for it than I see for having defileinto or deredirect. (The
> last one has an especially nice name, doesn't it?) 

I didn't like denotify to begin with, but you do have a strong point
there why.  As I said, ":copy" just retains a flag for allowing shorter
code without variables, but denotify works on a set, not on a flag,
and doing so just to avoid variables is silly, as indeed we had to add
cancel actions for all actions otherwise to stay consistent.  And if we
did that, all actions had to allow a tag and we needed a generic cancel
action, the whole thing being an extension in itself.

At that point, variables look real attractive. :-)

Yet: Are there any votes against removing denotify?

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UKEHao014151; Fri, 30 Sep 2005 13:14:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UKEHfw014150; Fri, 30 Sep 2005 13:14:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UKEFG0014136 for <[e-mail]>; Fri, 30 Sep 2005 13:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1ELRGo-0003Sn-RU for [e-mail]; Fri, 30 Sep 2005 22:14:14 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx7.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1ELRGo-0003vm-Q9 for [e-mail]; Fri, 30 Sep 2005 22:14:14 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1ELRGo-0007l9-Gm for [e-mail]; Fri, 30 Sep 2005 22:14:14 +0200
Date: Fri, 30 Sep 2005 22:14:14 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Sep 30, 2005 at 08:05:05AM -0700, Ned Freed wrote:
> > After reading this thread and having another go or two at the document,
> > I now get the idea that "notify" merely enables notifications to be sent
> > when *other* actions are taken.
> 
> I cannot believe this was the intent, but it is it needs to be changed ASAP.

Sounds we all agree in how it should work, but the draft really is
somewhat confusing in describing the notification model.

> > Also it's not clear if a single notification (one per :id, presumably)
> > is sent that summarizes all actions that have been taken, or if one
> > notification must be sent per action (per :id).
> 
> Notifications should contains what the action says they should contain.

We may add a site-specific default notification text, if no message is
given.

> My personal view is that denotify should be yanked from the specification. I
> see no more reason for it than I see for having defileinto or deredirect. (The
> last one has an especially nice name, doesn't it?) 

I didn't like denotify to begin with, but you do have a strong point
there why.  As I said, ":copy" just retains a flag for allowing shorter
code without variables, but denotify works on a set, not on a flag,
and doing so just to avoid variables is silly, as indeed we had to add
cancel actions for all actions otherwise to stay consistent.  And if we
did that, all actions had to allow a tag and we needed a generic cancel
action, the whole thing being an extension in itself.

At that point, variables look real attractive. :-)

Yet: Are there any votes against removing denotify?

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UHwPuF002757; Fri, 30 Sep 2005 10:58:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UHwP6e002756; Fri, 30 Sep 2005 10:58:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8UHwOpC002750 for <[e-mail]>; Fri, 30 Sep 2005 10:58:24 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 32367 invoked by uid 101); 30 Sep 2005 13:58:24 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 30 Sep 2005 13:58:24 -0400
To: Ned Freed <[e-mail]>
Cc: Mark E Mallett <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Sep 30, 2005 at 08:05:05AM -0700, Ned Freed wrote:
> > On Mon, Sep 26, 2005 at 03:26:46PM +0100, Alexey Melnikov wrote:
> > > Hi folks,
> > > I took a stab at updating draft-martin-sieve-notify-01.txt, which should
> > > be published soon as draft-ietf-sieve-notify-00.txt. The document is
> > > attached.
> 
> > Hi-
> 
> > On my first read through, I had the idea that it was defining an action
> > "notify" that would itself generate a notification, deferred until the
> > end of the script's execution (otherwise the "denotify" made no sense).
> 
> That's exactly what the extension does, or at least should do.
> 
> > After reading this thread and having another go or two at the document,
> > I now get the idea that "notify" merely enables notifications to be sent
> > when *other* actions are taken.
> 
> I cannot believe this was the intent, but it is it needs to be changed ASAP.

My problem is that I couldn't really tell which was the intent.  My
first read was prejudiced by what I expected notify to do, which is that
of an action that had an immediate effect of sending a notice.  But
there are some parts that read as though the intent is to enable
notifications when other actions occur.  e.g.:

    This is an extension to the Sieve language defined by [SIEVE] for
    providing instant notifications of sieve actions that have been
    preformed.

    However, all content specified in the notify action, including Sieve
    actions taken on the message, SHOULD be included.

    If errors occurred in another action they SHOULD be reported in the
    notification.

The kicker being:

    Notifications MUST be sent in all cases, unless a reject action is
    also executed. Users may wish to be notified of a message being
    discarded, for example.   <<The reject action is given an exception
    because implementations may wish to restrict users from seeing the
    contents of a rejected message. However, notifications MAY be
    modified to not include any data from the original rejected message.>>

That paragraph is perplexing, in several ways, if notify simply sends
its own message, but not so much with the other interpretation.


> There is absolutely no reason to make notify actions have special and
> unusual dependencies on other actions. This sort of thing would add all
> sorts of strange interaction semantics to the sieve language that it doesn't
> need and which will make our job of describing action behavior moving
> forward vastly more difficult. It will also make it harder to write
> scripts that function properly, debug scripts, and just about everything
> else.

I don't think that a summary notification of actions taken would have
these dire consequences, any more than logging each action does, or any
more than delaying actions until after script execution does.  (Not that
I'm in favor of having notify work that way, either.)  But I do think
the intent is unclear, and some wording needs to be changed to better
reflect whichever was meant.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UGRfQf096510; Fri, 30 Sep 2005 09:27:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UGRfvQ096509; Fri, 30 Sep 2005 09:27:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UGRfUq096503 for <[e-mail]>; Fri, 30 Sep 2005 09:27:41 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 30 Sep 2005 09:27:38 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1128097657; h=Date: 	 From:Subject:MIME-version:Content-type; b=JVa6VyOoMfdHOMrdme8jtfewf KAufsu0rP5s7mNVG20ehXyqOxxnCnBsLGesR2dETHDA10E2F4b+vtXvXRo7EA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 30 Sep 2005 09:27:32 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
To: Nigel Swinson <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 30 Sep 2005 09:26:03 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve notification draft
In-reply-to: "Your message dated Fri, 30 Sep 2005 17:02:40 +0100" <001e01c5c5d8$63e2e870$[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed; charset=iso-8859-1; reply-type=original
References: <[e-mail]> <[e-mail]> <[e-mail]> <001e01c5c5d8$63e2e870$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > My personal view is that denotify should be yanked from the specification.
> > I
> > see no more reason for it than I see for having defileinto or deredirect.
> > (The
> > last one has an especially nice name, doesn't it?)

> I'd be happy to see it dropped too, I doubt very much that I'd ever
> implement it even if it doesn't get dropped.

It appears to me to be fairly easy to implement so I'd probably do it in order
to claim conformance, but I cannot imagine a case in our environment where it
would actually be useful and used. And unused (or rarely used) options are
often a place for bugs to congregate.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UGF2qt095416; Fri, 30 Sep 2005 09:15:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UGF2Ox095415; Fri, 30 Sep 2005 09:15:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UGF14T095397 for <[e-mail]>; Fri, 30 Sep 2005 09:15:01 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1ELNXF-0006sk-Mo; Fri, 30 Sep 2005 18:14:57 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1ELNXC-0001Ie-Uw; Fri, 30 Sep 2005 18:14:55 +0200
Subject: Re: Updated Sieve notification draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 30 Sep 2005 18:14:41 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.752, required 12, autolearn=disabled, AWL 1.06, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-09-30 at 08:05 -0700, Ned Freed wrote:
> Notifications should contains what the action says they should contain.
> Automatic addition of information about other actions is IMO entirely
> inappropriate, and even if was appropriate I don't see how it could be done
> usefully. (Tnink about the internationalization issues.)

I agree.

> My personal view is that denotify should be yanked from the specification. I
> see no more reason for it than I see for having defileinto or deredirect. (The
> last one has an especially nice name, doesn't it?)

I agree.  (and without "denotify", "notify" can have immediate effect if
the implemenation so chooses.)

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UG5m5l094505; Fri, 30 Sep 2005 09:05:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UG5mat094504; Fri, 30 Sep 2005 09:05:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UG5mKn094492 for <[e-mail]>; Fri, 30 Sep 2005 09:05:48 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (unverified [10.42.44.102]) by mail.rockliffe.com (Rockliffe SMTPRA 6.3.25) with ESMTP id <[e-mail]>; Fri, 30 Sep 2005 09:02:43 -0700
Message-ID: <001e01c5c5d8$63e2e870$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Cc: "Alexey Melnikov" <[e-mail]>, "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Updated Sieve notification draft
Date: Fri, 30 Sep 2005 17:02:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> My personal view is that denotify should be yanked from the specification. 
> I
> see no more reason for it than I see for having defileinto or deredirect. 
> (The
> last one has an especially nice name, doesn't it?)

I'd be happy to see it dropped too, I doubt very much that I'd ever 
implement it even if it doesn't get dropped.

Nigel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UFFYq3090004; Fri, 30 Sep 2005 08:15:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UFFYY7090003; Fri, 30 Sep 2005 08:15:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UFFVUi089985 for <[e-mail]>; Fri, 30 Sep 2005 08:15:32 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 30 Sep 2005 08:14:51 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1128093290; h=Date: 	 From:Subject:MIME-version:Content-type; b=dJjH95RuyT8ILR7wkeEZr1nnc bsJBqybL7xElE2UHRJKrBIdEM6PnT85dtej0l4ac0voypdvagxzHmoKwH7Vuw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 30 Sep 2005 08:14:48 -0700 (PDT)
Cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
To: Mark E Mallett <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 30 Sep 2005 08:05:05 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve notification draft
In-reply-to: "Your message dated Thu, 29 Sep 2005 18:39:53 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Mon, Sep 26, 2005 at 03:26:46PM +0100, Alexey Melnikov wrote:
> > Hi folks,
> > I took a stab at updating draft-martin-sieve-notify-01.txt, which should
> > be published soon as draft-ietf-sieve-notify-00.txt. The document is
> > attached.

> Hi-

> On my first read through, I had the idea that it was defining an action
> "notify" that would itself generate a notification, deferred until the
> end of the script's execution (otherwise the "denotify" made no sense).

That's exactly what the extension does, or at least should do.

> After reading this thread and having another go or two at the document,
> I now get the idea that "notify" merely enables notifications to be sent
> when *other* actions are taken.

I cannot believe this was the intent, but it is it needs to be changed ASAP.
There is absolutely no reason to make notify actions have special and
unusual dependencies on other actions. This sort of thing would add all
sorts of strange interaction semantics to the sieve language that it doesn't
need and which will make our job of describing action behavior moving
forward vastly more difficult. It will also make it harder to write
scripts that function properly, debug scripts, and just about everything
else.

>  If that's the correct reading of the
> draft, then I think it needs to be made clearer that the "notify" verb
> merely enables notifications, and the notifications are triggered by
> other actions.  I'm still not sure I have interpreted it correctly.

I hope not.

> Also it's not clear if a single notification (one per :id, presumably)
> is sent that summarizes all actions that have been taken, or if one
> notification must be sent per action (per :id).

Notifications should contains what the action says they should contain.
Automatic addition of information about other actions is IMO entirely
inappropriate, and even if was appropriate I don't see how it could be done
usefully. (Tnink about the internationalization issues.)

> Nor is it clear (to me)
> whether "denotify" cancels any queued-up notifications, or whether it
> merely disarms the trigger (and queued-up notifications as a result of
> already-executed actions are still sent).  And what happens if you've
> executed two "notify" statements with different ":id"s -- does each
> subsequent action then get two notifications?  That seems reasonable but
> probably should be stated.

My personal view is that denotify should be yanked from the specification. I
see no more reason for it than I see for having defileinto or deredirect. (The
last one has an especially nice name, doesn't it?) 

However, if there is a consensus to retain denotify (it isn't all that
difficult to implement, just silly), it should be able to cancel either a
specific pending notification (by id), a group of notifications (by id list) or
all notifications.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TMdtI7084780; Thu, 29 Sep 2005 15:39:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8TMdtGC084779; Thu, 29 Sep 2005 15:39:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8TMdr5U084773 for <[e-mail]>; Thu, 29 Sep 2005 15:39:53 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 67435 invoked by uid 101); 29 Sep 2005 18:39:53 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 29 Sep 2005 18:39:53 -0400
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Sep 26, 2005 at 03:26:46PM +0100, Alexey Melnikov wrote:
> Hi folks,
> I took a stab at updating draft-martin-sieve-notify-01.txt, which should 
> be published soon as draft-ietf-sieve-notify-00.txt. The document is 
> attached.

Hi-

On my first read through, I had the idea that it was defining an action
"notify" that would itself generate a notification, deferred until the
end of the script's execution (otherwise the "denotify" made no sense).
After reading this thread and having another go or two at the document,
I now get the idea that "notify" merely enables notifications to be sent
when *other* actions are taken.  If that's the correct reading of the
draft, then I think it needs to be made clearer that the "notify" verb
merely enables notifications, and the notifications are triggered by
other actions.  I'm still not sure I have interpreted it correctly.

Also it's not clear if a single notification (one per :id, presumably)
is sent that summarizes all actions that have been taken, or if one
notification must be sent per action (per :id).  Nor is it clear (to me)
whether "denotify" cancels any queued-up notifications, or whether it
merely disarms the trigger (and queued-up notifications as a result of
already-executed actions are still sent).  And what happens if you've
executed two "notify" statements with different ":id"s -- does each
subsequent action then get two notifications?  That seems reasonable but
probably should be stated.

It may just be me, of course, but I think some of this could be a lot
clearer.

As for a few specific comments (pared down a little):

    > 1.  Introduction
    > 
    > This is an extension to the Sieve language defined by [SIEVE] for
    > providing instant notifications of sieve actions that have been
    > preformed. It defines the new action "notify".

That definition suggests that executing the "notify" action will cause
a notification.


    > 1.0
    > 
    > Sieve interpreters for which notifications are impractical or is not
    > possible SHOULD ignore this extension.

What does this mean... are you recommending that interpreters implement
the extension as no-ops, so that the "require" will work but the actual
notify statements will not?  I mean, this seems to be recommending
something other than the usual thing of having the "require" fail to
operate if the capability is not available.  If all this means is
"have the 'require' fail if the capability isn't available" -- doesn't
that go without saying?


    > 3.1.  Notify action


    >  ... If an URI schema is
    > specified that the implementation does not support, the notification
    > MUST be ignored. An implementation treats this as a warning
    > condition and execution of the sieve script MUST continue.

I find "must be ignored" and "treat as a warning condition" to be
contradictory..  Perhaps the intent is "must not be treated as a fatal
error, may result in a warning, but the script must continue"


    > Some notification methods allow users to specify their
    > state of activity (for example "busy" or "away from keyboard"). If
    > the notification method provides this information it SHOULD be used
    > to selectively send notifications.  If, for example, the user marks
    > herself as "busy", an implementation SHOULD NOT send a notification
    > for a new mailing list message with a priority of :low, however the
    > user should be notified of a high priority action.  If the
    > notification method allows users to filter messages based upon
    > certain parameters in the message, users should be able to filter
    > based upon priority. If the notification method does not support
    > priority, then this parameter MUST be ignored.

Is any of this in scope?  That stuff sounds to me more like details of
the way the specific notification platform operates than how the Sieve
implementation should operate.  It would be pretty hairy for the Sieve
implementation to figure out what user to query, even assuming the
notification system directs the message to a particular user, let alone
how to find out what the user's state is.  Then again, I may be
misunderstanding.



    > 3.2.  Denotify Action
    > 
    > Usage: denotify [MATCH-TYPE string] [<":low" / ":normal" / ":high">]

I don't care for the fact that "match-type" takes an argument; this is
different from every other context for "match-type."  I would much
prefer ":id" with an argument to specify the id(s) to affect, as it's
already defined with "notify," and revert "match-type" the way it is
everywhere else.

For that matter, rather than two verbs "notify" and "denotify" I'd
rather see just one verb, with modifiers to toggle the notification on
or off and/or to cancel.  e.g.:

    notify :cancel  # to cancel any pent-up notifications
    notify :off     # to disable notifications for future actions
    notify :on      # to [re]enable a notification



    > 4.  Interaction with Other Sieve Actions
    > 
    > Notifications MUST be sent in all cases, unless a reject action is
    > also executed. Users may wish to be notified of a message being
    > discarded, for example.

Might users not want to be notified of a 'reject' action too?  Why not
let them have that control?  The :off/:on/:cancel thing would facilitate
that.


    > The notify action is compatible with itself.

Meaning?

With apologies for any extra denseness,
mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8SEHhEv034277; Wed, 28 Sep 2005 07:17:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8SEHhP3034276; Wed, 28 Sep 2005 07:17:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8SEHgQ1034268 for <[e-mail]>; Wed, 28 Sep 2005 07:17:42 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 28 Sep 2005 07:17:38 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1127917058; h=Date: 	 From:Subject:MIME-version:Content-type; b=BL/647mJy3PYrTCPl05hJY0nI nFEJeJ5PbB4snG4+LRm2qsxft7OIOe0mh4NTWeXQcWfzDpHwTwSSRUr0wh9nQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 28 Sep 2005 07:17:35 -0700 (PDT)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Wed, 28 Sep 2005 07:13:13 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve notification draft
In-reply-to: "Your message dated Wed, 28 Sep 2005 09:59:27 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Tue, Sep 27, 2005 at 06:24:04PM +0100, Alexey Melnikov wrote:
> >
> > Kjetil Torgrim Homme wrote:
> > >       [...] that allows users to give specific rules for how and when
> > >       notifications should be sent when mail is received.
> > >
> > I've deleted "when mail is received" part and used the suggested text.

> Just nitpicking, but it is the Sieve base language that contains the
> rules, not the notify extension.  The latter only sends notifications. :-)

> > >I think it would be good if the notify document described at least one
> > >method.  it seems to me that the amount of explanation needed for SMS
> > >and XMPP would be very little, and not worthy of a separate document.
> > >there is no need to go into protocol specifics, IMHO, a simple mapping
> > >for where the message should go seems sufficient.
> > >
> > SMS is trivial. XMPP is more interesting, because it allows for multiple
> > alternative representations.
> >
> > I would also like to avoid any normative reference to XMPP. This can be
> > probably done if XMPP notifications are described in an informative
> > appendix.

> As odd as that may sound, but I would like to see mailto URLs being
> described.

Actually, it is far from odd. Our experience is that this is mechanism more
commonly requested and used than almost anything else, if for no other reason
than the fact that gatways from email to other systems are very common.

> The normative reference should not be a problem and there
> are many SMTP to SMS gateways run by cell phone providers.

Exactly so. There are also situations where someone needs to know a message
has been delivered somewhere but security reasons preclude forwarding
the message itself.

> I know many
> people using them to get SMS notifications.  Usually they transmit the
> Subject: of the message and the mail address looks like <number>@gateway.
> Since it causes no costs for the sending side, many peoviders offer those.

Email is certainly the one service an email server is pretty much guaranteed
to have available.

> > I am still hesitating. I see a point of having a timestamp somewhere in
> > a notification, either as a separate field or in the body.
> >
> > What other people think about this?

> Thinking about it, time stamps are useful, but I never had any for
> notifications and did not miss them in the past.  I would not require
> them, but perhaps recommend.

Sounds right.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S9Dvit007753; Wed, 28 Sep 2005 02:13:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8S9DvvU007752; Wed, 28 Sep 2005 02:13:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S9DtBM007744 for <[e-mail]>; Wed, 28 Sep 2005 02:13:55 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1EKY0f-0003vb-RO for [e-mail]; Wed, 28 Sep 2005 11:13:53 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx4.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EKY0e-0001Uz-Jv for [e-mail]; Wed, 28 Sep 2005 11:13:53 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1EKY0Y-0005dM-Mt for [e-mail]; Wed, 28 Sep 2005 11:13:46 +0200
Date: Wed, 28 Sep 2005 11:13:46 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Sep 26, 2005 at 03:26:46PM +0100, Alexey Melnikov wrote:
> I took a stab at updating draft-martin-sieve-notify-01.txt, which should 
> be published soon as draft-ietf-sieve-notify-00.txt. The document is 
> attached.

Thanks a lot! I appreciate this very much, because some functionality of
this kind is on my list of tasks.  I am not sure if notify is really
what I ask for, reading the draft, but it may.

> I remember there was a discussion few months ago about defining a 
> separate SMS notification mechanism. I just want to let people know that 
> the update I've made doesn't prevent any other documents in this area. 
> Just treat it as an input for discussion.

Using URLs may well allow to unify all notification mechanisms.  Sure
a "comsat" URL may look odd, but why a whole new extension for it?

>     Usage:   notify [":method" string]
>                [":id" string]
>                [<":low" / ":normal" / ":high">]
>                [":message" string]

I miss a sender specification of some kind, like [":from" string], like
we have for vacation.

>     The format of the notification is implementation-defined. However,
>     all content specified in the notify action, including Sieve actions
>     taken on the message, SHOULD be included. If errors occurred in
>     another action they SHOULD be reported in the notification. In
>     addition, if the notification method does not provide a timestamp,
>     one SHOULD be appended to the notification. Implementations SHOULD
>     NOT include extraneous information.

I don't like that, because it means I have to delay sending notifications
until successful delivery of a message, like transferring it to the mail
store or forwarding it to another host.  What if the user is over quota
or the remote host is down? That's not a successful delivery.  Yet I would
like to get a notification that the mail was seen by the filter.

I guess what I do not like it that notify sounds like DSNs.  To me,
it should be just some action.  If I decide to send a notification and
then discard the message in order to process mail alarms, I don't need
to have notify tell me the message was discarded.

>     If the :method tag is not specified, the default
>     implementation defined notification method is used.  The
>     possible values of this will be site-specific.  If an URI schema is
>     specified that the implementation does not support, the notification
>     MUST be ignored. An implementation treats this as a warning
>     condition and execution of the sieve script MUST continue.

As I wrote in another mail, people have a hard time to get phone numbers
right, like not including letters in them.  I prefer to generate errors
if that happens.  That way they see something is wrong instead of yelling
at the SMS provider.

May an implementation choose not to send any notification if no method is
given? I run a bunch of systems without a default notification mechanism.

>     If there are errors sending the notification, the Sieve interpreter
>     SHOULD ignore the notification and not retry indefinitely.

I agree on that.  If the URL was syntactically correct, and perhaps even
semantically correct, faults are usually outside the scope of users.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S8p21b099414; Wed, 28 Sep 2005 01:51:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8S8p2qC099413; Wed, 28 Sep 2005 01:51:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S8p079099393 for <[e-mail]>; Wed, 28 Sep 2005 01:51:01 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EKXeW-0001T6-ER for [e-mail]; Wed, 28 Sep 2005 10:51:00 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EKXeW-0001YR-CL for [e-mail]; Wed, 28 Sep 2005 10:51:00 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1EKXeT-0005ca-7p for [e-mail]; Wed, 28 Sep 2005 10:50:57 +0200
Date: Wed, 28 Sep 2005 10:50:57 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <015201c5c354$0f101ab0$050ac050@nigelhome>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Sep 27, 2005 at 12:10:22PM +0100, Nigel Swinson wrote:
>     This document does not dictate the notification method used.
>     Examples of possible notification methods are Zephyr and Jabber. The
> -    method shall be site-defined.
> +    available methods shall be site-defined.
> 
> Which makes me wonder if each desired "method" should really be available via a require command?

I prefer a require commend for each method and syntactically checking
the URL, generating an error on bad syntax.  And I would go as far as
allowing semantic errors to cause errors on behalf of the implementation.

I ran various SMS gateways over the years and if there is one common
problem, it is people embedding letters and all kinds of special
characters in phone numbers, like @ and 8-bit characters, or doubling
the number or the area prefix which yields way too long numbers.
Simply dropping those numbers results in complaints why important SMS
were not sent.  At one time I had almost 10% bad numbers and I am sick
of complaints.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S8bheG091114; Wed, 28 Sep 2005 01:37:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8S8bhfM091113; Wed, 28 Sep 2005 01:37:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S8bg5o091105 for <[e-mail]>; Wed, 28 Sep 2005 01:37:42 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EKXRd-00026a-Ue for [e-mail]; Wed, 28 Sep 2005 10:37:41 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EKXRd-0004y2-MY for [e-mail]; Wed, 28 Sep 2005 10:37:41 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1EKXRb-0005c9-B3 for [e-mail]; Wed, 28 Sep 2005 10:37:39 +0200
Date: Wed, 28 Sep 2005 10:37:39 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Sep 27, 2005 at 05:56:04PM +0200, Kjetil Torgrim Homme wrote:
> one general issue which I think should be specified in 3.1, is how to
> handle charsets when the notification method doesn't support full UTF-8.
> something like: "Characters in the message which can't be represented by
> the notification method SHOULD be replaced with a symbol indicating an
> unknown character, e.g., a question mark."

Forget about that.  If you connect to a SMSC and speak UCP, it is your
choice how to convert the message text to IA5.  If you use a regular
gateway by SMTP or HTTP, you can not deliver IA5, but usually ISO-8859-15,
and you have no influence on how that is converted to IA5.  The ones I
saw so far just dropped characters they can not translate.

I choose to use UCP, if I can, but it is not offered by all SMS providers.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S8Tl5X090324; Wed, 28 Sep 2005 01:29:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8S8TleX090323; Wed, 28 Sep 2005 01:29:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S8TkN8090313 for <[e-mail]>; Wed, 28 Sep 2005 01:29:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EKXJx-0003Cu-Jw for [e-mail]; Wed, 28 Sep 2005 10:29:45 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EKXJx-0000QC-Ha for [e-mail]; Wed, 28 Sep 2005 10:29:45 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1EKXJx-0005be-5w for [e-mail]; Wed, 28 Sep 2005 10:29:45 +0200
Date: Wed, 28 Sep 2005 10:29:45 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Sep 27, 2005 at 01:50:21PM +0100, Alexey Melnikov wrote:
> >This makes it sound like there are hard and fast rules between user status 
> >notifications and the setting of the priority parameter, yet the 
> >discussion is very brief and doesn't elaborate to rigorously define all 
> >those rules.  I also feel uneasy about adding syntax that permits only 3 
> >levels of priority.   I think we should either drop the parameter, or 
> >extend it to allow an almost arbitrary number and style of priority 
> >statuses, even if we only define 3 for now.  I'm thinking of the 
> >Priority/X-Priority/X-MSMail-Priority mess in mail headers.  I'd suggest a 
> >string which could be used with the relational draft to do numeric 
> >comparisons if desired.
> > 
> >
> Let me think about this one for a bit.

Just my two cent: Drop it.  The :id option might be renamed to :handle,
like for vacation.  If I wanted to use priorities, I would encode the
priority in the id and match that.

I am a bit puzzled by denotify anyway.  Obviously, notify predated
variables, thus duplicating some functionality.  Do we really need the
complexity of denotify?  How is the notify id scope defined? Does it
match the scope of variables with regard to including scripts?

I know :copy was invented to simplify scripts without having variables,
but it is cheap to implement.  Denotify looks like a can of worms to me.

> >5.  Security Consideration
> >
> >Is there additional risk of mail loops when using this extension?
> > 
> >
> Yes, if you use mailto: URI schema. Or any other notification method 
> that can be getawayed to mail.
> But this is not an issue specific to Sieve notify.

It is and it is not.  Vacation goes into great detail about rate limiting,
among other reasons for that purpose.  With vacation, it makes sense,
because you are about to annoy other people.  Notify is usually directed
to yourself, but rate limiting may still be interesting.

The question is: Do we need rate limiting inside notify (preferably a
token bucket) or should a rate limit extension, expressed as new test,
be defined?

SMS are not for free and some protection against mail bombing causing
high costs should be offered.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S7xUsu087552; Wed, 28 Sep 2005 00:59:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8S7xUgO087551; Wed, 28 Sep 2005 00:59:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8S7xTiT087543 for <[e-mail]>; Wed, 28 Sep 2005 00:59:30 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EKWqe-0003ex-13 for [e-mail]; Wed, 28 Sep 2005 09:59:28 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EKWqd-0004YM-W3 for [e-mail]; Wed, 28 Sep 2005 09:59:28 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #19) id 1EKWqd-0005ac-Mh for [e-mail]; Wed, 28 Sep 2005 09:59:27 +0200
Date: Wed, 28 Sep 2005 09:59:27 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve notification draft
Message-ID: <[e-mail]>
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Sep 27, 2005 at 06:24:04PM +0100, Alexey Melnikov wrote:
> 
> Kjetil Torgrim Homme wrote:
> >       [...] that allows users to give specific rules for how and when
> >       notifications should be sent when mail is received.
> >
> I've deleted "when mail is received" part and used the suggested text.

Just nitpicking, but it is the Sieve base language that contains the
rules, not the notify extension.  The latter only sends notifications. :-)

> >I think it would be good if the notify document described at least one
> >method.  it seems to me that the amount of explanation needed for SMS
> >and XMPP would be very little, and not worthy of a separate document.
> >there is no need to go into protocol specifics, IMHO, a simple mapping
> >for where the message should go seems sufficient.
> >
> SMS is trivial. XMPP is more interesting, because it allows for multiple 
> alternative representations.
> 
> I would also like to avoid any normative reference to XMPP. This can be 
> probably done if XMPP notifications are described in an informative 
> appendix.

As odd as that may sound, but I would like to see mailto URLs being
described.  The normative reference should not be a problem and there
are many SMTP to SMS gateways run by cell phone providers.  I know many
people using them to get SMS notifications.  Usually they transmit the
Subject: of the message and the mail address looks like <number>@gateway.
Since it causes no costs for the sending side, many peoviders offer those.

> I am still hesitating. I see a point of having a timestamp somewhere in 
> a notification, either as a separate field or in the body.
> 
> What other people think about this?

Thinking about it, time stamps are useful, but I never had any for
notifications and did not miss them in the past.  I would not require
them, but perhaps recommend.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RMOD8G032931; Tue, 27 Sep 2005 15:24:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8RMODrE032930; Tue, 27 Sep 2005 15:24:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RMOC4S032918 for <[e-mail]>; Tue, 27 Sep 2005 15:24:12 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1EKNrr-0000d2-VW; Wed, 28 Sep 2005 00:24:08 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EKNrn-0004ii-39; Wed, 28 Sep 2005 00:24:03 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 28 Sep 2005 00:23:48 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.616, required 12, autolearn=disabled, AWL 1.20, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-09-27 at 13:31 -0700, Ned Freed wrote:
> > Alexey Melnikov wrote:
> > The next question I would like to ask:
> >  Are people Ok with having this restriction for :address and :string tests?
> 
> I'm in favor of the behavior being consistent across all tests. If it isn't
> we now hove to specify this obscure bit of behavior for every future
> extension that introduces a test. Not good IMO.

I agree.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RKWPtE024847; Tue, 27 Sep 2005 13:32:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8RKWPBl024846; Tue, 27 Sep 2005 13:32:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RKWO1j024838 for <[e-mail]>; Tue, 27 Sep 2005 13:32:24 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 27 Sep 2005 13:32:23 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1127853142; h=Date: 	 From:Subject:MIME-version:Content-type; b=fSFG4XqffOAensUtqd2ZZGCXp GlypLgpqiqTV7fxQs546vDhum0e3658YKAn/YdRIbUgtw3cjEIdz/d/Y09/cA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 27 Sep 2005 13:32:20 -0700 (PDT)
Cc: MTA filtering mailing list <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
Date: Tue, 27 Sep 2005 13:31:16 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft
In-reply-to: "Your message dated Tue, 27 Sep 2005 18:31:25 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=KOI8-R; format=flowed
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Alexey Melnikov wrote:

> > Hi folks,
> > One of the questions raised during the WGLC of
> > draft-ietf-sieve-3431bis-01.txt was concerning the following text in
> > the draft:
> >
> > >3.1.  Match Type Value
> > [...]
> > >   Leading and trailing white space MUST be removed from the value of
> > >   the message for the comparison.  White space is defined as
> > >
> > >       SP / HTAB / CRLF
> >
> > I would like to poll people who've implemented the relational
> > draft/RFC if they've been following this rule.

> The next question I would like to ask:
>  Are people Ok with having this restriction for :address and :string tests?

I'm in favor of the behavior being consistent across all tests. If it isn't
we now hove to specify this obscure bit of behavior for every future
extension that introduces a test. Not good IMO.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RHVWPe010960; Tue, 27 Sep 2005 10:31:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8RHVWlM010959; Tue, 27 Sep 2005 10:31:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RHVV86010952 for <[e-mail]>; Tue, 27 Sep 2005 10:31:31 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Tue, 27 Sep 2005 18:31:29 +0100
Message-ID: <[e-mail]>
Date: Tue, 27 Sep 2005 18:31:25 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Hi folks,
> One of the questions raised during the WGLC of 
> draft-ietf-sieve-3431bis-01.txt was concerning the following text in 
> the draft:
>
> >3.1.  Match Type Value
> [...]
> >   Leading and trailing white space MUST be removed from the value of
> >   the message for the comparison.  White space is defined as
> >
> >       SP / HTAB / CRLF
>
> I would like to poll people who've implemented the relational 
> draft/RFC if they've been following this rule.

The next question I would like to ask:
 Are people Ok with having this restriction for :address and :string tests?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RHO944010341; Tue, 27 Sep 2005 10:24:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8RHO9ul010340; Tue, 27 Sep 2005 10:24:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RHO8nl010334 for <[e-mail]>; Tue, 27 Sep 2005 10:24:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.119] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 27 Sep 2005 18:24:04 +0100
Message-ID: <[e-mail]>
Date: Tue, 27 Sep 2005 18:24:04 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Updated Sieve notification draft
References: <[e-mail]>	 <015201c5c354$0f101ab0$050ac050@nigelhome>  <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Tue, 2005-09-27 at 13:50 +0100, Alexey Melnikov wrote:
>  
>
>>>Abstract:
>>>   This draft describes an extension to the Sieve mail filtering
>>>   language that allows users to give specific preferences for
>>>-    notification of Sieve actions.
>>>+   notification of mail delivery.      
>>>
>>Sieve notify can also be used to notify about Sieve actions executed for 
>>a message, so the original text is better in this respect.
>>The document as written is not quite clear how this has to be done, though.
>>
>
>I suggest:
>
>        [...] that allows users to give specific rules for how and when
>        notifications should be sent when mail is received.
>
I've deleted "when mail is received" part and used the suggested text.

>>One thought I have is to have separate documents describing how 
>>different notification schemas should be handled, e.g. a separate 
>>document for SMS, another one for XMPP, etc.    
>>
>
>I think it would be good if the notify document described at least one
>method.  it seems to me that the amount of explanation needed for SMS
>and XMPP would be very little, and not worthy of a separate document.
>there is no need to go into protocol specifics, IMHO, a simple mapping
>for where the message should go seems sufficient.
>
SMS is trivial. XMPP is more interesting, because it allows for multiple 
alternative representations.

I would also like to avoid any normative reference to XMPP. This can be 
probably done if XMPP notifications are described in an informative 
appendix.

>>>3.1 Notify Action
>>>   In
>>>   addition, if the notification method does not provide a timestamp,
>>>   one SHOULD be appended to the notification.
>>>
>>>Why bother with this?  While I agree it might be a sensible idea, I
>>>was surprised to see it as a SHOULD, I guess it's not a MUST
>>>though :o/
>>>      
>>>
>
>"appended" indicates to me that it should be part of the message, and
>that just doesn't seem right.  most of the notification methods will
>have a timestamp field which can be used, and if they don't and won't
>"pollute" the message with a textual timestamp, well, tough cookies for
>the users of that notification method.
>
Yes, I've changed "appended to the notification" to "included in the 
notification".

>>I can even lowercase SHOULD here.    
>>
>
>I don't think that's appropriate.  either it should stay with capital
>letters, or it should be removed.
>
I am still hesitating. I see a point of having a timestamp somewhere in 
a notification, either as a separate field or in the body.

What other people think about this?

Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RG9atC003451; Tue, 27 Sep 2005 09:09:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8RG9axN003450; Tue, 27 Sep 2005 09:09:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RG9Zwj003439 for <[e-mail]>; Tue, 27 Sep 2005 09:09:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1EKI1L-0006MU-Ly; Tue, 27 Sep 2005 18:09:31 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EKHoR-0002vq-1m; Tue, 27 Sep 2005 17:56:11 +0200
Subject: Re: Updated Sieve notification draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome>  <[e-mail]>
Content-Type: text/plain
Date: Tue, 27 Sep 2005 17:56:04 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (timed out)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-09-27 at 13:50 +0100, Alexey Melnikov wrote:
> >Abstract:
> >    This draft describes an extension to the Sieve mail filtering
> >    language that allows users to give specific preferences for
> >-    notification of Sieve actions.
> >+   notification of mail delivery.
> >  
> >
> Sieve notify can also be used to notify about Sieve actions executed for 
> a message, so the original text is better in this respect.
> The document as written is not quite clear how this has to be done, though.

I suggest:

        [...] that allows users to give specific rules for how and when
        notifications should be sent when mail is received.

> One thought I have is to have separate documents describing how 
> different notification schemas should be handled, e.g. a separate 
> document for SMS, another one for XMPP, etc.

I think it would be good if the notify document described at least one
method.  it seems to me that the amount of explanation needed for SMS
and XMPP would be very little, and not worthy of a separate document.
there is no need to go into protocol specifics, IMHO, a simple mapping
for where the message should go seems sufficient.

> >3.1 Notify Action
> >    In
> >    addition, if the notification method does not provide a timestamp,
> >    one SHOULD be appended to the notification.
> >
> >Why bother with this?  While I agree it might be a sensible idea, I
> >was surprised to see it as a SHOULD, I guess it's not a MUST
> >though :o/

"appended" indicates to me that it should be part of the message, and
that just doesn't seem right.  most of the notification methods will
have a timestamp field which can be used, and if they don't and won't
"pollute" the message with a textual timestamp, well, tough cookies for
the users of that notification method.

> I can even lowercase SHOULD here.

I don't think that's appropriate.  either it should stay with capital
letters, or it should be removed.

> >    <<Open issue: the previous version of this draft has defined the two
> >      variables that can't be currently represented:
> >
> >         $text$     - the first text/* part
> >
> >         $text[n]$  - the first n bytes of the first text/* part
> >    >>
> >
> >I'd like to drop both of these, and wait for other extensions used with VARIABLES to allow the behaviour.
> >
> Yes, this will need an extension to variables.

well, you need "body".

  if body :text :matches "*" {
      set "text" "${1}";
  }

and to do the $text[n]$ bit you need "regex" as well:

  if body :text :regex ".{120}" {
      set "text" "${1}";
  }


one general issue which I think should be specified in 3.1, is how to
handle charsets when the notification method doesn't support full UTF-8.
something like: "Characters in the message which can't be represented by
the notification method SHOULD be replaced with a symbol indicating an
unknown character, e.g., a question mark."

> >5.  Security Consideration
> >
> >Is there additional risk of mail loops when using this extension?
> >  
> >
> Yes, if you use mailto: URI schema. Or any other notification method 
> that can be getawayed to mail.
> But this is not an issue specific to Sieve notify.

if the mailto: schema is described in this document, there should be a
reference to RFC 3834 ("Recommendations for Automatic Responses to
Electronic Mail.") to cover this.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RCoRp0081506; Tue, 27 Sep 2005 05:50:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8RCoR8I081505; Tue, 27 Sep 2005 05:50:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RCoP1G081494 for <[e-mail]>; Tue, 27 Sep 2005 05:50:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 27 Sep 2005 13:50:21 +0100
Message-ID: <[e-mail]>
Date: Tue, 27 Sep 2005 13:50:21 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nigel Swinson <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Updated Sieve notification draft
References: <[e-mail]> <015201c5c354$0f101ab0$050ac050@nigelhome>
In-Reply-To: <015201c5c354$0f101ab0$050ac050@nigelhome>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Nigel,
First of all, thank you for the comments!

>Abstract:
>    This draft describes an extension to the Sieve mail filtering
>    language that allows users to give specific preferences for
>-    notification of Sieve actions.
>+   notification of mail delivery.
>  
>
Sieve notify can also be used to notify about Sieve actions executed for 
a message, so the original text is better in this respect.
The document as written is not quite clear how this has to be done, though.

>That sounds like the extension allows you to be notified about an action, rather than a message.  I thought the significant event was the delivery of mail rather than a sieve action.  Similar comments apply to Introduction section.
>
>    This document does not dictate the notification method used.
>    Examples of possible notification methods are Zephyr and Jabber. The
>-    method shall be site-defined.
>+    available methods shall be site-defined.
>  
>
Done.

>Which makes me wonder if each desired "method" should really be available via a require command?
>  
>
I am not sure that this is needed.
Remember, notifications are ignored if method is not recognized.

One thought I have is to have separate documents describing how 
different notification schemas should be handled, e.g. a separate 
document for SMS, another one for XMPP, etc.

>3.1 Notify Action
>    In
>    addition, if the notification method does not provide a timestamp,
>    one SHOULD be appended to the notification.
>
>Why bother with this?  While I agree it might be a sensible idea, I was surprised to see it as a SHOULD, I guess it's not a MUST though :o/
>  
>
I can even lowercase SHOULD here.

>    If, for example, the user marks
>    herself as "busy", an implementation SHOULD NOT send a notification
>    for a new mailing list message with a priority of :low
>
>This makes it sound like there are hard and fast rules between user status notifications and the setting of the priority parameter, yet the discussion is very brief and doesn't elaborate to rigorously define all those rules.  I also feel uneasy about adding syntax that permits only 3 levels of priority.   I think we should either drop the parameter, or extend it to allow an almost arbitrary number and style of priority statuses, even if we only define 3 for now.  I'm thinking of the Priority/X-Priority/X-MSMail-Priority mess in mail headers.  I'd suggest a string which could be used with the relational draft to do numeric comparisons if desired.
>  
>
Let me think about this one for a bit.

>    If the message parameter is absent, a default message
>    containing the value of the From header field and the value of the
>    Subject header field will be used.
>
>Could this be specific to the notification mechanism in use?
>
Yes!

>  And can it just be left to be implementation specific?
>
I think so.

The original draft was prescribing the exact syntax. While I was trying 
to construct an XMPP example I've realized that Subject is not a part of 
XMPP payload, it is a separate XML element. So I've made the text more 
generic.

I also want to allow for Sieve notify to be usable without variables.

>The use of "will be" instead of SHOULD/MUST makes this sentence pretty ignorable anyway.  As it stands it doesn't seem to want me to include as much of the message body as I can, which is clearly a nice feature.
>
>    <<Open issue: the previous version of this draft has defined the two
>      variables that can't be currently represented:
>
>         $text$     - the first text/* part
>
>         $text[n]$  - the first n bytes of the first text/* part
>    >>
>
>I'd like to drop both of these, and wait for other extensions used with VARIABLES to allow the behaviour.
>
Yes, this will need an extension to variables.

>  The syntax of the above doesn't sit well with VARIABLES.
>  
>
Right, I've just kept the original syntax as defined in Tim Martin's draft.

>-    The denotify action can be used to cancel a previous notification.
>+    The denotify action can be used to cancel previous notifications.
>  
>
Done.

>5.  Security Consideration
>
>Is there additional risk of mail loops when using this extension?
>  
>
Yes, if you use mailto: URI schema. Or any other notification method 
that can be getawayed to mail.
But this is not an issue specific to Sieve notify.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RB9qRa072659; Tue, 27 Sep 2005 04:09:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8RB9qeB072658; Tue, 27 Sep 2005 04:09:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RB9pXl072651 for <[e-mail]>; Tue, 27 Sep 2005 04:09:51 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.204]) by mail.rockliffe.com (Rockliffe SMTPRA 6.3.25) with ESMTP id <[e-mail]>; Tue, 27 Sep 2005 04:09:46 -0700
Message-ID: <015201c5c354$0f101ab0$050ac050@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]>
Subject: Re: Updated Sieve notification draft
Date: Tue, 27 Sep 2005 12:10:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8RB9pXl072653
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I took a stab at updating draft-martin-sieve-notify-01.txt, which should 
> be published soon as draft-ietf-sieve-notify-00.txt. The document is 
> attached.
> 
> The two major changes are:
> 1). updated the document to reference Sieve variables. Some notification 
> variables line "$text$" can't be mapped directly, but I will send a 
> separate message on this.
> 2). changed the document to use notification URIs, e.g. "sms:[phone]"
> 
> I remember there was a discussion few months ago about defining a 
> separate SMS notification mechanism. I just want to let people know that 
> the update I've made doesn't prevent any other documents in this area. 
> Just treat it as an input for discussion.

Abstract:
    This draft describes an extension to the Sieve mail filtering
    language that allows users to give specific preferences for
-    notification of Sieve actions.
+   notification of mail delivery.

That sounds like the extension allows you to be notified about an action, rather than a message.  I thought the significant event was the delivery of mail rather than a sieve action.  Similar comments apply to Introduction section.

    This document does not dictate the notification method used.
    Examples of possible notification methods are Zephyr and Jabber. The
-    method shall be site-defined.
+    available methods shall be site-defined.

Which makes me wonder if each desired "method" should really be available via a require command?

3.1 Notify Action
    In
    addition, if the notification method does not provide a timestamp,
    one SHOULD be appended to the notification.

Why bother with this?  While I agree it might be a sensible idea, I was surprised to see it as a SHOULD, I guess it's not a MUST though :o/

    If, for example, the user marks
    herself as "busy", an implementation SHOULD NOT send a notification
    for a new mailing list message with a priority of :low

This makes it sound like there are hard and fast rules between user status notifications and the setting of the priority parameter, yet the discussion is very brief and doesn't elaborate to rigorously define all those rules.  I also feel uneasy about adding syntax that permits only 3 levels of priority.   I think we should either drop the parameter, or extend it to allow an almost arbitrary number and style of priority statuses, even if we only define 3 for now.  I'm thinking of the Priority/X-Priority/X-MSMail-Priority mess in mail headers.  I'd suggest a string which could be used with the relational draft to do numeric comparisons if desired.

    If the message parameter is absent, a default message
    containing the value of the From header field and the value of the
    Subject header field will be used.

Could this be specific to the notification mechanism in use?  And can it just be left to be implementation specific?  The use of "will be" instead of SHOULD/MUST makes this sentence pretty ignorable anyway.  As it stands it doesn't seem to want me to include as much of the message body as I can, which is clearly a nice feature.

    <<Open issue: the previous version of this draft has defined the two
      variables that can't be currently represented:

         $text$     - the first text/* part

         $text[n]$  - the first n bytes of the first text/* part
    >>

I'd like to drop both of these, and wait for other extensions used with VARIABLES to allow the behaviour.  The syntax of the above doesn't sit well with VARIABLES.

-    The denotify action can be used to cancel a previous notification.
+    The denotify action can be used to cancel previous notifications.

5.  Security Consideration

Is there additional risk of mail loops when using this extension?

Cheers

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8R9oPRb066011; Tue, 27 Sep 2005 02:50:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8R9oPRm066010; Tue, 27 Sep 2005 02:50:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8R9oNpl066003 for <[e-mail]>; Tue, 27 Sep 2005 02:50:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Tue, 27 Sep 2005 10:50:19 +0100
Message-ID: <[e-mail]>
Date: Tue, 27 Sep 2005 10:50:15 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Mon, Sep 26, 2005, Alexey Melnikov <[e-mail]> said:
>  
>
>>...  When the "variables" extension is not enabled
>>   the explicit variable name parameter to setflag/addflag/removeflag
>>   MUST NOT be used and MUST cause an error according to [SIEVE].
>>    
>>
>
>I've noticed that a lot of the Sieve specs say to generate errors at
>"compile" time and I'm just wondering if there's a list of compile-time
>and run-time errors that are listed as MUST, SHOULD or MAY.
>
I think all errors are MUST. Otherwise scripts are not really portable.

Whether an error is catched at runtime or compile time - it depends on 
an implementation. Some implementations bytecompile Sieve, some 
implementations interpret it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QNswVF096459; Mon, 26 Sep 2005 16:54:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8QNswrl096458; Mon, 26 Sep 2005 16:54:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QNsvUQ096451 for <[e-mail]>; Mon, 26 Sep 2005 16:54:57 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id CFE3560934AB; Mon, 26 Sep 2005 16:54:56 -0700 (PDT)
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with SMTP id 0294860934AA; Mon, 26 Sep 2005 16:54:52 -0700 (PDT)
Date: Mon, 26 Sep 2005 23:54:52 -0000
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:43388a50153191075683240!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Sep 26, 2005, Alexey Melnikov <[e-mail]> said:
> ...  When the "variables" extension is not enabled
>    the explicit variable name parameter to setflag/addflag/removeflag
>    MUST NOT be used and MUST cause an error according to [SIEVE].

I've noticed that a lot of the Sieve specs say to generate errors at
"compile" time and I'm just wondering if there's a list of compile-time
and run-time errors that are listed as MUST, SHOULD or MAY. I'm also
wondering if someone's got a good solution to the Halting Problem? I've
been working at it for a while and it seems to be unsolvable...

Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QHKqPM062770; Mon, 26 Sep 2005 10:20:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8QHKpuR062769; Mon, 26 Sep 2005 10:20:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QHKoVa062762 for <[e-mail]>; Mon, 26 Sep 2005 10:20:51 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Mon, 26 Sep 2005 18:20:48 +0100
Message-ID: <[e-mail]>
Date: Mon, 26 Sep 2005 18:20:46 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: scoping and variables yet again
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>my suggestion is (text A), a complete reversal of behaviour:
>
>    Variables are only visible to the currently running script.
>
>the possibility of a different extension allowing a different scope is
>implicit -- everything not forbidden can be overridden :-).  the usage
>of the word "script" to mean a single fragment is consistent with other
>Sieve documents.  e.g., an extension needs to be declared via "require"
>in each script which uses it according to the base spec.
>
>Aaron Stone's suggestion is similar in effect, I think (text B):
>
>        All variables have global scope within a script. Future
>        specifications may allow for a script to be composed of more
>        than one file [part?], or for running more than one script per
>        message [delivery?]. Such specifications may provide for
>        different variable scoping rules.
>  
>
>it attempts to be more explicit, but I think it muddies more than it
>clarifies, to be honest.
>
>what is "global scope within a script"?  does this mean included scripts
>are affected?  what is a "script"?
>
Ok, I see your point.

How about replacing the first sentence of B with your proposal A.

The rest of the paragraph is trying to say that there would be other 
specification with different scoping rules, or additional operators that 
can declare a variable global for other scripts/imported from another 
script.

>  it may be unfortunate that we have
>no established term for the collection of scripts into a bigger whole,
>but as it is, I think "script" _is_ a single part (or file, or
>fragment).
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QEo3Ps047163; Mon, 26 Sep 2005 07:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8QEo3uJ047162; Mon, 26 Sep 2005 07:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QEo29N047140 for <[e-mail]>; Mon, 26 Sep 2005 07:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EJuIs-0006dc-8g; Mon, 26 Sep 2005 10:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-notify-00.txt 
Message-Id: <[e-mail]>
Date: Mon, 26 Sep 2005 10:50:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve -- An extension for providing instant notifications
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-notify-00.txt
	Pages		: 
	Date		: 2005-9-26
	
Users go to great lengths to be notified as quickly as possible that
they have received new mail. Most of these methods involve polling
to check for new messages periodically. A push method handled by the
final delivery agent gives users quicker notifications and saves
server resources. This document does not specify the notification
method but is expected that using existing instant messaging
infrastructure such as Zephyr, Jabber, or SMS messages will be popular.
This draft describes an extension to the Sieve mail filtering
language that allows users to give specific preferences for
notification of Sieve actions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-notify-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-notify-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-notify-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QEjj9s046876; Mon, 26 Sep 2005 07:45:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8QEjjlr046875; Mon, 26 Sep 2005 07:45:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QEjgX9046865 for <[e-mail]>; Mon, 26 Sep 2005 07:45:43 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.143] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 26 Sep 2005 15:45:18 +0100
Message-ID: <[e-mail]>
Date: Mon, 26 Sep 2005 15:45:17 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Philip Guenther <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Philip Guenther wrote:

>I'm not sure it's clear that the "variables" extension is 'present' if
>and only if it has actually been used with "require".  (You can't use
>the explicit variable name parameters if the "variables" extension is
>supported by the implementation but has not been enabled with
>"require".)  Perhaps the wording of the last paragraph of section 1
>could be tweaked to avoid that ambiguity?
>
Yes. I've updated the last paragraph of section 1 to read:

   The "imap4flags" extension can be used with or without the "variables"
   extension [VARIABLES]. When the "variables" extension is enabled in
   a script using <require "variables">, the script can use explicit
   variable names in setflag/addflag/removeflag actions. See also section
   3 for more details. When the "variables" extension is not enabled
   the explicit variable name parameter to setflag/addflag/removeflag
   MUST NOT be used and MUST cause an error according to [SIEVE].



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QEQpve045101; Mon, 26 Sep 2005 07:26:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8QEQpjX045100; Mon, 26 Sep 2005 07:26:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QEQoVq045094 for <[e-mail]>; Mon, 26 Sep 2005 07:26:50 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.143] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 26 Sep 2005 15:26:47 +0100
Message-ID: <[e-mail]>
Date: Mon, 26 Sep 2005 15:26:46 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Updated Sieve notification draft
Content-Type: multipart/mixed; boundary="------------080601090609070100030801"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------080601090609070100030801
Content-type: text/plain; charset="us-ascii"

Hi folks,
I took a stab at updating draft-martin-sieve-notify-01.txt, which should 
be published soon as draft-ietf-sieve-notify-00.txt. The document is 
attached.

The two major changes are:
1). updated the document to reference Sieve variables. Some notification 
variables line "$text$" can't be mapped directly, but I will send a 
separate message on this.
2). changed the document to use notification URIs, e.g. "sms:[phone]"

I remember there was a discussion few months ago about defining a 
separate SMS notification mechanism. I just want to let people know that 
the update I've made doesn't prevent any other documents in this area. 
Just treat it as an input for discussion.

Alexey


--------------080601090609070100030801
Content-type: text/plain; name="draft-ietf-sieve-notify-00.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-sieve-notify-00.txt"

Network Working Group                                    Alexey Melnikov
Document: draft-ietf-sieve-notify-00.txt                          Editor
Expires March 2006                                        September 2005


         Sieve -- An extension for providing instant notifications

Status of this Memo

     By submitting this Internet-Draft, each author represents that any
     applicable patent or other IPR claims of which he or she is aware
     have been or will be disclosed, and any of which he or she becomes
     aware will be disclosed, in accordance with Section 6 of BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts as
     reference material or to cite them other than as "work in
     progress".

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).


Abstract

    Users go to great lengths to be notified as quickly as possible that
    they have received new mail. Most of these methods involve polling
    to check for new messages periodically. A push method handled by the
    final delivery agent gives users quicker notifications and saves
    server resources. This document does not specify the notification
    method but is expected that using existing instant messaging
    infrastructure such as Zephyr, Jabber, or SMS messages will be popular.
    This draft describes an extension to the Sieve mail filtering
    language that allows users to give specific preferences for
    notification of Sieve actions.


1.  Introduction

    This is an extension to the Sieve language defined by [SIEVE] for
    providing instant notifications of sieve actions that have been
    preformed. It defines the new action "notify".

    This document does not dictate the notification method used.
    Examples of possible notification methods are Zephyr and Jabber. The
    method shall be site-defined.

    Sieve interpreters for which notifications are impractical or is not
    possible SHOULD ignore this extension.

    Conventions for notations are as in [SIEVE] section 1.1, including
    use of [KEYWORDS].


1.1.  Conventions Used in This Document
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [KEYWORDS].


2.  Capability Identifier

    The capability string associated with the extension defined in this
    document is "notify".


3.  Actions


3.1.  Notify action

    Usage:   notify [":method" string]
               [":id" string]
               [<":low" / ":normal" / ":high">]
               [":message" string]

    The Notify action specifies that a notification should be sent to
    the user upon successful handling of this message.

    The format of the notification is implementation-defined. However,
    all content specified in the notify action, including Sieve actions
    taken on the message, SHOULD be included. If errors occurred in
    another action they SHOULD be reported in the notification. In
    addition, if the notification method does not provide a timestamp,
    one SHOULD be appended to the notification. Implementations SHOULD
    NOT include extraneous information.

    The :method tag identifies the notification method that will be
    used, it is an URI. For examples, the notification method can
    be an SMS URI [SMS-URI] containing a phone number, or an XMPP [XMPP]
    URI containing Jabber identifier [XMPP-URI].
    If the :method tag is not specified, the default
    implementation defined notification method is used.  The
    possible values of this will be site-specific.  If an URI schema is
    specified that the implementation does not support, the notification
    MUST be ignored. An implementation treats this as a warning
    condition and execution of the sieve script MUST continue.

    The :id tag can be used to give the notify action an unique
    identifier. This identifier can be used later in the script to
    cancel the specific notify. The string may have any value and SHOULD
    NOT be included in the notification.

    The priority parameter specifies the importance of the notification.
    The priority parameter has the following values: ":high" (very
    important), ":normal", and ":low" (not very important). If no
    priority is given, a default priority of ":normal" SHOULD be
    assumed. Some notification methods allow users to specify their
    state of activity (for example "busy" or "away from keyboard"). If
    the notification method provides this information it SHOULD be used
    to selectively send notifications.  If, for example, the user marks
    herself as "busy", an implementation SHOULD NOT send a notification
    for a new mailing list message with a priority of :low, however the
    user should be notified of a high priority action.  If the
    notification method allows users to filter messages based upon
    certain parameters in the message, users should be able to filter
    based upon priority. If the notification method does not support
    priority, then this parameter MUST be ignored.

    The :message tag specifies the message data to be included in the
    notification. The entirety of the string SHOULD be sent but
    implementations MAY shorten the message for technical or aesthetic
    reasons. If the message parameter is absent, a default message
    containing the value of the From header field and the value of the
    Subject header field will be used. Note that the notification
    method (the ":method" tag) may affect how this information is
    formatted.
    In order to construct more complex messages
    the notify extension can be used together with the Sieve variables
    extension [VARIABLES], as shown at the end of this section.

    <<Open issue: the previous version of this draft has defined the two
      variables that can't be currently represented:

         $text$     - the first text/* part

         $text[n]$  - the first n bytes of the first text/* part
    >>

    If there are errors sending the notification, the Sieve interpreter
    SHOULD ignore the notification and not retry indefinitely.

    This action MUST NOT cancel the implicit keep.

    Example:
        require ["notify", "fileinto", "variables"];

        if header :contains "from" "[e-mail]" {
            notify :high :message "This is probably very important";
            # Don't send any further notifications
            stop;
        }

        if header :contains "to" "[e-mail]" {
            # :matches is used to get the value of the Subject header
            if header :matches "Subject" "*" {
                set "subject" "${1}";
            }

            # :matches is used to get the value of the From header
            if header :matches "From" "*" {
                set "from" "${1}";
            }

            notify :low :message "[SIEVE] ${from}: ${subject}";
            fileinto "INBOX.sieve";
        }

    Example:
        require ["notify", "fileinto", "variables", "envelope"];

        if header :matches "from" "*@*.example.org" {
            # :matches is used to get the MAIL FROM address
            if envelope :all :matches "from" "*" {
                set "env_from" " [really: ${1}]";
            }

            # :matches is used to get the value of the Subject header
            if header :matches "Subject" "*" {
                set "subject" "${1}";
            }

            # :matches is used to get the address from the From header
            if address :matches :all "from" "*" {
                set "from_addr" "${1}";
            }

            notify :message "${from_addr}${env_from}: ${subject}";
        }


3.2.  Denotify Action

    Usage: denotify [MATCH-TYPE string] [<":low" / ":normal" / ":high">]

    The denotify action can be used to cancel a previous notification.
    If the priority, ":low" / ":normal" / ":high", is specified, then
    only cancel those notifications with the specified priority.  If a
    MATCH-TYPE with a string is specified, then only those notifications
    whose :id tag matches the specified string using the match-type
    operator are canceled.  The ascii-casemap comparator MUST be used.

    If no notifications exist that match the search criteria, then the
    denotify has no effect.  A denotify only cancels notifications that
    have already been requested.  It is not possible to preemptively
    cancel a notification.

    The sequence:

      denotify;
      notify;

    will still generate a notification.  The denotify does not cancel
    the notify.

    The following table shows which notifies would get cancelled:

                                        # what is cancelled
      denotify                          # all notifications
      denotify :matches "*"             # all notifications with :id tag
      denotify :high                    # all high priority notifications
      denotify :is "foobar"             # all notifications with id "foobar"
      denotify :matches "foo*" :normal  # all normal priority notifications
                                        #   with id that starts with "foo"

    Example:

        require ["notify", "variables"];

        notify :method "xmpp:[e-mail]?You%20got%20mail&subject=SIEVE"
               :id "foobar";

        if header :contains "from" "[e-mail]" {
            # :matches is used to get the value of the Subject header
            if header :matches "Subject" "*" {
                set "subject" "${1}";
            }

            notify :method "sms:[phone]" :id "foobar"
                   :high :message "BOSS: ${subject}";
        }

        if header :contains "to" "[e-mail]" {
            denotify :is "foobar";
        }

        if header :contains "subject" "FYI:" {
            # don't need high priority notification for
            # a 'for your information'
            denotify :is "foobar" :high;
        }


4.  Interaction with Other Sieve Actions

    Notifications MUST be sent in all cases, unless a reject action is
    also executed. Users may wish to be notified of a message being
    discarded, for example. <<The reject action is given an exception
    because implementations may wish to restrict users from seeing the
    contents of a rejected message. However, notifications MAY be
    modified to not include any data from the original rejected message.>>

    The notify action MUST NOT cancel the implicit keep.

    The notify action is compatible with itself.

    The denotify action MUST NOT affect any actions other than the
    notify action.

    Failures of other actions MAY be reported in the notification.


5.  Security Considerations

    Security considerations are discussed in [SIEVE]. Additionally
    implementations must be careful to follow the security
    considerations of the specific notification methods. It is believed
    that this extension does not introduce any additional security
    concerns.

    The notify action is potentially very dangerous.  The path the
    notification takes through the network may not be secure.  An error
    in the options string may cause the message to be transmitted to
    someone it was not intended for.

    Just because a notification is received doesn't mean it was sent by
    the sieve implementation.  It might be possible to forge
    notifications with some notification methods.


6.  IANA Considerations

   The following template specifies the IANA registration of the
   variables Sieve extension specified in this document:

   To: [e-mail]
   Subject: Registration of new Sieve extension
   Capability name: notify
   Capability keyword: notify
   Capability arguments: N/A
   Standards Track/IESG-approved experimental RFC number:
           this RFC
   Person and email address to contact for further information:
           Alexey Melnikov <[e-mail]>

   This information should be added to the list of sieve extensions
   given on http://www.iana.org/assignments/sieve-extensions.


7.  Acknowledgments

    Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Barry
    Leiba, and Cyrus Daboo for help with this document.


8.  References

8.1.  Normative References

    [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
    Requirement Levels", BCP 14, RFC 2119, March 1997.

    [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
    ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
    November 1997. <<needs updating>>

    [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering
    Language", work in progress, draft-ietf-sieve-3028bis-XX.txt.


8.2.  Informative References

    [VARIABLES] Homme, K., "Sieve Extension: Variables", work in
    progress, draft-ietf-sieve-variables-XX.txt.

    [XMPP]

    [XMPP-URI] Saint-Andre, P., "A Uniform Resource Identifier (URI)
    Scheme for the Extensible Messaging and Presence Protocol (XMPP)",
    work in progress, draft-saintandre-xmpp-uri-XX.txt.

    [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short
    Message Service", work in progress, draft-wilde-sms-uri-XX.txt.


9.  Author's and Editor's Addresses

    Tim Martin
    Mirapoint Inc.
    909 Hermosa Court
    Sunnyvale, CA 94085

    Phone: [phone]
    EMail: [e-mail]

    Wolfgang Segmuller
    IBM T.J. Watson Research Center
    30 Saw Mill River Rd
    Hawthorne, NY  10532

    Phone: [phone]
    Email: [e-mail]


    Alexey Melnikov (Editor)
    Isode Limited
    5 Castle Business Village
    36 Station Road
    Hampton, Middlesex
    TW12 2BX, UK

    Email: [e-mail]


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

--------------080601090609070100030801--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q9isSE017858; Mon, 26 Sep 2005 02:44:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8Q9isBI017857; Mon, 26 Sep 2005 02:44:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q9irlB017850 for <[e-mail]>; Mon, 26 Sep 2005 02:44:54 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1EJpXY-0006DB-He for [e-mail]; Mon, 26 Sep 2005 11:44:52 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EJpXY-0008Dy-GQ for [e-mail]; Mon, 26 Sep 2005 11:44:52 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #11) id 1EJpXX-0004yF-5z for [e-mail]; Mon, 26 Sep 2005 11:44:51 +0200
Date: Mon, 26 Sep 2005 11:44:51 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Sep 23, 2005 at 10:44:56PM +0100, Alexey Melnikov wrote:
> >well, this stripping only happens for relational tests, not ":is" and
> >friends.  although it's a trap for the unwary, it's not a big problem,
> >IMO.  you can work around it when needed by using explicit begin and end
> >markers in both strings:
> >
> >       if string :gt "!${var1}!" "!${var2}!" ...
> >
> >an example of this technique may be useful.
> > 
> >
> This would work but it is a hack!
> I would rather say that for headers, relational strips leading and 
> trailing spaces, but for other things, like addresses and variables - it 
> does not.

If you go as far as breaking backward compatibility, then I suggest to let
"i;ascii-numeric" ignore heading and trailing white space when used with
the relational extension, and Sieve base comparators like "en;ascii-case"
obey it.  Numbers are numbers and strings are strings, and the latter may
contain white space and string comparisons in general do not ignore it.

The obvious solution would be to add an option :full to keep all white
space and to strip it otherwise, as done before.  I am not sure it's
worth it, though.  The next person may suggest two options for heading
and trailing white space and the third will suggest string functions,
and that's probably the most universal solution, but a whole different
thing than the relational extension.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q9HpBZ015658; Mon, 26 Sep 2005 02:17:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8Q9Hpxa015657; Mon, 26 Sep 2005 02:17:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q9Honk015651 for <[e-mail]>; Mon, 26 Sep 2005 02:17:50 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.143] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 26 Sep 2005 10:17:36 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 22:44:56 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: "Mark E. Mallett" <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Thu, 2005-09-22 at 13:26 -0400, Mark E. Mallett wrote:
>  
>
>>On Wed, Sep 21, 2005 at 04:41:58PM +0100, Alexey Melnikov wrote:
>>    
>>
>>>Hi folks,
>>>One of the questions raised during the WGLC of 
>>>draft-ietf-sieve-3431bis-01.txt was concerning the following text in the 
>>>draft:
>>>      
>>>
>>>>3.1.  Match Type Value
>>>>        
>>>>
>>>[...]
>>>      
>>>
>>>>  Leading and trailing white space MUST be removed from the value of
>>>>  the message for the comparison.  White space is defined as
>>>>
>>>>      SP / HTAB / CRLF
>>>>        
>>>>
>>>I would like to poll people who've implemented the relational draft/RFC 
>>>if they've been following this rule.
>>>      
>>>
>>Yes but probably not because of that draft, but because that's what the
>>associated tests do, relational or not.  As I mentioned, if I had [yet]
>>implemented the variables draft, I probably would question the
>>whitespace skipping on the first argument in the "string" test.
>>    
>>
>
>well, this stripping only happens for relational tests, not ":is" and
>friends.  although it's a trap for the unwary, it's not a big problem,
>IMO.  you can work around it when needed by using explicit begin and end
>markers in both strings:
>
>        if string :gt "!${var1}!" "!${var2}!" ...
>
>an example of this technique may be useful.
>  
>
This would work but it is a hack!
I would rather say that for headers, relational strips leading and 
trailing spaces, but for other things, like addresses and variables - it 
does not.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8O0rYFW017414; Fri, 23 Sep 2005 17:53:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8O0rYbF017413; Fri, 23 Sep 2005 17:53:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8O0rXGG017407 for <[e-mail]>; Fri, 23 Sep 2005 17:53:33 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 23 Sep 2005 17:53:27 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1127523206; h=Date: 	 From:Subject:MIME-version:Content-type; b=1ksllZ5u/yKswBAwcAcl0jFC6 3bg2Fd2MJauIxU14oi2Oyv4qQzsnkvCrrTZeOqbez+cek9WyS/f0m6+5NmWHQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 23 Sep 2005 17:53:24 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
To: Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 23 Sep 2005 17:52:57 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Security review of SIEVE vacation
In-reply-to: "Your message dated Wed, 14 Sep 2005 10:43:10 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=KOI8-R; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ned Freed wrote:

> >> Section 3.7 says "The vacation is incompatible with reject.".  I think
> >> there are some words missing there.
> >
> > I'll change this to read "the vacaction action is incompatible with
> > the sieve
> > reject action".

> Which reminds me: reject is now defined in a separate document and there
> is no reference to it.

FYI, this is fixed in the -03 version.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NGNrJA073397; Fri, 23 Sep 2005 09:23:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NGNrKW073396; Fri, 23 Sep 2005 09:23:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NGNr19073388 for <[e-mail]>; Fri, 23 Sep 2005 09:23:53 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 23 Sep 2005 09:23:48 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1127492627; h=MIME-version: 	 Content-transfer-encoding:Content-type:Date:From:Subject; b=JCivvpD 	bIACwQd0IPD7U8RYtE7wbAGD4tIeqSNDzN7QYQ9f480frUcYE/LsMhGRN5SC3EeoV0m uEmw5e6WWJCA==
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 23 Sep 2005 09:23:43 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, MTA filtering mailing list <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 23 Sep 2005 09:22:04 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt
In-reply-to: "Your message dated Fri, 23 Sep 2005 11:58:49 +0200" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Thu, 2005-09-22 at 19:54 -0700, Ned Freed wrote:
> > > Section 4.3 requires support for RFC 2047 encoding of the subject;
> > > should that same requirement be placed on any phrase portion of the
> > > from?
> >
> > Right now the text says you have to construct something that's a syntactically
> > valid mailbox-list, which would preclude any 8bit material. I'm reluctant to
> > change that since it gets into the issue of exactly how you take structured
> > header content that contains 8bit and convert it to something legal.

> IDNA is relevant for mailbox-list, e.g. [e-mail]
> which is "kjetilho@sørlandslaget.no" to a user expecting "everything" in
> Sieve to be UTF-8.  but I think IDNA in "vacation" should wait until
> IDNA is in the base spec (e.g. "address" test), in other words, not yet.

The binding and use of IDNA in email isn't specified yet, so even talking about
it in the base specific would be premature.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NDCMA0054829; Fri, 23 Sep 2005 06:12:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NDCMvE054828; Fri, 23 Sep 2005 06:12:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NDCK8u054815 for <[e-mail]>; Fri, 23 Sep 2005 06:12:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EInLb-0001d8-KV; Fri, 23 Sep 2005 15:12:15 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EInLT-00068j-OJ; Fri, 23 Sep 2005 15:12:07 +0200
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 23 Sep 2005 15:11:54 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.764, required 12, autolearn=disabled, AWL 1.05, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-09-23 at 14:05 +0200, Michael Haardt wrote:
> On Fri, Sep 23, 2005 at 11:48:34AM +0100, Alexey Melnikov wrote:
> > >Examples are very good, but what I love most is a short summary of the
> > >important points (in this case, that all comparators of the base language
> > >do return sort information),
> > >
> > So basically you asking for a note that both "i;octet" and 
> > "en;ascii-casemap" support sorting?
> 
> Yes, and "i;ascii-numeric", please.  It is not much duplicated information
> and it save from having to look it up in the comparator draft to be
> 100% sure.

you MUST look it up in the comparator draft to be 100% sure, since
"relational" isn't normative for this behaviour.  such an added note is
only good enough to be 99% sure.

(I don't like duplication, but I don't have any strong opinion on this
particular addition.)
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NC5ZDF048903; Fri, 23 Sep 2005 05:05:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NC5Zuv048902; Fri, 23 Sep 2005 05:05:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NC5Yq2048896 for <[e-mail]>; Fri, 23 Sep 2005 05:05:35 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.53-RC2) id 1EImJ3-0002zK-HY for [e-mail]; Fri, 23 Sep 2005 14:05:33 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EImJ3-0007Vq-EU for [e-mail]; Fri, 23 Sep 2005 14:05:33 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #11) id 1EImIy-0003oi-3B for [e-mail]; Fri, 23 Sep 2005 14:05:28 +0200
Date: Fri, 23 Sep 2005 14:05:28 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Sep 23, 2005 at 11:48:34AM +0100, Alexey Melnikov wrote:
> >Examples are very good, but what I love most is a short summary of the
> >important points (in this case, that all comparators of the base language
> >do return sort information),
> >
> So basically you asking for a note that both "i;octet" and 
> "en;ascii-casemap" support sorting?

Yes, and "i;ascii-numeric", please.  It is not much duplicated information
and it save from having to look it up in the comparator draft to be
100% sure.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NB1Urn042351; Fri, 23 Sep 2005 04:01:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NB1UhK042350; Fri, 23 Sep 2005 04:01:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NB1Ttk042344 for <[e-mail]>; Fri, 23 Sep 2005 04:01:29 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.119] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 23 Sep 2005 12:01:24 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 12:01:23 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Philip Guenther <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Philip. I am answering to part of your comments and will get to 
the rest later on.

Philip Guenther wrote:

>Why is the [Variables] reference mixed cased instead of being
>[VARIABLES]?
>  
>
Changed.

>The ignoring of extra spaces in flag lists should include leading and
>trailing spaces.
>
Ok, section 2.1, the middle of the third paragraph now reads:

   However spaces MUST be always allowed. Multiple
   spaces between flag names MUST be treated as a single space character,
   leading and trailing spaces MUST be ignored.

>Should tabs and CRLF pairs also be ignored?
>
No :-).

>That
>would let applications use multiline literals:
>	addflag "flagvar" text:
>	\deleted \answered
>	.
>
>  
>
[...]

>The third paragraph of section 4 regarding "hasflag" and reordering
>makes no sense to me.  "hasflag" must split the supplied list of flag
>and then iterate across it, but since it returns true if *any* of the
>flags are present, the relative order of the flags doesn't matter, no?
>
You are right. The paragraph should be deleted.

>There's no way to test whether a variable contains _only_ certain flags,
>but I don't think that's needed either.
>
I don't think this is needed, as different flags are independent.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NAmoIa041346; Fri, 23 Sep 2005 03:48:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NAmogX041345; Fri, 23 Sep 2005 03:48:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NAmnsp041338 for <[e-mail]>; Fri, 23 Sep 2005 03:48:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.119] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 23 Sep 2005 11:48:36 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Sep 2005 11:48:34 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt  (relational test)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>>When I edit a document I usually try to add lots of examples to address 
>>issues like yours.
>>    
>>
>Examples are very good, but what I love most is a short summary of the
>important points (in this case, that all comparators of the base language
>do return sort information),
>
So basically you asking for a note that both "i;octet" and 
"en;ascii-casemap" support sorting?

> a reference where to read it in detail AND
>examples. :-)
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NA1qas036835; Fri, 23 Sep 2005 03:01:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NA1qxl036834; Fri, 23 Sep 2005 03:01:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NA1oxo036826 for <[e-mail]>; Fri, 23 Sep 2005 03:01:51 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1EIkNG-0000Hn-QY; Fri, 23 Sep 2005 12:01:46 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EIkKW-0007FG-Hd; Fri, 23 Sep 2005 11:58:56 +0200
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Date: Fri, 23 Sep 2005 11:58:49 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.699, required 12, autolearn=disabled, AWL 1.11, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8NA1pxo036829
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2005-09-22 at 19:54 -0700, Ned Freed wrote:
> > Section 4.3 requires support for RFC 2047 encoding of the subject;
> > should that same requirement be placed on any phrase portion of the
> > from?
> 
> Right now the text says you have to construct something that's a syntactically
> valid mailbox-list, which would preclude any 8bit material. I'm reluctant to
> change that since it gets into the issue of exactly how you take structured
> header content that contains 8bit and convert it to something legal.

IDNA is relevant for mailbox-list, e.g. [e-mail]
which is "kjetilho@sørlandslaget.no" to a user expecting "everything" in
Sieve to be UTF-8.  but I think IDNA in "vacation" should wait until
IDNA is in the base spec (e.g. "address" test), in other words, not yet.
-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N3LU5J099491; Thu, 22 Sep 2005 20:21:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N3LUwL099490; Thu, 22 Sep 2005 20:21:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N3LTwD099484 for <[e-mail]>; Thu, 22 Sep 2005 20:21:29 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8N3LTKV009592 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 22 Sep 2005 20:21:29 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j8N3LTKV009592
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=sNd+bK73yGmWJQIbkQDo3UmGyKqYZbX9dvJx/69hAVq1iBFScwOYAtVLwrYW12kYn dvMzasZocgw6mGGt8QVTyfXGyDvlBn4EbOT+aHjAWiZjxFUz8f5PCZ8ZinaAPX8j9aq kCnuX34Lhh7EMejuUa7YdJuvMVwa47UaMT+CTiA=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j8N3LTRZ025284; Thu, 22 Sep 2005 20:21:29 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Thu, 22 Sep 2005 20:21:29 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed <[e-mail]> writes:
...
>> Section 4.3 requires support for RFC 2047 encoding of the subject;
>> should that same requirement be placed on any phrase portion of the
>> from?
>
>Right now the text says you have to construct something that's a
>syntactically valid mailbox-list, which would preclude any 8bit
>material. I'm reluctant to change that since it gets into the issue
>of exactly how you take structured header content that contains
>8bit and convert it to something legal.

Oops, right.  I withdraw the comment/suggestion.

(Hmmm, if you ban comments and refuse to encode a comma, I think
it would be unambiguous, but oof, that would be an ugly spec.)


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N35rgp098143; Thu, 22 Sep 2005 20:05:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N35rL8098142; Thu, 22 Sep 2005 20:05:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N35qej098136 for <[e-mail]>; Thu, 22 Sep 2005 20:05:52 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 22 Sep 2005 20:05:51 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1127444750; h=Date: 	 From:Subject:MIME-version; b=FmABN6KUnQx8lCwKqynxvwuwMk76iSLBsn7RCR 4PG0r60kLGCOu91gcbbGaJco0AUUSvkAFQgRjL8Fff0Rx9uw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 22 Sep 2005 20:05:48 -0700 (PDT)
Cc: MTA filtering mailing list <[e-mail]>
To: Philip Guenther <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 22 Sep 2005 19:54:39 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt
In-reply-to: "Your message dated Thu, 22 Sep 2005 19:35:50 -0700" <[e-mail]>
MIME-version: 1.0
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> In section 2, since when did RFC 2119 define "CAN"?

Wierd. I'll replace it with "REQUIRED", which is used and should be on the
list.

> Do the references to SMTP MAIL FROM require at least an informative
> reference to RFC 2821?

Probably not required, but it doesn't hurt to add it.

> Section 4.3 requires support for RFC 2047 encoding of the subject;
> should that same requirement be placed on any phrase portion of the
> from?

Right now the text says you have to construct something that's a syntactically
valid mailbox-list, which would preclude any 8bit material. I'm reluctant to
change that since it gets into the issue of exactly how you take structured
header content that contains 8bit and convert it to something legal. This is
very different than converting text to stuff into an unstructured header and
not specified anywhere AFAIK. I really don't think this document is the place
to get into it.

> An example using the :mime parameter would be nice.  How about:
> 	require "vacation";
> 	vacation :mime text:
> 	Content-Type: multipart/alternative; boundary=foo
	
> 	--foo
	
> 	I'm at the beach relaxing.  Mmmm, surf...

> 	--foo
> 	Content-Type: text/html; charset=us-ascii

> 	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
> 	     "http://www.w3.org/TR/REC-html40/strict.dtd">
> 	<HTML><HEAD><TITLE>How to relax</TITLE>
> 	<BASE HREF="http://home.example.com/pictures/"></HEAD>
> 	<BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
> 	Mmmm, <A HREF="ocean.gif">surf</A>...
> 	</BODY></HTML>

> 	--foo--
> 	.

Why not? Added.

> In section 5, there's a space missing between the RFC3461 reference and
> the next word, "is".

Fixed.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N2gCCR095066; Thu, 22 Sep 2005 19:42:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N2gCBb095065; Thu, 22 Sep 2005 19:42:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N2gBB8095058 for <[e-mail]>; Thu, 22 Sep 2005 19:42:11 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8N2g1tm002920 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 22 Sep 2005 19:42:01 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j8N2g1tm002920
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=mjlLWTsaDyKdDZGaGyCYUkisEea9YtrIeRghmkkhJRZ6IcZmI0nhIHUViNxJmbHls QW032YO4XKSjx/H1T25zoQLjI3fVYrmISZ6X1ee0wE+LpsteRVroRkJHZ8cli6fwsGv ChVfm8wKqnyWRn4cJs+Qxu8O2ldbVElzRDDDovk=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j8N2g14x022516; Thu, 22 Sep 2005 19:42:01 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: removeflag \recent 
In-reply-to: <[e-mail]> 
References: <1126767529.24991.37.camel@localhost> <[e-mail]> <x6j/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Thu, 22 Sep 2005 19:42:00 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme <[e-mail]> writes:
...
>as long as there is no facility for accessing such logs in Sieve, I
>think the spec shouldn't be mentioning any.  what gets logged or not is
>an administrative issue.

Exactly.  I like your suggested text too.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N2Zprt094377; Thu, 22 Sep 2005 19:35:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N2ZpIH094376; Thu, 22 Sep 2005 19:35:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N2ZpBD094369 for <[e-mail]>; Thu, 22 Sep 2005 19:35:51 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8N2ZpVt001934 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Thu, 22 Sep 2005 19:35:51 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j8N2ZpVt001934
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=fQxyGxks4WMtvH6FirnIqfuWafi/jdGwKN616qll0Znt/rQwxv2RnPcTy4+1WvRbT Gdjg33tfQufWAdhWj9jOXHfSyjEMpm1X/Or5/dmqWghntpUstpBZo+tiRG4J6BzMlDg GHiQrTMjC3YT/pS1H7p3570QsZR3QnVCeNsiZlk=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j8N2Zol9022090 for <[e-mail]>; Thu, 22 Sep 2005 19:35:50 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> 
Date: Thu, 22 Sep 2005 19:35:50 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In section 2, since when did RFC 2119 define "CAN"?

Do the references to SMTP MAIL FROM require at least an informative
reference to RFC 2821?

Section 4.3 requires support for RFC 2047 encoding of the subject;
should that same requirement be placed on any phrase portion of the
from?

An example using the :mime parameter would be nice.  How about:
	require "vacation";
	vacation :mime text:
	Content-Type: multipart/alternative; boundary=foo
	
	--foo
	
	I'm at the beach relaxing.  Mmmm, surf...

	--foo
	Content-Type: text/html; charset=us-ascii

	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
	     "http://www.w3.org/TR/REC-html40/strict.dtd">
	<HTML><HEAD><TITLE>How to relax</TITLE>
	<BASE HREF="http://home.example.com/pictures/"></HEAD>
	<BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
	Mmmm, <A HREF="ocean.gif">surf</A>...
	</BODY></HTML>

	--foo--
	.


In section 5, there's a space missing between the RFC3461 reference and
the next word, "is".


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N22cQ6091412; Thu, 22 Sep 2005 19:02:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N22cpP091411; Thu, 22 Sep 2005 19:02:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N22cV3091400 for <[e-mail]>; Thu, 22 Sep 2005 19:02:38 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8N22ZsU028759 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Thu, 22 Sep 2005 19:02:36 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j8N22ZsU028759
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=CZvxsL5CcQEOfTAZ7s39cWxQ2mkGA/1xeV6QyRfn2eAN9vnPvRvOuUulSlEC9y7JQ xcNPCO6Bs63fQqV/S/VS1+K4AiHOOrjven/9M/yPF6p0wO/SrO5Yi6Lq9nPdzsH8UGV 7tM4aOntR72ho8ntXgSvrxH2JvoVBXEQmxCheMY=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j8N22ZNN019712 for <[e-mail]>; Thu, 22 Sep 2005 19:02:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> 
Date: Thu, 22 Sep 2005 19:02:35 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In section 1, I suggest changing
   Sieve interpreters that don't support integration with IMAP SHOULD
   ignore this extension.
to
   This extension is only appropriate for sieve interpreters that
   support integration with IMAP.
(What does it mean for an interpreter to 'ignore' an extension?)


Why is the [Variables] reference mixed cased instead of being
[VARIABLES]?


I'm not sure it's clear that the "variables" extension is 'present' if
and only if it has actually been used with "require".  (You can't use
the explicit variable name parameters if the "variables" extension is
supported by the implementation but has not been enabled with
"require".)  Perhaps the wording of the last paragraph of section 1
could be tweaked to avoid that ambiguity?


The ignoring of extra spaces in flag lists should include leading and
trailing spaces.  Should tabs and CRLF pairs also be ignored?  That
would let applications use multiline literals:
	addflag "flagvar" text:
	\deleted \answered
	.


I think the third sentence of section 3.2 should be flipped around, if
just to avoid "MAY NOT" (while "MAY" is an RFC 2119 keyword, "MAY NOT"
isn't!).  Indeed, I would give the implementation even more leeways,
ala:
   The addflag action MAY alter the flag list in any way that leaves the
   its semantics as a set of case-insensitive words unaltered.  For
   example, it may reorder the flags, alter the case of the letters in
   them, or add or remove duplicates or extraneous spaces.  Scripts
   SHOULD NOT make assumptions about the ordering of flags in lists or
   the preservation of their case.

Hmm, written like that, that chunk probably belongs in section 3 and not
3.2, especially when generallized to cover "setflag" and "removeflag" as
well.

The above also obsoletes the second paragraph of section 6 ("A script
interpreter..."), which seemed oddly placed to me anyway.


The third paragraph of section 4 regarding "hasflag" and reordering
makes no sense to me.  "hasflag" must split the supplied list of flag
and then iterate across it, but since it returns true if *any* of the
flags are present, the relative order of the flags doesn't matter, no?

There's no way to test whether a variable contains _only_ certain flags,
but I don't think that's needed either.


The two sample implementations of "addflag" should be next to each
other.


The sample "removeflag" implementation in section 6 is incorrect, as it
will only remove a single occurence of the given flag.  (Even if
"addflag" performs duplicate elimination, "removeflag" must still handle
multiple occurences as the user may have altered the variable directly
with "set".)


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MM2B7m072931; Thu, 22 Sep 2005 15:02:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MM2Bew072930; Thu, 22 Sep 2005 15:02:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MM2Ac7072924 for <[e-mail]>; Thu, 22 Sep 2005 15:02:11 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8MM29Ua016433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 22 Sep 2005 15:02:09 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j8MM29Ua016433
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=Q9/g+ZD9W2nwC31pFV//VEOFswxoahmrfBGOBjirOWvjnJR84R6fMqwTQY8WxdyrK PToX3z99TX5MhuxOn0QOhV9gr+pyLW2oeyk8/ZkhUH7o74Bz/VVvxMAJ/YtOuR+90O8 zmaG3JwKKOnZg1iekpLMA3g5eRq5r+f3PZ5PHwk=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j8MM28k3001519; Thu, 22 Sep 2005 15:02:09 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft 
In-reply-to: <[e-mail]> 
References: <[e-mail]> 
Date: Thu, 22 Sep 2005 15:02:08 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:
...
>I would like to poll people who've implemented the relational draft/RFC 
>if they've been following this rule.

Sendmail's sieve implementation has always done so

Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MKZ7Jd066097; Thu, 22 Sep 2005 13:35:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MKZ70Y066096; Thu, 22 Sep 2005 13:35:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MKZ6mN066089 for <[e-mail]>; Thu, 22 Sep 2005 13:35:06 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EIXmb-0008EK-PX for [e-mail]; Thu, 22 Sep 2005 22:35:05 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EIXmb-0006t2-O1 for [e-mail]; Thu, 22 Sep 2005 22:35:05 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #10) id 1EIXma-0003QV-ER for [e-mail]; Thu, 22 Sep 2005 22:35:04 +0200
Date: Thu, 22 Sep 2005 22:35:04 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Sep 21, 2005 at 06:40:43PM +0100, Alexey Melnikov wrote:
> >>"relational" draft is not the place for listing such comparators. There 
> >>is a separate document (currently draft-newman-i18n-comparator-05.txt) 
> >>that defines the comparator registry. 

> >I guess you are right that duplicating information is not good, but the
> >Sieve base language contains so few comparators, that it would be nice
> >to state that those return sort information.

> Maybe you are asking for a reference to the comparator registry after 
> the quoted sentence?

Probably.

> When I edit a document I usually try to add lots of examples to address 
> issues like yours.

Examples are very good, but what I love most is a short summary of the
important points (in this case, that all comparators of the base language
do return sort information), a reference where to read it in detail AND
examples. :-)

> On a somewhat related note: do people think we need a comparator that 
> can handle negative numbers?

At first, I thought it was odd not to have one, but as a matter of fact,
I never missed it.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MKSfbU065642; Thu, 22 Sep 2005 13:28:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MKSfGL065641; Thu, 22 Sep 2005 13:28:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MKSeF5065631 for <[e-mail]>; Thu, 22 Sep 2005 13:28:40 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EIXgN-0004B0-Cf for [e-mail]; Thu, 22 Sep 2005 22:28:39 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EIXgN-0004LI-AL for [e-mail]; Thu, 22 Sep 2005 22:28:39 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #10) id 1EIXgJ-0003QE-W5 for [e-mail]; Thu, 22 Sep 2005 22:28:36 +0200
Date: Thu, 22 Sep 2005 22:28:35 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-03.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Sep 22, 2005 at 10:35:11AM -0700, Ned Freed wrote:
> > Section 4.6, "Restricting Replies to Automated Processes and Mailing Lists"
> > gives a list of List-* header fields.  Is it certain that no other fields
> > are in use?
> 
> No, but neither is it certain that other list-* fields, when used, actually
> mean the message is from a list and should be exempt from vacation responses.
> 
> That's why I opted for an explicit list of fields in the document.

That's what I guessed what might have been the reason.  I have a slight
preference for that as well and will look into getting this changed in
Exim.  

It is amazing how many odd ends Sieve helps to fix.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIpT0L056948; Thu, 22 Sep 2005 11:51:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MIpT7q056947; Thu, 22 Sep 2005 11:51:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIpSTu056941 for <[e-mail]>; Thu, 22 Sep 2005 11:51:29 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1EIWAH-0000Z7-JJ; Thu, 22 Sep 2005 20:51:25 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EIWAA-00057M-6N; Thu, 22 Sep 2005 20:51:18 +0200
Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 22 Sep 2005 20:51:11 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.618, required 12, autolearn=disabled, AWL 1.20, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2005-09-22 at 13:26 -0400, Mark E. Mallett wrote:
> On Wed, Sep 21, 2005 at 04:41:58PM +0100, Alexey Melnikov wrote:
> > Hi folks,
> > One of the questions raised during the WGLC of 
> > draft-ietf-sieve-3431bis-01.txt was concerning the following text in the 
> > draft:
> > 
> > >3.1.  Match Type Value
> > [...]
> > >   Leading and trailing white space MUST be removed from the value of
> > >   the message for the comparison.  White space is defined as
> > >
> > >       SP / HTAB / CRLF
> > 
> > I would like to poll people who've implemented the relational draft/RFC 
> > if they've been following this rule.
> 
> Yes but probably not because of that draft, but because that's what the
> associated tests do, relational or not.  As I mentioned, if I had [yet]
> implemented the variables draft, I probably would question the
> whitespace skipping on the first argument in the "string" test.

well, this stripping only happens for relational tests, not ":is" and
friends.  although it's a trap for the unwary, it's not a big problem,
IMO.  you can work around it when needed by using explicit begin and end
markers in both strings:

        if string :gt "!${var1}!" "!${var2}!" ...

an example of this technique may be useful.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHxu3g051263; Thu, 22 Sep 2005 10:59:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MHxuaV051262; Thu, 22 Sep 2005 10:59:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHxtfc051253 for <[e-mail]>; Thu, 22 Sep 2005 10:59:56 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.165] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 22 Sep 2005 18:59:52 +0100
Message-ID: <[e-mail]>
Date: Thu, 22 Sep 2005 18:59:52 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: removeflag \recent
References: <1126767529.24991.37.camel@localhost>	 <[e-mail]>	 <x6j/[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Wed, 2005-09-21 at 16:05 +0100, Alexey Melnikov wrote:
>  
>
>>Philip Guenther wrote:
>>    
>>
>>>> Note that it is not possible to use this extension to set or clear the
>>>> \Recent flag or any other special system flag which is not settable
>>>> in [IMAP]. If the \Recent flag is included in a flag list, it MUST be
>>>> silently ignored, but a warning message SHOULD be logged by the Sieve
>>>> interpreter.
>>>>        
>>>>
>>>[...]
>>>However, the suggestion that the implementation should log these events
>>>is kinda weird.  In my experience, admins have *no* interest in being
>>>bothered by this stuff.
>>>      
>>>
>>As Rob pointed out, the draft doesn't actually say what kind of logging 
>>should be done.
>>Some kind of user specific logging would be useful, so that people can 
>>answer a question like "why such and such flag is not being set".
>>
>>Should I change the "SHOULD" to "should"?
>>Should the draft explain this in more details?
>>    
>>
>
>as long as there is no facility for accessing such logs in Sieve, I
>think the spec shouldn't be mentioning any.  what gets logged or not is
>an administrative issue.
>
>I'd drop the text after the comma, and also remove the "silently", since
>it may be taken to mean that no logging is allowed.  what happens to
>special system flags other than \Recent?  shouldn't the behaviour be the
>same?
>
Yes, even though there is no other special flag at the moment.

>suggested replacement text (only the last sentence is different):
>
>        Note that it is not possible to use this extension to set or
>        clear the \Recent flag or any other special system flag which is
>        not settable in [IMAP]. Any such flags MUST be ignored if
>        included in a flag list.
>  
>
Done.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHur33051066; Thu, 22 Sep 2005 10:56:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MHur3h051065; Thu, 22 Sep 2005 10:56:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8MHuqtH051048 for <[e-mail]>; Thu, 22 Sep 2005 10:56:52 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 667 invoked by uid 101); 22 Sep 2005 13:56:51 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 22 Sep 2005 13:56:51 -0400
To: [e-mail]
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Sep 22, 2005 at 10:11:12AM -0700, Ned Freed wrote:
> 
> >Hi folks,
> >One of the questions raised during the WGLC of
> >draft-ietf-sieve-3431bis-01.txt was concerning the following text in the
> >draft:
> 
> > >3.1.  Match Type Value
> >[...]
> > >   Leading and trailing white space MUST be removed from the value of
> > >   the message for the comparison.  White space is defined as
> > >
> > >       SP / HTAB / CRLF
> 
> >I would like to poll people who've implemented the relational draft/RFC
> >if they've been following this rule.
> 
> We handled the leading white space this way but not the trailing in this 
> way.

Shoot... having read that, I see that I ignored the "trailing" part in
the question, so I'll have to amend my response.  For 'header' test,
leading spaces are skipped, trailing are not.  I believe that address
tests are coded to work on address parts that have had leading and
trailing spaces removed.

Pardon,
mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHqNFb050049; Thu, 22 Sep 2005 10:52:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MHqN3u050048; Thu, 22 Sep 2005 10:52:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHqMjJ050012 for <[e-mail]>; Thu, 22 Sep 2005 10:52:22 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1EIVF4-0002XF-Gu; Thu, 22 Sep 2005 19:52:18 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EIVEy-0006w3-W3; Thu, 22 Sep 2005 19:52:13 +0200
Subject: Re: removeflag \recent
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <1126767529.24991.37.camel@localhost> <[e-mail]> <x6j/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 22 Sep 2005 19:51:54 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.483, required 12, autolearn=disabled, AWL 1.33, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 2005-09-21 at 16:05 +0100, Alexey Melnikov wrote:
> Philip Guenther wrote:
> >>  Note that it is not possible to use this extension to set or clear the
> >>  \Recent flag or any other special system flag which is not settable
> >>  in [IMAP]. If the \Recent flag is included in a flag list, it MUST be
> >>  silently ignored, but a warning message SHOULD be logged by the Sieve
> >>  interpreter.
> >[...]
> >However, the suggestion that the implementation should log these events
> >is kinda weird.  In my experience, admins have *no* interest in being
> >bothered by this stuff.
>
> As Rob pointed out, the draft doesn't actually say what kind of logging 
> should be done.
> Some kind of user specific logging would be useful, so that people can 
> answer a question like "why such and such flag is not being set".
> 
> Should I change the "SHOULD" to "should"?
> Should the draft explain this in more details?

as long as there is no facility for accessing such logs in Sieve, I
think the spec shouldn't be mentioning any.  what gets logged or not is
an administrative issue.

I'd drop the text after the comma, and also remove the "silently", since
it may be taken to mean that no logging is allowed.  what happens to
special system flags other than \Recent?  shouldn't the behaviour be the
same?  suggested replacement text (only the last sentence is different):

        Note that it is not possible to use this extension to set or
        clear the \Recent flag or any other special system flag which is
        not settable in [IMAP]. Any such flags MUST be ignored if
        included in a flag list.

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHeLS4049122; Thu, 22 Sep 2005 10:40:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MHeLDM049121; Thu, 22 Sep 2005 10:40:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHeKYi049115 for <[e-mail]>; Thu, 22 Sep 2005 10:40:20 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 22 Sep 2005 10:40:18 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1127410817; h=Date: 	 From:Subject:MIME-version; b=OimhkRm5JSJcHO0RT6SZlxZw8JPtS4yFEScfh0 hdMlc99ZS67uYgL4wPpOCBVECfMZhx7OtZzQ/JovukJwFm9Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 22 Sep 2005 10:40:15 -0700 (PDT)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 22 Sep 2005 10:35:11 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-03.txt
In-reply-to: "Your message dated Thu, 22 Sep 2005 16:42:47 +0200" <[e-mail]>
MIME-version: 1.0
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hello,

> I took the chance to audit the Exim implementation for making sure I
> read the draft closely and while doing so, I found some minor issues
> with my code, but none with the draft.

> Section 4.6, "Restricting Replies to Automated Processes and Mailing Lists"
> gives a list of List-* header fields.  Is it certain that no other fields
> are in use?

No, but neither is it certain that other list-* fields, when used, actually
mean the message is from a list and should be exempt from vacation responses.

That's why I opted for an explicit list of fields in the document.

> Exim uses the pattern List-*, which would be easy to change.
> I asked this on the Exim list as well.

> Section 5.8, "In-Reply-To and References" says:

>    Replies MUST have the In-Reply-To field set to the Message-ID of the
>    original message, and the References field SHOULD be updated with the
>    Message-ID of the original message.

>    If the original message lacks a Message-ID, an In-Reply-To need not
>    be generated, and References need not be changed.

> Please add a reference to RFC 2822, section 3.6.4, "Identification
> fields".  It explains how to build the new references header in detail.
> The above section summarises it well, but it should tell that there is
> more to obey.

OK, I'll add a reference to it.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHaqFm048818; Thu, 22 Sep 2005 10:36:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MHaqDS048817; Thu, 22 Sep 2005 10:36:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHapij048798 for <[e-mail]>; Thu, 22 Sep 2005 10:36:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.165] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 22 Sep 2005 18:36:42 +0100
Message-ID: <[e-mail]>
Date: Thu, 22 Sep 2005 18:36:41 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett wrote:

>As I mentioned, if I had [yet]
>implemented the variables draft, I probably would question the
>whitespace skipping on the first argument in the "string" test.
>  
>
Yes, I will get to this once people respond to my poll ;-).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHQZQs047062; Thu, 22 Sep 2005 10:26:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MHQZGU047061; Thu, 22 Sep 2005 10:26:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8MHQYhX047055 for <[e-mail]>; Thu, 22 Sep 2005 10:26:34 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 89764 invoked by uid 101); 22 Sep 2005 13:26:33 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 22 Sep 2005 13:26:33 -0400
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Sep 21, 2005 at 04:41:58PM +0100, Alexey Melnikov wrote:
> Hi folks,
> One of the questions raised during the WGLC of 
> draft-ietf-sieve-3431bis-01.txt was concerning the following text in the 
> draft:
> 
> >3.1.  Match Type Value
> [...]
> >   Leading and trailing white space MUST be removed from the value of
> >   the message for the comparison.  White space is defined as
> >
> >       SP / HTAB / CRLF
> 
> I would like to poll people who've implemented the relational draft/RFC 
> if they've been following this rule.

Yes but probably not because of that draft, but because that's what the
associated tests do, relational or not.  As I mentioned, if I had [yet]
implemented the variables draft, I probably would question the
whitespace skipping on the first argument in the "string" test.

Yours,
mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHEfjF045480; Thu, 22 Sep 2005 10:14:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MHEfsU045479; Thu, 22 Sep 2005 10:14:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MHEeJX045472 for <[e-mail]>; Thu, 22 Sep 2005 10:14:40 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 22 Sep 2005 10:14:37 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1127409276; h=Date: 	 From:Subject:MIME-version:Content-type; b=QcAYPyBohdF1CUmLi2ymhakSa FOwJIRlLXJSZ/osIDpxIE0xkBnUT97vzAkqpA1DKmgg8Q1vMP6wjr76c22qYg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 22 Sep 2005 10:14:29 -0700 (PDT)
Cc: MTA filtering mailing list <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 22 Sep 2005 10:11:12 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft
In-reply-to: "Your message dated Wed, 21 Sep 2005 16:41:58 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=KOI8-R; format=flowed
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi folks,
> One of the questions raised during the WGLC of
> draft-ietf-sieve-3431bis-01.txt was concerning the following text in the
> draft:

>  >3.1.  Match Type Value
> [...]
>  >   Leading and trailing white space MUST be removed from the value of
>  >   the message for the comparison.  White space is defined as
>  >
>  >       SP / HTAB / CRLF

> I would like to poll people who've implemented the relational draft/RFC
> if they've been following this rule.

We handled the leading white space this way but not the trailing in this way.
I've already adjusted things so we follow the rule completely, but this 
isn't in our released product (yet).

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEgpx7031290; Thu, 22 Sep 2005 07:42:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MEgp8q031289; Thu, 22 Sep 2005 07:42:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEgoSj031283 for <[e-mail]>; Thu, 22 Sep 2005 07:42:50 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1EISHh-0006KI-6k for [e-mail]; Thu, 22 Sep 2005 16:42:49 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx4.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EISHh-0006MT-5L for [e-mail]; Thu, 22 Sep 2005 16:42:49 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC2 #9) id 1EISHf-0003DR-PI for [e-mail]; Thu, 22 Sep 2005 16:42:47 +0200
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-03.txt
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 22 Sep 2005 16:42:47 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I took the chance to audit the Exim implementation for making sure I
read the draft closely and while doing so, I found some minor issues
with my code, but none with the draft.

Section 4.6, "Restricting Replies to Automated Processes and Mailing Lists"
gives a list of List-* header fields.  Is it certain that no other fields
are in use? Exim uses the pattern List-*, which would be easy to change.
I asked this on the Exim list as well.

Section 5.8, "In-Reply-To and References" says:

   Replies MUST have the In-Reply-To field set to the Message-ID of the
   original message, and the References field SHOULD be updated with the
   Message-ID of the original message.

   If the original message lacks a Message-ID, an In-Reply-To need not
   be generated, and References need not be changed.

Please add a reference to RFC 2822, section 3.6.4, "Identification
fields".  It explains how to build the new references header in detail.
The above section summarises it well, but it should tell that there is
more to obey.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDh0VI025946; Thu, 22 Sep 2005 06:43:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MDh0vZ025945; Thu, 22 Sep 2005 06:43:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDgvch025937 for <[e-mail]>; Thu, 22 Sep 2005 06:42:59 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.207]) by mail.rockliffe.com (Rockliffe SMTPRA 6.3.25) with ESMTP id <[e-mail]>; Thu, 22 Sep 2005 06:42:50 -0700
Message-ID: <00f901c5bf7b$89c04910$3ffac350@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Date: Thu, 22 Sep 2005 14:42:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="KOI8-R"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8MDgxch025940
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yeah I think we do.
 
----- Original Message ----- 
From: "Alexey Melnikov" <[e-mail]>
To: "MTA filtering mailing list" <[e-mail]>
Sent: Wednesday, September 21, 2005 4:41 PM
Subject: Stripping leading/trailing spaces in relational draft


> 
> Hi folks,
> One of the questions raised during the WGLC of 
> draft-ietf-sieve-3431bis-01.txt was concerning the following text in the 
> draft:
> 
>  >3.1.  Match Type Value
> [...]
>  >   Leading and trailing white space MUST be removed from the value of
>  >   the message for the comparison.  White space is defined as
>  >
>  >       SP / HTAB / CRLF
> 
> I would like to poll people who've implemented the relational draft/RFC 
> if they've been following this rule.
> 
> Thanks,
> Alexey
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LNj1gA050286; Wed, 21 Sep 2005 16:45:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LNj1QD050285; Wed, 21 Sep 2005 16:45:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LNj0rP050279 for <[e-mail]>; Wed, 21 Sep 2005 16:45:00 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (pool-141-158-125-55.pitt.east.verizon.net [141.158.125.55]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j8LNh3uG031682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 21 Sep 2005 19:43:05 -0400
Date: Wed, 21 Sep 2005 19:44:56 -0400
From: Cyrus Daboo <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Subject: Working Group Last Call: draft-ietf-sieve-vacation-03.txt
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-03.txt>

A two week working group last call of this document starts today on 
September 21st 2005 and ends on October 5th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, please 
send both co-chairs (or the list) an email to indicate you have looked at 
it. This will allow the chairs to gauge the scope of reviews of this 
document to aid in our determination on whether to send it to the IESG. 
Thanks.

--
Cyrus Daboo
SIEVE WG Co-chair



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJo6mr024607; Wed, 21 Sep 2005 12:50:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LJo6wN024606; Wed, 21 Sep 2005 12:50:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJo5xP024598 for <[e-mail]>; Wed, 21 Sep 2005 12:50:05 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EIAbS-00064p-07; Wed, 21 Sep 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-vacation-03.txt 
Message-Id: <[e-mail]>
Date: Wed, 21 Sep 2005 15:50:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-03.txt
	Pages		: 15
	Date		: 2005-9-21
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-vacation-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-vacation-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-vacation-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-vacation-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LHfOEw012624; Wed, 21 Sep 2005 10:41:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LHfOn6012623; Wed, 21 Sep 2005 10:41:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LHfLsG012597 for <[e-mail]>; Wed, 21 Sep 2005 10:41:23 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.137] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 21 Sep 2005 18:40:44 +0100
Message-ID: <[e-mail]>
Date: Wed, 21 Sep 2005 18:40:43 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt  (relational test)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>>>Section 4.1:
>>>
>>>  The VALUE match type may be used with any comparator which returns
>>>  sort information.
>>>
>>>And which comparator of the base language does that? All, I guess,
>>>but I miss reading that.
>>>      
>>>
>>"relational" draft is not the place for listing such comparators. There 
>>is a separate document (currently draft-newman-i18n-comparator-05.txt) 
>>that defines the comparator registry. 
>>
>
>I guess you are right that duplicating information is not good, but the
>Sieve base language contains so few comparators, that it would be nice
>to state that those return sort information.
>
Maybe you are asking for a reference to the comparator registry after 
the quoted sentence?

When I edit a document I usually try to add lots of examples to address 
issues like yours.

>
>After all, "i;ascii-numeric" is described to allow at least 32 bit
>integers and not being capable to compare signed numbers.  The latter
>at least is duplicated information, yet it is very helpful.
>
Yes, the latter is important because it can be one of the unexpected 
things when using this comparator.

On a somewhat related note: do people think we need a comparator that 
can handle negative numbers?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LFg1vE099343; Wed, 21 Sep 2005 08:42:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LFg1S0099342; Wed, 21 Sep 2005 08:42:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LFg0VU099336 for <[e-mail]>; Wed, 21 Sep 2005 08:42:01 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.137] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 21 Sep 2005 16:41:58 +0100
Message-ID: <[e-mail]>
Date: Wed, 21 Sep 2005 16:41:58 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Stripping leading/trailing spaces in relational draft
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
One of the questions raised during the WGLC of 
draft-ietf-sieve-3431bis-01.txt was concerning the following text in the 
draft:

 >3.1.  Match Type Value
[...]
 >   Leading and trailing white space MUST be removed from the value of
 >   the message for the comparison.  White space is defined as
 >
 >       SP / HTAB / CRLF

I would like to poll people who've implemented the relational draft/RFC 
if they've been following this rule.

Thanks,
Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LF9fVe095296; Wed, 21 Sep 2005 08:09:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LF9fJN095295; Wed, 21 Sep 2005 08:09:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LF9eNM095288 for <[e-mail]>; Wed, 21 Sep 2005 08:09:41 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 21 Sep 2005 08:09:37 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1127315377; h=Date: 	 From:Subject:MIME-version:Content-type; b=0EN3Tc7jPrIhW2nGNJE4oGvFd w845lI4MyTZn+lkYVBLdCH/8/HWsladJ2SzVoYvo4FMwvFIB0MD6Gpk/Gp03Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 21 Sep 2005 08:09:32 -0700 (PDT)
Cc: [e-mail]
To: Mark E Mallett <[e-mail]>
Message-id: <[e-mail]>
Date: Wed, 21 Sep 2005 08:09:06 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Security review of SIEVE vacation
In-reply-to: "Your message dated Thu, 15 Sep 2005 19:30:35 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Wed, Sep 14, 2005 at 10:58:44AM +0200, Michael Haardt wrote:
> > On Tue, Sep 13, 2005 at 06:25:06PM -0700, Ned Freed wrote:
> > > This sort of thing really needs to be up to the implementation, and the
> > > current
> > > specification specifically allows this (section 3.5 list item 1) You really
> > > don't want to have to require that every user specify complex matching
> > > criteria
> > > in every vacation action they write.
> >
> > I agree.  If your address is really jhutz+*@*.cmu.edu, that pattern
> > should be used by vacation, too, without you having to specify it.
> > In fact it is probably jhutz+*@cmu.edu as well and a number different
> > patterns, if all you have are Sieve wildcard patterns.  Users will mostly
> > fail to get that right.  I don't want to think about sites with caseful
> > local parts.

> Along these lines (pretty closely along these lines in fact) I had
> suggested that the envelope recipient address that causes the final
> delivery, if known, should be one of the "known addresses" for the user.
> After all, if delivery is happening, that address is, by implementation,
> one that is valid for that user.  Ned had said:

>     I have no problem calling out that the current envelope recipient
>     address as an additional source of information for this check. I'll
>     add text to this effect to the revision.

> (in and around
>   http://www.imc.org/ietf-mta-filters/mail-archive/msg05948.html
> )

> and I think that that still addresses some of the concern.  Is that
> additional text still pending or was it shot down (I didn't notice if it
> was)?

Yes, this has been added and will be in the next update.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LF7Cdt095030; Wed, 21 Sep 2005 08:07:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LF7CDL095029; Wed, 21 Sep 2005 08:07:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LF7Csq095023 for <[e-mail]>; Wed, 21 Sep 2005 08:07:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.137] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 21 Sep 2005 16:07:10 +0100
Message-ID: <[e-mail]>
Date: Wed, 21 Sep 2005 16:07:09 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Initial revisions of Sieve Loops and Sieve Notifications?
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
I would like to remind people that we have the following 2 Sieve WG 
milestones for September:
 Sep 05    Submit revised loop draft  
 Sep 05    Submit revised notification action draft  

Can the guilty parties tell me and Cyrus if new drafts will appear this 
month.
Thanks,
Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LF5dOO094842; Wed, 21 Sep 2005 08:05:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LF5dEi094841; Wed, 21 Sep 2005 08:05:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LF5ciR094833 for <[e-mail]>; Wed, 21 Sep 2005 08:05:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.137] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 21 Sep 2005 16:05:16 +0100
Message-ID: <[e-mail]>
Date: Wed, 21 Sep 2005 16:05:16 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: [e-mail]
Subject: Re: removeflag \recent
References: <1126767529.24991.37.camel@localhost> <[e-mail]> <x6j/[e-mail]> 	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Philip Guenther wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>Arnt Gulbrandsen wrote:
>>    
>>
>...
>  
>
>>>I suggest that removeflag should NOT be able to modify \recent, since 
>>>similar IMAP commands cannot set it either. hasflag could test it 
>>>(since similar IMAP commands can) but considering that the result is 
>>>true always, I don't see much value in allowing \recent for hasflag.
>>>      
>>>
>>I think \recent should be explicitly excluded.
>>I've added to section 2.1:
>>
>>  Note that it is not possible to use this extension to set or clear the
>>  \Recent flag or any other special system flag which is not settable
>>  in [IMAP]. If the \Recent flag is included in a flag list, it MUST be
>>  silently ignored, but a warning message SHOULD be logged by the Sieve
>>  interpreter.
>>    
>>
>
>That makes the handling of \recent match that of flag names that don't
>match the IMAP syntax for flag names, which seems right to me.
>
>However, the suggestion that the implementation should log these events
>is kinda weird.  In my experience, admins have *no* interest in being
>bothered by this stuff.  Indeed, providing users with an automated way
>to bother admins would be considered a DoS attack by some people.  The
>problem is that it's notifying the wrong party: the author of the script
>should be notified, not the admin.  IMHO, invalid flag names and flags
>that can't be set (like \recent) should either be silently ignored or be
>considered an actual error.
>  
>
As Rob pointed out, the draft doesn't actually say what kind of logging 
should be done.
Some kind of user specific logging would be useful, so that people can 
answer a question like "why such and such flag is not being set".

Should I change the "SHOULD" to "should"?
Should the draft explain this in more details?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LF2MDJ094042; Wed, 21 Sep 2005 08:02:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LF2MUW094041; Wed, 21 Sep 2005 08:02:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LF2Lmw094035 for <[e-mail]>; Wed, 21 Sep 2005 08:02:21 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.137] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 21 Sep 2005 16:02:18 +0100
Message-ID: <[e-mail]>
Date: Wed, 21 Sep 2005 16:02:17 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Dave Cridland <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland wrote:

> On Wed Sep 14 01:01:36 2005, Cyrus Daboo wrote:
>
>> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-01.txt>
>
> 1) I did find the use of the phrase "internal variable" somewhat 
> confusing - this may simply be my own stupidity, but I feel that the 
> first usage of "the internal variable" would be more readable if 
> changed to "an internal flag list". Similarly, subsequent uses could 
> be changed to "the internal flag list". I consider this a purely 
> editorial change.

But it is a variable. If an implementation supports both "variables" and 
"imap4flags", the internal variable can still be accessed.

Do other people find this confusing?

> 2) Section 5, para 2 states: "If the :flags tagged argument is not 
> specified, "keep" or "fileinto" will not set any flag [...]". This 
> appears to be in contradiction to Section 3, which states that where 
> :flags is not supplied, the internal flag list will be used. I 
> consider this a purely editorial change.

Good catch, fixed.

> 3) Section 4: hasflag appears to require a list of variable names. 
> This would mean there is no method for testing the presence of a flag 
> in the internal flag list. I consider this a minor technical change.

Good point.
I've made the list of variables in hasflag optional and added:
   If the list of variables is omitted, value of the internal variable is
   used instead.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KMg0Un005284; Tue, 20 Sep 2005 15:42:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KMg0v1005281; Tue, 20 Sep 2005 15:42:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KMfxoD005273 for <[e-mail]>; Tue, 20 Sep 2005 15:41:59 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8KMfvmS027214 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Tue, 20 Sep 2005 15:41:57 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j8KMfvmS027214
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=UyVrXPLjZjkeUczGni8uBUKX3Ax4B8v8tEUbj4twmYepnYPI+e9DcVK9S9U4bnMy8 Fu1y3F9oYDeT8RT+0KBmsbJJi7s9TycT/LRY87/ykwKwEEScIWfAP/npHmc47/xl5f2 BYg6n5CIE/ZOrtIJLqfNp8CAe8950i18c7US7YE=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j8KMfvBM091136 for <[e-mail]>; Tue, 20 Sep 2005 15:41:57 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test) 
In-reply-to: <[e-mail]> 
References: <[e-mail]> 
Date: Tue, 20 Sep 2005 15:41:57 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[My apologies for the delay in this as well.  Barry, you may scowl at me
when we next meet.]

The leading broilerplate is out of date.  Possibly the trailing
broilerplate too.

I would suggest striking the second sentence of section 2 ("Any
comparator used..."), as this document is not the source of that
requirement and the list of exempted comparators is no longer accurate.

In the third paragraph of section 3.1, I think "of the message" should
be changed "from the message".

The last comma in section 3.1 ("...considered true[,] if any pair...")
should be removed 

In section 3.2, the phrasing of what the various tests do is a bit odd.
The first paragraph talks about counting entities, but then there's no
further mention of "entities".  If that first paragraph is left as is,
then I think the following paragraphs should be phrased more like:
   When used with the "address" test, the contained "addr-spec" elements
   [RFC2822] are the counted entity.  Note that addr-specs contained in
   group addresses are counted, but the group itself does not affect the
   count.

   When used with the "envelope" test, any envelope-part whose value is
   non-empty will contribute one (1) to the count.  In particular, the
   "to" envelope-part will always contribute exactly one.

(We need to leave the door open for other envelope-parts to be defined.)

   When used with the "header" test, the instances of the named fields
   are the counted entity.  The values of the instances has no effect on
   the count.

...though that text seems clunky too.


The reference to MATCH-TYPE in the ABNF will be rejected as there's no
previous definition of the MATCH-TYPE non-terminal, not even in the
base-spec, so it can't be added to with "=/".  I'm not sure what the
best fix for this is.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KGN4P3069156; Tue, 20 Sep 2005 09:23:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KGN4vQ069155; Tue, 20 Sep 2005 09:23:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KGN3vq069148 for <[e-mail]>; Tue, 20 Sep 2005 09:23:03 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j8KGLKuG003504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 20 Sep 2005 12:21:20 -0400
Date: Tue, 20 Sep 2005 12:23:01 -0400
From: Cyrus Daboo <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt        (relational test)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
X-Spam-Status: No, hits=1.0 tests=SUBJ_HAS_SPACES
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8KGN4vq069150
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My 3431bis comments:

--
§2 ¶1

Change:

   MUST be declared a require clause as defined in [SIEVE].

To:

   MUST be declared in a require clause as defined in [SIEVE].

                    ^^

--
§2 and elsewhere: change [ACAP] reference to i18n document.

--

Various places: 'syntax' -> 'usage'

--
§3 perhaps there ought to be an informative reference to 'C', or at least 
define it somewhere as 'the C programming language'.

--
§3.2

The phrase 'number of recipients' is not strictly right as From addresses 
can be tested and that is not a 'recipient'.

Exactly what are we talking about here? The number of 'addr-spec' elements 
as defined by 2822?

Also, I am not sure about the comment on groups. A group can have a list of 
email addresses included - do those get counted or not? It would be useful 
to have an example illustrating this if its not clear. Perhaps text should 
be:

	Group names are ignored, but the list of addresses in a group,
	if provided, are counted.

--
§3.2 ¶6

Change:

	comparing the total number of "to" and "cc" addresses;

To:

	compares the total number of "to" and "cc" addresses;
	
	      ^^

--
Examples: all of the examples use [...] around single string-list items, 
which is not strictly necessary. I always prefer to see the most 'compact' 
syntax representation where ever possible. This is just a personal 
preference.

--
§5 Examples:

Change:

	elseif

To:

	elsif

--

§5: the 'if allof' statement is missing a closing right-paren.

--

§5: 'fileinto' needs to be in the 'require' statement.


--
§8: update SIEVE reference to 3028bis.


-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFvPTe067217; Tue, 20 Sep 2005 08:57:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KFvPZs067215; Tue, 20 Sep 2005 08:57:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8KFvNFo067209 for <[e-mail]>; Tue, 20 Sep 2005 08:57:24 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 71430 invoked by uid 101); 20 Sep 2005 11:57:23 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 20 Sep 2005 11:57:23 -0400
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(Sorry to weigh in so late.)

On Thu, Sep 08, 2005 at 02:37:11PM +0200, Michael Haardt wrote:
> On Tue, Sep 06, 2005 at 11:28:20AM +0100, Alexey Melnikov wrote:
> > I would like to draw your attention to the following draft:
> > 
> > <http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-01.txt>
> 
> Am I right in thinking that using "i;octet", the left side " B " is
> equal to "B" (white space is stripped from the left side), but "B"
> is not equal to " B " (white space is not stripped from the right side)?

That's reasonable for values that are derived from message elements, I
would want a header field value or an address being tested to be
stripped of its leading spaces.  But that section also defines the left
side of a comparison as always being "from the message" which is hard to
apply to the "string" verb from the variables extension.

Speaking of which, 3.1 says:

 >  Leading and trailing white space MUST be removed from the value of
 >  the message for the comparison.  White space is defined as 
 >
 >      SP / HTAB / CRLF
 >
 >  A value from the message is considered the left side of the relation. 

The first sentence says "the value of the message" where it probably
means to say "the value from the message" or "a value from the message" .

Some other random comments, some significant, some not..

Some of the examples use domain names like "example.com.invalid" --
why not just "example.com" ?  Not that I expect to ever see a ".invalid"
TLD but example.tld is supposed to be for examples.

Also, the examples should use "elsif" rather than "elseif".

Some of the examples refer to a test as "being" true or false, and
others refer to the test as "returning" true or false.  I think
"returning" is a bad word, and would prefer e.g. "evaluates to" .

Should the "extended example" (section 5) require "fileinto" ?

The last "allof" in the extended example is missing a closing paren.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JFoxPa023536; Mon, 19 Sep 2005 08:50:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JFoxXx023535; Mon, 19 Sep 2005 08:50:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JFowr7023529 for <[e-mail]>; Mon, 19 Sep 2005 08:50:58 -0700 (PDT) (envelope-from [e-mail])
Received: by 216-239-45-4.google.com with SMTP id 14so1609zzb for <[e-mail]>; Mon, 19 Sep 2005 08:50:53 -0700 (PDT)
Received: by 172.25.12.99 with SMTP id 19mr8457zzb; Mon, 19 Sep 2005 08:50:53 -0700 (PDT)
Received: by 172.25.12.97 with HTTP; Mon, 19 Sep 2005 08:50:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 19 Sep 2005 08:50:53 -0700
From: Rob Siemborski <[e-mail]>
To: Philip Guenther <[e-mail]>
Subject: Re: removeflag \recent
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <1126767529.24991.37.camel@localhost> <[e-mail]> <x6j/[e-mail]> <[e-mail]> <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8JFowr7023530
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 9/18/05, Philip Guenther <[e-mail]> wrote:
> However, the suggestion that the implementation should log these events
> is kinda weird.  In my experience, admins have *no* interest in being
> bothered by this stuff.  Indeed, providing users with an automated way
> to bother admins would be considered a DoS attack by some people.  The
> problem is that it's notifying the wrong party: the author of the script
> should be notified, not the admin.  IMHO, invalid flag names and flags
> that can't be set (like \recent) should either be silently ignored or be
> considered an actual error.

Who says the log has to be something read by an admin instead of a user?

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [e-mail]
Software Engineer     |                       |            650-623-6925



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J3T04Y074323; Sun, 18 Sep 2005 20:29:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8J3T05V074322; Sun, 18 Sep 2005 20:29:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J3Sx83074315 for <[e-mail]>; Sun, 18 Sep 2005 20:28:59 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8J3SuoE024456 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 18 Sep 2005 20:28:57 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j8J3SuoE024456
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=PymTksXl533LYC63kOwXrq/uX+y5qFtr0DsmPMh2KykUe9tWMuSZ8GMJwdQuYH3MH 6szWOobwHmd00T+k61OvAER6kHa79lLXnsYtsYhQ/goKwM4IrS8HNlBjkfcmIK6XUgZ Y/GO/q8eQWkKqvXR64FDUg5oluw2IePmMbl6eBE=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j8J3SuVj093795; Sun, 18 Sep 2005 20:28:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: removeflag \recent 
In-reply-to: <[e-mail]> 
References: <1126767529.24991.37.camel@localhost> <[e-mail]> <x6j/[e-mail]>  <[e-mail]> 
Date: Sun, 18 Sep 2005 20:28:56 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:
>Arnt Gulbrandsen wrote:
...
>> I suggest that removeflag should NOT be able to modify \recent, since 
>> similar IMAP commands cannot set it either. hasflag could test it 
>> (since similar IMAP commands can) but considering that the result is 
>> true always, I don't see much value in allowing \recent for hasflag.
>
>I think \recent should be explicitly excluded.
>I've added to section 2.1:
>
>   Note that it is not possible to use this extension to set or clear the
>   \Recent flag or any other special system flag which is not settable
>   in [IMAP]. If the \Recent flag is included in a flag list, it MUST be
>   silently ignored, but a warning message SHOULD be logged by the Sieve
>   interpreter.

That makes the handling of \recent match that of flag names that don't
match the IMAP syntax for flag names, which seems right to me.

However, the suggestion that the implementation should log these events
is kinda weird.  In my experience, admins have *no* interest in being
bothered by this stuff.  Indeed, providing users with an automated way
to bother admins would be considered a DoS attack by some people.  The
problem is that it's notifying the wrong party: the author of the script
should be notified, not the admin.  IMHO, invalid flag names and flags
that can't be set (like \recent) should either be silently ignored or be
considered an actual error.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IFPOeY016117; Sun, 18 Sep 2005 08:25:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IFPOmi016116; Sun, 18 Sep 2005 08:25:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IFPMck016110 for <[e-mail]>; Sun, 18 Sep 2005 08:25:23 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 18 Sep 2005 16:24:54 +0100
Message-ID: <[e-mail]>
Date: Sat, 17 Sep 2005 01:06:44 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Jeffrey Hutzelman <[e-mail]>
CC: Sam Hartman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Security review of SIEVE vacation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

>>> That said, the WG may choose not to solve that use case.
>>> I am afraid that's the only sensible way, but the vacation extension
>>> should probably document this in section 6, security considerations.
>>> Like:
>>
>>>   If mail is forwarded from a site that uses subaddressing, it may
>>>   be impossible to list all recipient addresses with ":addresses".
>>
>> Seems reasonable. I'll add it unless someone objects.
>
> This seems fine.  Is "subaddressing" a well-defined term?

Yes, see draft-ietf-sieve-rfc3598bis-01.txt




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8GD3Cwg027800; Fri, 16 Sep 2005 06:03:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8GD3Cj6027797; Fri, 16 Sep 2005 06:03:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8GD3CVa027783 for <[e-mail]>; Fri, 16 Sep 2005 06:03:12 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (unverified [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.3.24) with ESMTP id <[e-mail]>; Fri, 16 Sep 2005 06:03:06 -0700
Message-ID: <000f01c5babe$fafe75a0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: scoping and variables yet again
Date: Fri, 16 Sep 2005 14:03:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> before we discuss the wording, we should make sure we have consensus on
> what the behaviour should be.
> 
>        a) an included script should not be allowed to change the
>        variables in the parent script unless the parent script
>        explicitly allows it.
> 
>        b) an included script should not be allowed to view the
>        variables in the parent script unless the parent script
>        explicitly allows it.
> 
>        c) the behaviour of a script should not change if it is included
>        by a parent script rather than run standalone.
> 
> are everyone with me on this?

+ d) a parent script should not be allowed to view the variables
    in the included script unless the included script explicitly allows it.

> my suggestion is (text A), a complete reversal of behaviour:
> 
>    Variables are only visible to the currently running script.

Ok by me :o)

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8GCUfud024777; Fri, 16 Sep 2005 05:30:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8GCUf9N024776; Fri, 16 Sep 2005 05:30:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8GCUeu0024767 for <[e-mail]>; Fri, 16 Sep 2005 05:30:41 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EGFMS-0000qU-Uv for [e-mail]; Fri, 16 Sep 2005 14:30:37 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EGFML-0006bq-Fd for [e-mail]; Fri, 16 Sep 2005 14:30:29 +0200
Subject: scoping and variables yet again
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Fri, 16 Sep 2005 14:30:21 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.775, required 12, autolearn=disabled, AWL 1.04, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm sorry, I don't think we have a clear consensus on this point yet.
so allow me to bring your attention to two suggestions for change in the
variables extension:

the text in -06:

        All variables have global scope: they are visible until
        processing stops.

this was deemed to be too risky security wise and allows too many feet
to be shot by accident when combined with "include".

before we discuss the wording, we should make sure we have consensus on
what the behaviour should be.

        a) an included script should not be allowed to change the
        variables in the parent script unless the parent script
        explicitly allows it.

        b) an included script should not be allowed to view the
        variables in the parent script unless the parent script
        explicitly allows it.

        c) the behaviour of a script should not change if it is included
        by a parent script rather than run standalone.

are everyone with me on this?


my suggestion is (text A), a complete reversal of behaviour:

    Variables are only visible to the currently running script.

the possibility of a different extension allowing a different scope is
implicit -- everything not forbidden can be overridden :-).  the usage
of the word "script" to mean a single fragment is consistent with other
Sieve documents.  e.g., an extension needs to be declared via "require"
in each script which uses it according to the base spec.

Aaron Stone's suggestion is similar in effect, I think (text B):

        All variables have global scope within a script. Future
        specifications may allow for a script to be composed of more
        than one file [part?], or for running more than one script per
        message [delivery?]. Such specifications may provide for
        different variable scoping rules.

it attempts to be more explicit, but I think it muddies more than it
clarifies, to be honest.

what is "global scope within a script"?  does this mean included scripts
are affected?  what is a "script"?  it may be unfortunate that we have
no established term for the collection of scripts into a bigger whole,
but as it is, I think "script" _is_ a single part (or file, or
fragment).

but before we discuss the wording, we should make sure we have consensus
on what the behaviour should be.


-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G9pc6j007733; Fri, 16 Sep 2005 02:51:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8G9pcMj007732; Fri, 16 Sep 2005 02:51:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G9pb9v007721 for <[e-mail]>; Fri, 16 Sep 2005 02:51:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Fri, 16 Sep 2005 10:51:34 +0100
Message-ID: <[e-mail]>
Date: Thu, 15 Sep 2005 22:11:07 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: removeflag \recent
References: <1126767529.24991.37.camel@localhost>  <[e-mail]> <x6j/[e-mail]>
In-Reply-To: <x6j/[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> Dave Cridland writes:
>
>> The only distinctions in IMAP itself that springs to mind is that 
>> system flags can affect, or be affected by, the IMAP server (\Seen, 
>> \Deleted, \Recent - but not \Answered, \Flagged or \Draft) and that 
>> system flags have shorthand search criteria (ANSWERED, UNSEEN, etc). 
>> Otherwise, they behave identically.
>
> Which reminds me - as I read the imapflags draft, it's not clear 
> whether \recent can be changed using removeflag (and once removed, set 
> again using setflag).
>
> I suggest that removeflag should NOT be able to modify \recent, since 
> similar IMAP commands cannot set it either. hasflag could test it 
> (since similar IMAP commands can) but considering that the result is 
> true always, I don't see much value in allowing \recent for hasflag.

I think \recent should be explicitly excluded.
I've added to section 2.1:

   Note that it is not possible to use this extension to set or clear the
   \Recent flag or any other special system flag which is not settable
   in [IMAP]. If the \Recent flag is included in a flag list, it MUST be
   silently ignored, but a warning message SHOULD be logged by the Sieve
   interpreter.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FNUaUL047143; Thu, 15 Sep 2005 16:30:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FNUa9l047142; Thu, 15 Sep 2005 16:30:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8FNUZgp047136 for <[e-mail]>; Thu, 15 Sep 2005 16:30:36 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 13218 invoked by uid 101); 15 Sep 2005 19:30:35 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 15 Sep 2005 19:30:35 -0400
To: [e-mail]
Subject: Re: Security review of SIEVE vacation
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Sep 14, 2005 at 10:58:44AM +0200, Michael Haardt wrote:
> On Tue, Sep 13, 2005 at 06:25:06PM -0700, Ned Freed wrote:
> > This sort of thing really needs to be up to the implementation, and the 
> > current
> > specification specifically allows this (section 3.5 list item 1) You really
> > don't want to have to require that every user specify complex matching 
> > criteria
> > in every vacation action they write.
> 
> I agree.  If your address is really jhutz+*@*.cmu.edu, that pattern
> should be used by vacation, too, without you having to specify it.
> In fact it is probably jhutz+*@cmu.edu as well and a number different
> patterns, if all you have are Sieve wildcard patterns.  Users will mostly
> fail to get that right.  I don't want to think about sites with caseful
> local parts.

Along these lines (pretty closely along these lines in fact) I had
suggested that the envelope recipient address that causes the final
delivery, if known, should be one of the "known addresses" for the user.
After all, if delivery is happening, that address is, by implementation,
one that is valid for that user.  Ned had said:

    I have no problem calling out that the current envelope recipient
    address as an additional source of information for this check. I'll
    add text to this effect to the revision.

(in and around
  http://www.imc.org/ietf-mta-filters/mail-archive/msg05948.html
)

and I think that that still addresses some of the concern.  Is that
additional text still pending or was it shot down (I didn't notice if it
was)?

-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FLT6M8038014; Thu, 15 Sep 2005 14:29:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FLT55W038013; Thu, 15 Sep 2005 14:29:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FLT5er037991 for <[e-mail]>; Thu, 15 Sep 2005 14:29:05 -0700 (PDT) (envelope-from [e-mail])
Received: from [66.228.163.20] (trustwho.corp.yahoo.com [66.228.163.20]) by mrout3.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j8FLS7Di054548; Thu, 15 Sep 2005 14:28:08 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 15 Sep 2005 14:28:07 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050215)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: removeflag \recent
References: <1126767529.24991.37.camel@localhost>  <[e-mail]> <x6j/[e-mail]>
In-Reply-To: <x6j/[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:
> 
> Which reminds me - as I read the imapflags draft, it's not clear whether 
> \recent can be changed using removeflag (and once removed, set again 
> using setflag).
> 
> I suggest that removeflag should NOT be able to modify \recent, since 
> similar IMAP commands cannot set it either. hasflag could test it (since 
> similar IMAP commands can) but considering that the result is true 
> always, I don't see much value in allowing \recent for hasflag.

I wholeheartedly agree; \Recent is typically not modifyable (given Cyrus 
mail stores that I remember, and presumably UW stores as well), and we 
don't want to even suggest that it should be modifyable.

(\Recent can be implemented with timestamps, but not if it's modifyable.)

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FKIaFJ031552; Thu, 15 Sep 2005 13:18:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FKIa2k031551; Thu, 15 Sep 2005 13:18:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8FKIYu8031522 for <[e-mail]>; Thu, 15 Sep 2005 13:18:34 -0700 (PDT) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa14619; 15 Sep 2005 16:18 EDT
Date: Thu, 15 Sep 2005 16:18:25 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Ned Freed <[e-mail]>, Michael Haardt <[e-mail]>
cc: Sam Hartman <[e-mail]>, Alexey Melnikov <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Security review of SIEVE vacation
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Originator-Info: login-token=Mulberry:01aj9W9dSny2m2is52nb2GZAGxjSDxc8/XtIRaoL8=; token_authority=[e-mail]
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thursday, September 15, 2005 10:44:48 AM -0700 Ned Freed 
<[e-mail]> wrote:

>
>> On Wed, Sep 14, 2005 at 10:00:04AM -0400, Sam Hartman wrote:
>> > Jeff's concern is that imap.outsourcemail.com may well know nothing
>> > about CMU's addressing plan.  If outsourcemail.com is affiliated with
>> > Jeff and not with CMU it is unreasonable for them to have out of band
>> > configuration.
>
>> Now I see where the comparator comes in: To describe remote subaddressing
>> schemes.
>
>> That is not going to work, because subaddressing schemes can not be
>> covered by Sieve without adding a powerful string expression language.
>> A comparator may suffice to describe the user-separator-detail scheme,
>> but without regular expressions it already requires a couple patterns.
>> More elaborate subaddressing schemes may leave regular languages.
>
> Bingo. Over the years I've seen numerous different subaddressing schemes.
> Only a couple of days ago I ran into one that was positional - no
> separator - and I believe the subaddress came first.
>
> Things might have been different had the IETF published some suggestions
> in this area, but the IETF elected not to do so some years back.

I think you can do a lot with multiple patterns using the pattern matching 
we have now.  And certainly a "powerful string expression language" is not 
out of the question -- we have a draft on the table for adding regular 
expression matching to SIEVE (I have some reservations about that, but 
nothing insurmountable).

Still, ading a match operator and comparator would be a significant change, 
and I can understand not wanting to do it.

>> > That said, the WG may choose not to solve that use case.
>> I am afraid that's the only sensible way, but the vacation extension
>> should probably document this in section 6, security considerations.
>> Like:
>
>>   If mail is forwarded from a site that uses subaddressing, it may
>>   be impossible to list all recipient addresses with ":addresses".
>
> Seems reasonable. I'll add it unless someone objects.

This seems fine.  Is "subaddressing" a well-defined term?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FHpj2X017716; Thu, 15 Sep 2005 10:51:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FHpjkn017715; Thu, 15 Sep 2005 10:51:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FHphSn017700 for <[e-mail]>; Thu, 15 Sep 2005 10:51:43 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 15 Sep 2005 10:51:37 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1126806696; h=Date: 	 From:Subject:MIME-version:Content-type; b=z9dnFN+v2Vim9EbSVJZPwVlb8 3e5uBLYybwAxjHI2lacIbO/Ddzlu6CRAUhnuB+arncVksK25JJSSpP9nnSMLw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 15 Sep 2005 10:51:32 -0700 (PDT)
Cc: Sam Hartman <[e-mail]>, Ned Freed <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, Alexey Melnikov <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 15 Sep 2005 10:44:48 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Security review of SIEVE vacation
In-reply-to: "Your message dated Thu, 15 Sep 2005 15:03:11 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Wed, Sep 14, 2005 at 10:00:04AM -0400, Sam Hartman wrote:
> > Jeff's concern is that imap.outsourcemail.com may well know nothing
> > about CMU's addressing plan.  If outsourcemail.com is affiliated with
> > Jeff and not with CMU it is unreasonable for them to have out of band
> > configuration.

> Now I see where the comparator comes in: To describe remote subaddressing
> schemes.

> That is not going to work, because subaddressing schemes can not be
> covered by Sieve without adding a powerful string expression language.
> A comparator may suffice to describe the user-separator-detail scheme,
> but without regular expressions it already requires a couple patterns.
> More elaborate subaddressing schemes may leave regular languages.

Bingo. Over the years I've seen numerous different subaddressing schemes. Only
a couple of days ago I ran into one that was positional - no separator - and I
believe the subaddress came first.

Things might have been different had the IETF published some suggestions
in this area, but the IETF elected not to do so some years back.

> > That said, the WG may choose not to solve that use case.
> I am afraid that's the only sensible way, but the vacation extension
> should probably document this in section 6, security considerations.
> Like:

>   If mail is forwarded from a site that uses subaddressing, it may
>   be impossible to list all recipient addresses with ":addresses".

Seems reasonable. I'll add it unless someone objects.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FF0cRo098742; Thu, 15 Sep 2005 08:00:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FF0cxZ098741; Thu, 15 Sep 2005 08:00:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FF0b2W098734 for <[e-mail]>; Thu, 15 Sep 2005 08:00:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.176] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 15 Sep 2005 16:00:29 +0100
Message-ID: <[e-mail]>
Date: Thu, 15 Sep 2005 16:00:27 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Dave Cridland <[e-mail]>
CC: Aaron Stone <[e-mail]>, [e-mail]
Subject: Re: An imapflags question
References: <1126767529.24991.37.camel@localhost> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland wrote:

> On Wed Sep 14 17:58:48 2005, Aaron Stone wrote:
>
>> Several places in the imapflags draft, there are flags such as this one,
>> starting with a $ rather than \\
>>
>>            addflag "MyFlags" ["\\Answered", "$MDNSent"];
>>
>> I presume that this is not a variable, but actually a flag that begins
>> with $. Where in the specs did those come from? Is this the "keywords"
>> type flag that RFC 3501 allows?
>>
>> If it is the "keywords" type flags, I think it would it be prudent to
>> make reference to that aspect of RFC 3501.
>
>
> It does state that "Setflag is used for setting [IMAP] flags or 
> keywords."
>
> This may not be clear enough, however, I usually read "flags" as 
> "system flags or keywords" in any case. The only distinctions in IMAP 
> itself that springs to mind is that system flags can affect, or be 
> affected by, the IMAP server (\Seen, \Deleted, \Recent - but not 
> \Answered, \Flagged or \Draft) and that system flags have shorthand 
> search criteria (ANSWERED, UNSEEN, etc). Otherwise, they behave 
> identically.

Correct.

> The $ prefix is not specified in any RFC, as far as I'm aware, and is 
> purely a convention for standard keywords.

There was a discussion about documenting this convention, but there is 
no document yet.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FD3TjQ087939; Thu, 15 Sep 2005 06:03:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FD3Twk087938; Thu, 15 Sep 2005 06:03:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FD3R4f087928 for <[e-mail]>; Thu, 15 Sep 2005 06:03:27 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53) id 1EFtOW-0004Rq-Kv; Thu, 15 Sep 2005 15:03:16 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EFtOW-0002y9-Hr; Thu, 15 Sep 2005 15:03:16 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC1 #7) id 1EFtOR-0000un-Vs; Thu, 15 Sep 2005 15:03:11 +0200
Date: Thu, 15 Sep 2005 15:03:11 +0200
From: Michael Haardt <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Ned Freed <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, Alexey Melnikov <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Security review of SIEVE vacation
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Sep 14, 2005 at 10:00:04AM -0400, Sam Hartman wrote:
> Jeff's concern is that imap.outsourcemail.com may well know nothing
> about CMU's addressing plan.  If outsourcemail.com is affiliated with
> Jeff and not with CMU it is unreasonable for them to have out of band
> configuration.

Now I see where the comparator comes in: To describe remote subaddressing
schemes.

That is not going to work, because subaddressing schemes can not be
covered by Sieve without adding a powerful string expression language.
A comparator may suffice to describe the user-separator-detail scheme,
but without regular expressions it already requires a couple patterns.
More elaborate subaddressing schemes may leave regular languages.

> That said, the WG may choose not to solve that use case.

I am afraid that's the only sensible way, but the vacation extension
should probably document this in section 6, security considerations.
Like:

  If mail is forwarded from a site that uses subaddressing, it may
  be impossible to list all recipient addresses with ":addresses".

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FCoIKX086790; Thu, 15 Sep 2005 05:50:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FCoIUV086789; Thu, 15 Sep 2005 05:50:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FCoHT0086783 for <[e-mail]>; Thu, 15 Sep 2005 05:50:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53) id 1EFtBw-0000JJ-Bq for [e-mail]; Thu, 15 Sep 2005 14:50:16 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EFtBw-0001Te-9l for [e-mail]; Thu, 15 Sep 2005 14:50:16 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC1 #7) id 1EFtBv-0000tk-VN for [e-mail]; Thu, 15 Sep 2005 14:50:15 +0200
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 15 Sep 2005 14:50:15 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >Section 4.1:
> >
> >   The VALUE match type may be used with any comparator which returns
> >   sort information.
> >
> >And which comparator of the base language does that? All, I guess,
> >but I miss reading that.
> >
> "relational" draft is not the place for listing such comparators. There 
> is a separate document (currently draft-newman-i18n-comparator-05.txt) 
> that defines the comparator registry.

I guess you are right that duplicating information is not good, but the
Sieve base language contains so few comparators, that it would be nice
to state that those return sort information.

After all, "i;ascii-numeric" is described to allow at least 32 bit
integers and not being capable to compare signed numbers.  The latter
at least is duplicated information, yet it is very helpful.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FASUhh054601; Thu, 15 Sep 2005 03:28:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FASUGN054600; Thu, 15 Sep 2005 03:28:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FASTad054566 for <[e-mail]>; Thu, 15 Sep 2005 03:28:29 -0700 (PDT) (envelope-from [e-mail])
Received: from libertango.oryx.com (unknown [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id CF69A4AD94; Thu, 15 Sep 2005 12:28:07 +0200 (CEST)
Message-Id: <x6j/[e-mail]>
Date: Thu, 15 Sep 2005 12:24:38 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: removeflag \recent
References: <1126767529.24991.37.camel@localhost> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland writes:
> The only distinctions in IMAP itself that springs to mind is that 
> system flags can affect, or be affected by, the IMAP server (\Seen, 
> \Deleted, \Recent - but not \Answered, \Flagged or \Draft) and that 
> system flags have shorthand search criteria (ANSWERED, UNSEEN, etc). 
> Otherwise, they behave identically.

Which reminds me - as I read the imapflags draft, it's not clear whether 
\recent can be changed using removeflag (and once removed, set again 
using setflag).

I suggest that removeflag should NOT be able to modify \recent, since 
similar IMAP commands cannot set it either. hasflag could test it 
(since similar IMAP commands can) but considering that the result is 
true always, I don't see much value in allowing \recent for hasflag.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8F9M5tM022156; Thu, 15 Sep 2005 02:22:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8F9M5rj022155; Thu, 15 Sep 2005 02:22:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8F9M42X022141 for <[e-mail]>; Thu, 15 Sep 2005 02:22:05 -0700 (PDT) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 9239B154009; Thu, 15 Sep 2005 09:21:58 +0000 (UTC)
Date: Thu, 15 Sep 2005 10:21:58 +0100
Subject: Re: An imapflags question
References: <1126767529.24991.37.camel@localhost>
In-Reply-To: <1126767529.24991.37.camel@localhost>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed Sep 14 17:58:48 2005, Aaron Stone wrote:
> Several places in the imapflags draft, there are flags such as this 
> one,
> starting with a $ rather than \\
> 
>            addflag "MyFlags" ["\\Answered", "$MDNSent"];
> 
> I presume that this is not a variable, but actually a flag that 
> begins
> with $. Where in the specs did those come from? Is this the 
> "keywords"
> type flag that RFC 3501 allows?
> 
> If it is the "keywords" type flags, I think it would it be prudent 
> to
> make reference to that aspect of RFC 3501.

It does state that "Setflag is used for setting [IMAP] flags or 
keywords."

This may not be clear enough, however, I usually read "flags" as 
"system flags or keywords" in any case. The only distinctions in IMAP 
itself that springs to mind is that system flags can affect, or be 
affected by, the IMAP server (\Seen, \Deleted, \Recent - but not 
\Answered, \Flagged or \Draft) and that system flags have shorthand 
search criteria (ANSWERED, UNSEEN, etc). Otherwise, they behave 
identically.

The $ prefix is not specified in any RFC, as far as I'm aware, and is 
purely a convention for standard keywords.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8F6qn3u004973; Wed, 14 Sep 2005 23:52:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8F6qn22004972; Wed, 14 Sep 2005 23:52:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8F6qnFk004966 for <[e-mail]>; Wed, 14 Sep 2005 23:52:49 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id 51754601FD7C; Wed, 14 Sep 2005 23:52:49 -0700 (PDT)
Received: from [192.168.0.5] (dsl3-63-249-106-79.cruzio.com [63.249.106.79]) by lucite.serendipity.cx (Postfix) with ESMTP id 55AAB601FD7B for <[e-mail]>; Wed, 14 Sep 2005 23:52:47 -0700 (PDT)
Subject: An imapflags question
From: Aaron Stone <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Wed, 14 Sep 2005 23:58:48 -0700
Message-Id: <1126767529.24991.37.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:43291a41317152140214566!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Several places in the imapflags draft, there are flags such as this one,
starting with a $ rather than \\

           addflag "MyFlags" ["\\Answered", "$MDNSent"];

I presume that this is not a variable, but actually a flag that begins
with $. Where in the specs did those come from? Is this the "keywords"
type flag that RFC 3501 allows?

If it is the "keywords" type flags, I think it would it be prudent to
make reference to that aspect of RFC 3501.

Thanks!
Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EGHYYm057382; Wed, 14 Sep 2005 09:17:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8EGHYCY057381; Wed, 14 Sep 2005 09:17:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EGHXU8057365 for <[e-mail]>; Wed, 14 Sep 2005 09:17:33 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.122] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 14 Sep 2005 17:17:29 +0100
Message-ID: <[e-mail]>
Date: Wed, 14 Sep 2005 17:17:28 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt  (relational test)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>On Tue, Sep 06, 2005 at 11:28:20AM +0100, Alexey Melnikov wrote:
>  
>
>>I would like to draw your attention to the following draft:
>>
>><http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-01.txt>
>>
>>A two week working group last call of this document starts today on 
>>September 6th 2005 and ends on Tuesday, September 20th 2005 at 6 pm EST.
>>
>>Please review this document and send issues to the list or direct to the 
>>author(s).
>>    
>>
>
>I have no serious issues, but some minor ones:
>
>I miss a list of changes.  Aren't there any?
>
Only explanation what things like "gt", "eq", etc. mean

>I miss a table of contents, too.
>  
>
I believe RFC editor can address this, once the document is approved.

>I miss a section "Interaction with Other Sieve Actions".  Obviously,
>"relational" is only incompatible with comparators that return no
>sort information.  There are no incompatibilities with any actions
>and implicit keep is not touched, but I would prefer not having to
>read that between the lines.
>
>Section 2:
>
>   The capability string associated with extension defined in this
>   document is "relational".
>
>I think this does not belong to "Conventions used in this document",
>but to its own section "Capability Identifier".
>
>Section 4.1:
>
>   The VALUE match type may be used with any comparator which returns
>   sort information.
>
>And which comparator of the base language does that? All, I guess,
>but I miss reading that.
>
"relational" draft is not the place for listing such comparators. There 
is a separate document (currently draft-newman-i18n-comparator-05.txt) 
that defines the comparator registry.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EFIaDj052249; Wed, 14 Sep 2005 08:18:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8EFIaFm052248; Wed, 14 Sep 2005 08:18:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EFIZIW052234 for <[e-mail]>; Wed, 14 Sep 2005 08:18:36 -0700 (PDT) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 2B861154009; Wed, 14 Sep 2005 15:18:27 +0000 (UTC)
Date: Wed, 14 Sep 2005 16:18:26 +0100
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>, Alexey Melnikov <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed Sep 14 01:01:36 2005, Cyrus Daboo wrote:
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-01.txt>

1) I did find the use of the phrase "internal variable" somewhat 
confusing - this may simply be my own stupidity, but I feel that the 
first usage of "the internal variable" would be more readable if 
changed to "an internal flag list". Similarly, subsequent uses could 
be changed to "the internal flag list". I consider this a purely 
editorial change.

2) Section 5, para 2 states: "If the :flags tagged argument is not 
specified, "keep" or "fileinto" will not set any flag [...]". This 
appears to be in contradiction to Section 3, which states that where 
:flags is not supplied, the internal flag list will be used. I 
consider this a purely editorial change.

3) Section 4: hasflag appears to require a list of variable names. 
This would mean there is no method for testing the presence of a flag 
in the internal flag list. I consider this a minor technical change.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EENtsa047094; Wed, 14 Sep 2005 07:23:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8EENtCB047092; Wed, 14 Sep 2005 07:23:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EENsZ2047079 for <[e-mail]>; Wed, 14 Sep 2005 07:23:55 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53) id 1EFYAz-0005lU-H2 for [e-mail]; Wed, 14 Sep 2005 16:23:53 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EFYAz-0005Ux-Eo for [e-mail]; Wed, 14 Sep 2005 16:23:53 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53-RC1 #7) id 1EFYAz-0008Pj-4O for [e-mail]; Wed, 14 Sep 2005 16:23:53 +0200
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-01.txt
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 14 Sep 2005 16:23:53 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-01.txt

This draft addresses all my issues but one I had at the very beginning:

Why must the subaddress be a literal string and why must there be a
separator character sequence? Can't we just say: The encoding of user
and detail is site-specific?

VERP encodes a full local part in the detail and it would be nice if
Sieve could be used to process the bounces by decoding the address and
allowing comparisons against the decoded detail part.

Using anonymous mail addresses may be an application where user and detail
part are encrypted to form the resulting address.  To me, letting the
subaddress extension decrypt the address on the receiving system sounds
very useful.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EE2ACG045195; Wed, 14 Sep 2005 07:02:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8EE2AI6045194; Wed, 14 Sep 2005 07:02:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EE298R045188 for <[e-mail]>; Wed, 14 Sep 2005 07:02:10 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.71.2.87] ([63.202.89.97]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j8EE1LuG023080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 14 Sep 2005 10:01:23 -0400
Date: Wed, 14 Sep 2005 07:01:36 -0700
From: Cyrus Daboo <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Subject: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-01.txt>

A two week working group last call of this document starts today on 
September 14th 2005 and ends on September 27th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, please 
send both co-chairs (or the list) an email to indicate you have looked at 
it. This will allow the chairs to gauge the scope of reviews of this 
document to aid in our determination on whether to send it to the IESG. 
Thanks.

--
Cyrus Daboo
SIEVE WG Co-chair





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EE0ERp045011; Wed, 14 Sep 2005 07:00:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8EE0EJX045010; Wed, 14 Sep 2005 07:00:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EE0BaY044999 for <[e-mail]>; Wed, 14 Sep 2005 07:00:11 -0700 (PDT) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E2495E0049; Wed, 14 Sep 2005 10:00:04 -0400 (EDT)
To: Michael Haardt <[e-mail]>
Cc: Ned Freed <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, Alexey Melnikov <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Security review of SIEVE vacation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Sam Hartman <[e-mail]>
Date: Wed, 14 Sep 2005 10:00:04 -0400
In-Reply-To: <[e-mail]> (Michael Haardt's message of "Wed, 14 Sep 2005 10:58:44 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Michael" == Michael Haardt <[e-mail]> writes:

    Michael> On Tue, Sep 13, 2005 at 06:25:06PM -0700, Ned Freed
    Michael> wrote:
    >> >Just as one example, any address with a mailbox name beginning
    >> 'jhutz+' or >'jhutz=' and a domain ending in 'cmu.edu' is is
    >> probably mine, and if I >used vacation, I'd certainly want it
    >> to treat mail sent to any such address >as belonging to me,
    >> regardless of the specific host the mail went to or >what, if
    >> anything, occurs after the plus.  I'd want that even if the
    >> mail >server weren't also at CMU, if I ever decided to forward
    >> my CMU mail >off-site.  One way to deal with this sort of
    >> problem would be to allow a >match type and comparator to be
    >> specified for the addresses.
    >> 
    >> This sort of thing really needs to be up to the implementation,
    >> and the current specification specifically allows this (section
    >> 3.5 list item 1) You really don't want to have to require that
    >> every user specify complex matching criteria in every vacation
    >> action they write.

    Michael> I agree.  If your address is really jhutz+*@*.cmu.edu,
    Michael> that pattern should be used by vacation, too, without you
    Michael> having to specify it.  In fact it is probably
    Michael> jhutz+*@cmu.edu as well and a number different patterns,


Jeff's concern is that imap.outsourcemail.com may well know nothing
about CMU's addressing plan.  If outsourcemail.com is affiliated with
Jeff and not with CMU it is unreasonable for them to have out of band
configuration.

That said, the WG may choose not to solve that use case.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E9hKNX020089; Wed, 14 Sep 2005 02:43:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8E9hKmh020088; Wed, 14 Sep 2005 02:43:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E9hJtJ020082 for <[e-mail]>; Wed, 14 Sep 2005 02:43:19 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.122] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 14 Sep 2005 10:43:11 +0100
Message-ID: <[e-mail]>
Date: Wed, 14 Sep 2005 10:43:10 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: Security review of SIEVE vacation
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>> Section 3.7 says "The vacation is incompatible with reject.".  I think
>> there are some words missing there.
>
> I'll change this to read "the vacaction action is incompatible with 
> the sieve
> reject action".

Which reminds me: reject is now defined in a separate document and there 
is no reference to it.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E8x191015664; Wed, 14 Sep 2005 01:59:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8E8x1Q6015663; Wed, 14 Sep 2005 01:59:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E8wwPG015651 for <[e-mail]>; Wed, 14 Sep 2005 01:58:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53) id 1EFT6Q-0008IT-7x; Wed, 14 Sep 2005 10:58:50 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.53 #4) id 1EFT6Q-0003XY-6V; Wed, 14 Sep 2005 10:58:50 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53 #4) id 1EFT6K-0007Tp-VU; Wed, 14 Sep 2005 10:58:44 +0200
Date: Wed, 14 Sep 2005 10:58:44 +0200
From: Michael Haardt <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Alexey Melnikov <[e-mail]>, Sam Hartman <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Security review of SIEVE vacation
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Sep 13, 2005 at 06:25:06PM -0700, Ned Freed wrote:
> >Just as one example, any address with a mailbox name beginning 'jhutz+' or
> >'jhutz=' and a domain ending in 'cmu.edu' is is probably mine, and if I
> >used vacation, I'd certainly want it to treat mail sent to any such address
> >as belonging to me, regardless of the specific host the mail went to or
> >what, if anything, occurs after the plus.  I'd want that even if the mail
> >server weren't also at CMU, if I ever decided to forward my CMU mail
> >off-site.  One way to deal with this sort of problem would be to allow a
> >match type and comparator to be specified for the addresses.
> 
> This sort of thing really needs to be up to the implementation, and the 
> current
> specification specifically allows this (section 3.5 list item 1) You really
> don't want to have to require that every user specify complex matching 
> criteria
> in every vacation action they write.

I agree.  If your address is really jhutz+*@*.cmu.edu, that pattern
should be used by vacation, too, without you having to specify it.
In fact it is probably jhutz+*@cmu.edu as well and a number different
patterns, if all you have are Sieve wildcard patterns.  Users will mostly
fail to get that right.  I don't want to think about sites with caseful
local parts.

But perhaps section 3.5 is not clear enough:

                                               Implementations are
   assumed to know the user's email address, but users may have
   additional addresses beyond the control of the local mail system.

Ned: Do you refer to that sentence? If so, how about:

                                               Implementations are
   assumed to know the user's email address, including aliases and
   subaddresses, but users may have additional addresses beyond the
   control of the local mail system.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E1n3nQ073884; Tue, 13 Sep 2005 18:49:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8E1n3iq073883; Tue, 13 Sep 2005 18:49:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8E1n3nw073876 for <[e-mail]>; Tue, 13 Sep 2005 18:49:03 -0700 (PDT) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa08226; 13 Sep 2005 21:48 EDT
Date: Tue, 13 Sep 2005 21:48:39 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Ned Freed <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, Sam Hartman <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Security review of SIEVE vacation
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Originator-Info: login-token=Mulberry:01BaviNm8TV6pR9lq3OCkSpZwdGWGM31tyIBCbOys=; token_authority=[e-mail]
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tuesday, September 13, 2005 06:25:06 PM -0700 Ned Freed 
<[e-mail]> wrote:

>> Just as one example, any address with a mailbox name beginning 'jhutz+'
>> or 'jhutz=' and a domain ending in 'cmu.edu' is is probably mine, and if
>> I used vacation, I'd certainly want it to treat mail sent to any such
>> address as belonging to me, regardless of the specific host the mail
>> went to or what, if anything, occurs after the plus.  I'd want that even
>> if the mail server weren't also at CMU, if I ever decided to forward my
>> CMU mail off-site.  One way to deal with this sort of problem would be
>> to allow a match type and comparator to be specified for the addresses.
>
> This sort of thing really needs to be up to the implementation, and the
> current specification specifically allows this (section 3.5 list item 1)
> You really don't want to have to require that every user specify complex
> matching criteria in every vacation action they write.

No, but I sort of want to allow them to do it, rather than depending on the 
policies of the mail server operator to match the address forms used 
wherever the user is sending their mail from.

I agree the spec allows implementations to know about extra addresses using 
more or less arbitrary policy.  If the working group feels this is 
sufficient, I'll live with it.

-- Jeff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E1bgrN073100; Tue, 13 Sep 2005 18:37:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8E1bg6n073099; Tue, 13 Sep 2005 18:37:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8E1bfQD073093 for <[e-mail]>; Tue, 13 Sep 2005 18:37:41 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 13 Sep 2005 18:37:39 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1126661859; h=Date: 	 From:Subject:MIME-version:Content-type; b=o5vDvHeR86FRWhpuCdmAeSnC/ tgfB0I+uDRMygww0GoqblZVlc0bPLD3PFM/Yw7mMvjieN5952gthtDsbLK+RA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 13 Sep 2005 18:37:36 -0700 (PDT)
Cc: Alexey Melnikov <[e-mail]>, Sam Hartman <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
To: Jeffrey Hutzelman <[e-mail]>
Message-id: <[e-mail]>
Date: Tue, 13 Sep 2005 18:25:06 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Security review of SIEVE vacation
In-reply-to: "Your message dated Tue, 13 Sep 2005 14:45:50 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Monday, September 12, 2005 07:31:42 PM +0100 Alexey Melnikov
> <[e-mail]> wrote:

> > Jeff, Ned Freed, the author of vacation asked to have the results of
> > security review of the vacation draft in writing. If you didn't find any
> > issue, can you please acknowledge that.
> >
> > If you are too busy to do that quickly, can you please let Sam know so
> > that he can find another reviewer.
> >
> > Cyrus and I would like to avoid any security related surprises during
> > IETF wide LC.

> Section 3.3 says "... Implementations MAY also impose security restructions
> on what addresses can be specified in a ":from" parameter...".  I'd drop
> the word "security" here; such restrictions are a matter of policy which
> may or may not actually have anything to do with security.

Seens reasonable to me. I'll drop it in the next revision.

> I'm not real wild about the mechansims defined in sections 3.5 and 3.6 to
> try to avoid sending vacation messages to places they shouldn't go.  They
> seem a bit too inflexible for my taste.  I won't object on these grounds,
> though.

> Just as one example, any address with a mailbox name beginning 'jhutz+' or
> 'jhutz=' and a domain ending in 'cmu.edu' is is probably mine, and if I
> used vacation, I'd certainly want it to treat mail sent to any such address
> as belonging to me, regardless of the specific host the mail went to or
> what, if anything, occurs after the plus.  I'd want that even if the mail
> server weren't also at CMU, if I ever decided to forward my CMU mail
> off-site.  One way to deal with this sort of problem would be to allow a
> match type and comparator to be specified for the addresses.

This sort of thing really needs to be up to the implementation, and the current
specification specifically allows this (section 3.5 list item 1) You really
don't want to have to require that every user specify complex matching criteria
in every vacation action they write.

In fact if you used our sieve implementation you'd find that any address of the
form "[e-mail]" is seen as being one of my addresses.
(Actually, this is only the default, the subaddress separator characters are
settable.) I believe our implementation to be fully compliant to the
specification in this regard.

> Section 3.7 says "The vacation is incompatible with reject.".  I think
> there are some words missing there.

I'll change this to read "the vacaction action is incompatible with the sieve
reject action".

> Section 3.3 says implementations SHOULD insert "an appropriate default"
> subject line.  Section 4.3 then mandates a particular form.  These should
> be made consistent with each other.

I'll change the earlier reference to say "implementations MUST generate ...
as specified below".

> I don't believe this document introduces new security issues that are not
> already covered by RFC3834.

I'll add a note to that effect.

Thanks for the careful review.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DKbo36047411; Tue, 13 Sep 2005 13:37:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8DKboac047410; Tue, 13 Sep 2005 13:37:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DKbmMt047398 for <[e-mail]>; Tue, 13 Sep 2005 13:37:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [66.228.163.20] (trustwho.corp.yahoo.com [66.228.163.20]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j8DKbV9B094946; Tue, 13 Sep 2005 13:37:31 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 13 Sep 2005 13:37:31 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050215)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeffrey Hutzelman <[e-mail]>
CC: Alexey Melnikov <[e-mail]>, Sam Hartman <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Security review of SIEVE vacation
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff:

> I'm not real wild about the mechansims defined in sections 3.5 and 3.6 
> to try to avoid sending vacation messages to places they shouldn't go.  
> They seem a bit too inflexible for my taste.  I won't object on these 
> grounds, though.
> 
> Just as one example, any address with a mailbox name beginning 'jhutz+' 
> or 'jhutz=' and a domain ending in 'cmu.edu' is is probably mine, and if 
> I used vacation, I'd certainly want it to treat mail sent to any such 
> address as belonging to me, regardless of the specific host the mail 
> went to or what, if anything, occurs after the plus.  I'd want that even 
> if the mail server weren't also at CMU, if I ever decided to forward my 
> CMU mail off-site.  One way to deal with this sort of problem would be 
> to allow a match type and comparator to be specified for the addresses.

Not unsurprisingly, I thought about this when writing the ancient 
ancestral versions of the draft.  I assume the first paragraph of 
section 3.5 is sufficient to allow CMU mailers to deduce that 
[e-mail] is "yours" for the purpose of autoresponses.  At 
this point, it becomes a matter of policy.

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DIneWk035126; Tue, 13 Sep 2005 11:49:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8DIneB7035125; Tue, 13 Sep 2005 11:49:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8DInbRX035108 for <[e-mail]>; Tue, 13 Sep 2005 11:49:37 -0700 (PDT) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa06840; 13 Sep 2005 14:45 EDT
Date: Tue, 13 Sep 2005 14:45:50 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Sam Hartman <[e-mail]>
cc: Cyrus Daboo <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Security review of SIEVE vacation
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
Originator-Info: login-token=Mulberry:012/NAQEVbtbQnPrjBDnFwr3Jld2tiJ7lIaG6lEXM=; token_authority=[e-mail]
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Monday, September 12, 2005 07:31:42 PM +0100 Alexey Melnikov 
<[e-mail]> wrote:

> Jeff, Ned Freed, the author of vacation asked to have the results of
> security review of the vacation draft in writing. If you didn't find any
> issue, can you please acknowledge that.
>
> If you are too busy to do that quickly, can you please let Sam know so
> that he can find another reviewer.
>
> Cyrus and I would like to avoid any security related surprises during
> IETF wide LC.


Section 3.3 says "... Implementations MAY also impose security restructions 
on what addresses can be specified in a ":from" parameter...".  I'd drop 
the word "security" here; such restrictions are a matter of policy which 
may or may not actually have anything to do with security.

I'm not real wild about the mechansims defined in sections 3.5 and 3.6 to 
try to avoid sending vacation messages to places they shouldn't go.  They 
seem a bit too inflexible for my taste.  I won't object on these grounds, 
though.

Just as one example, any address with a mailbox name beginning 'jhutz+' or 
'jhutz=' and a domain ending in 'cmu.edu' is is probably mine, and if I 
used vacation, I'd certainly want it to treat mail sent to any such address 
as belonging to me, regardless of the specific host the mail went to or 
what, if anything, occurs after the plus.  I'd want that even if the mail 
server weren't also at CMU, if I ever decided to forward my CMU mail 
off-site.  One way to deal with this sort of problem would be to allow a 
match type and comparator to be specified for the addresses.

Section 3.7 says "The vacation is incompatible with reject.".  I think 
there are some words missing there.

Section 3.3 says implementations SHOULD insert "an appropriate default" 
subject line.  Section 4.3 then mandates a particular form.  These should 
be made consistent with each other.


I don't believe this document introduces new security issues that are not 
already covered by RFC3834.

-- Jeff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CJo3Oc009486; Mon, 12 Sep 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8CJo3fZ009484; Mon, 12 Sep 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CJo3UQ009462 for <[e-mail]>; Mon, 12 Sep 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EEuJW-0004EI-U5; Mon, 12 Sep 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-rfc3598bis-01.txt 
Message-Id: <[e-mail]>
Date: Mon, 12 Sep 2005 15:50:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering -- Subaddress Extension
	Author(s)	: K. Murchison
	Filename	: draft-ietf-sieve-rfc3598bis-01.txt
	Pages		: 14
	Date		: 2005-9-12
	
On email systems that allow for "subaddressing" or "detailed
   addressing" (e.g., "[e-mail]"), it is sometimes
   desirable to make comparisons against these sub-parts of addresses.
   This document defines an extension to the Sieve mail filtering
   language that allows users to compare against the user and detail
   parts of an address.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-rfc3598bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-rfc3598bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-rfc3598bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-rfc3598bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j88CbEkN014515; Thu, 8 Sep 2005 05:37:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j88CbEat014514; Thu, 8 Sep 2005 05:37:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j88CbDQh014507 for <[e-mail]>; Thu, 8 Sep 2005 05:37:13 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.52) id 1EDLeR-0003SO-Ud for [e-mail]; Thu, 08 Sep 2005 14:37:11 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 #11) id 1EDLeR-0003Cd-RL for [e-mail]; Thu, 08 Sep 2005 14:37:11 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.53 #2) id 1EDLeR-00039g-Hf for [e-mail]; Thu, 08 Sep 2005 14:37:11 +0200
Date: Thu, 8 Sep 2005 14:37:11 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Sep 06, 2005 at 11:28:20AM +0100, Alexey Melnikov wrote:
> I would like to draw your attention to the following draft:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-01.txt>
> 
> A two week working group last call of this document starts today on 
> September 6th 2005 and ends on Tuesday, September 20th 2005 at 6 pm EST.
> 
> Please review this document and send issues to the list or direct to the 
> author(s).

I have no serious issues, but some minor ones:

I miss a list of changes.  Aren't there any? I miss a table of contents,
too.

I miss a section "Interaction with Other Sieve Actions".  Obviously,
"relational" is only incompatible with comparators that return no
sort information.  There are no incompatibilities with any actions
and implicit keep is not touched, but I would prefer not having to
read that between the lines.

Section 2:

   The capability string associated with extension defined in this
   document is "relational".

I think this does not belong to "Conventions used in this document",
but to its own section "Capability Identifier".

Section 4.1:

   The VALUE match type may be used with any comparator which returns
   sort information.

And which comparator of the base language does that? All, I guess,
but I miss reading that.

Am I right in thinking that using "i;octet", the left side " B " is
equal to "B" (white space is stripped from the left side), but "B"
is not equal to " B " (white space is not stripped from the right side)?

Is white space on the right side an error when used with "eq"?

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j86ASP5k018886; Tue, 6 Sep 2005 03:28:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j86ASP8t018885; Tue, 6 Sep 2005 03:28:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j86ASO1c018879 for <[e-mail]>; Tue, 6 Sep 2005 03:28:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 6 Sep 2005 11:28:22 +0100
Message-ID: <[e-mail]>
Date: Tue, 06 Sep 2005 11:28:20 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt  (relational test)
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-01.txt>

A two week working group last call of this document starts today on 
September 6th 2005 and ends on Tuesday, September 20th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, 
please send both co-chairs (or the list) an email to indicate you have 
looked at it. This will allow the chairs to gauge the scope of reviews 
of this document to aid in our determination on whether to send it to 
the IESG. Thanks.

--
Alexey Melnikov
SIEVE WG Co-chair




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j859JLDR078111; Mon, 5 Sep 2005 02:19:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j859JLuj078110; Mon, 5 Sep 2005 02:19:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j859JJIY078100 for <[e-mail]>; Mon, 5 Sep 2005 02:19:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Mon, 5 Sep 2005 10:19:13 +0100
Message-ID: <[e-mail]>
Date: Sun, 04 Sep 2005 23:02:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: Sieve Mailing List <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
References: <[e-mail]>  , <[e-mail]>  <[e-mail]>  <[e-mail]>  <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]>, <[e-mail]> <[e-mail]> <028101c5ac9a$342ccee0$dbfac350@nigelhome> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Tue, Aug 30, 2005, ""Nigel Swinson"" <[e-mail]>
>said:  
>
>>>I think we all agree what the term "global variable" means in the 
>>>variables draft.
>>>But if people feel that the term "global variable" might be confusing, we 
>>>can still replace it with something else as an editorial change.
>>>      
>>>
>>Well at the risk of getting hit, I think it would be wise to change it from:
>>
>>   All variables have global scope: they are visible until processing
>>   stops.
>>
>>To:
>>
>>   All variables have file scope: they are visible to the remainder
>>   of the current script. 
>>
>
>As Kjetil pointed out last week, there is only one script, though there
>may be many files included. We should be careful not to confuzzle the two
>words.
>
And considering that the term "file" is not currently used in the 
variables draft, I would rather not introduce a new term just to define 
"scope".

>Also, from the point of view of the variables draft in a vacuum,
>there is only one file, only one script, and only one scope. 
>  
>
Right.

>How about this:
>
>    All variables have global scope within a script. Future specifications
>    may allow for a script to be composed of more than one file,
>
How about replacing "file" with more abstract "part"?
Sieve scripts are not necessarily stored as files.

>    or for
>    running more than one script per message [delivery?].
>
"per delivery" or "per message per recipient" is better, IMHO.
One message can have multiple recipients, all subject to different Sieve 
filters.

> Such
>    specifications may provide for different variable scoping rules.
>  
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81HCAkK055108; Thu, 1 Sep 2005 10:12:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81HCAuH055106; Thu, 1 Sep 2005 10:12:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81HC8Tx055100 for <[e-mail]>; Thu, 1 Sep 2005 10:12:08 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 1 Sep 2005 10:12:04 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1125594724; h=Date: 	 From:Subject:MIME-version:Content-type; b=InOYFOba6N1xXvDqot0+GEmzr TwTMIBFbbMaHOwILisK49NuMa3apX75Fk7GGKRWJY9joAUWdi83Q2CA22y8TQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 01 Sep 2005 10:12:01 -0700 (PDT)
Cc: MTA filtering mailing list <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 01 Sep 2005 09:45:49 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-spamtestbis-01.txt
In-reply-to: "Your message dated Thu, 01 Sep 2005 16:10:16 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Alexey Melnikov wrote:

> > I would like to draw your attention to the following draft:
> >
> > <http://www.ietf.org/internet-drafts/draft-ietf-sieve-spamtestbis-01.txt>
> >
> > A two week working group last call of this document starts today on
> > August 15th 2005 and ends on Monday, August 29th 2005 at 6 pm EST.

> Hi folks,
> The WGLC has ended. I've sent 2 editorial corrections directly to the
> author.
> I've seen no comments on the mailing list, however I can't interpret
> that that the document is just perfect and can be sent to IESG.
> So can I please ask people who have reviewed the document to send me a
> short note saying that the document is Ok. I suggest that you volunteer,
> or I will start picking some victims!

I just reviewed the draft. A few comments...

First and most important, the specification fails to state what value is
checked by spamtest :percent when no spam test has been done. There are
basically four possibilities:

(1) Return an error. This has the effect of requiring robust scripts to
    perform a spamtest :value "eq" :comparator "i;ascii-numeric" "0"
    prior to doing a spamtest :percent. I don't think this is a good
    idea.

(2) Return 0, which of course conflates no test with test and found to
    be clear.

(3) Return an out of range value like "" or "-1" or "<untested>" or whatever.

(4) State that implementations are free to return whatever they want in this
    case. This more or less reduces to (1).

I think either (2) or (3) is the right choice.

Having the specification be silent on this issue is not good since people
will code their scripts to whatever behavior they see locally.

The document states that require ["spamtest", "spamtestplus"] SHOULD NOT be
done. It is hard to see how the use of requirements language can be usefully
applied to script construction. An implementation has to accept this and most
implementations have no way of warning about problematic usage (nor do I think
generating a warning would be appropriate in this case).

It would be better to say something like "In the interests of brevity and
clarity, scripts should specify either spamtestplus or spamtest in their
require clause, but not both".

It would also be good to reword the "MUST NOT use spamtest :percent without
require spamtestplus" as a sieve implementation requirement rather than a
script coding requirement. Maybe something like "sieve implementations MUST
return an error if :percent is used and spamtestplus is not specified".

Finally, the first and second parts of the security considerations, although
identical to RFC 3685, could use some clarification. THe first part currently
says:

   SIEVE implementations SHOULD ensure that "spamtest" and "virustest"
   tests can only occur for messages that have gone through a legitimate
   spam or virus check process.  If such checks rely on the addition of
   special headers to messages, it is the responsibility of the
   implementation to ensure that such headers cannot be spoofed by the
   sender, to prevent the implementation from being tricked into
   returning the wrong result for the test.

How can an implementation possibly control when scripts perform certain tests?
The intent, I think, is to say that the tests should only return an indication
that a test has been done when a legitimate test really has been done. So how
about:

   SIEVE implementations SHOULD ensure that "spamtest" and "virustest"
   tests only report spam and virus test results for messages that actually
   have gone through a legitimate spam or virus check process.  In particular,
   if such checks rely on the addition and subsequent checking of private
   header fields, it is the responsibility of the implementation to ensure
   that such headers cannot be spoofed by the sender or intermediary and
   thereby prevent the implementation from being tricked into returning the
   wrong result for the test.

The second part says:

   Server administrators MUST ensure that the virus checking tools are
   kept up to date, to provide reasonable protection for users using the
   "virustest" test.  Users should be made aware of the fact that the
   "virustest" test does not provide a 100% reliable way to remove all
   viruses, and they should continue to exercise caution when dealing
   with messages of unknown content and origin.

This is a fine bit of motherhood and apple pie, but the use of MUST here is
inappropriate IMO since the behavior of server admins has little if anything to
do with sieve implementation compliaance.

That's it!

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81FALeP043124; Thu, 1 Sep 2005 08:10:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81FALEv043123; Thu, 1 Sep 2005 08:10:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81FAKnv043106 for <[e-mail]>; Thu, 1 Sep 2005 08:10:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 1 Sep 2005 16:10:18 +0100
Message-ID: <[e-mail]>
Date: Thu, 01 Sep 2005 16:10:16 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-spamtestbis-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> I would like to draw your attention to the following draft:
>
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-spamtestbis-01.txt>
>
> A two week working group last call of this document starts today on 
> August 15th 2005 and ends on Monday, August 29th 2005 at 6 pm EST.

Hi folks,
The WGLC has ended. I've sent 2 editorial corrections directly to the 
author.
I've seen no comments on the mailing list, however I can't interpret 
that that the document is just perfect and can be sent to IESG.
So can I please ask people who have reviewed the document to send me a 
short note saying that the document is Ok. I suggest that you volunteer, 
or I will start picking some victims!

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81EjC9A040840; Thu, 1 Sep 2005 07:45:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81EjCUR040839; Thu, 1 Sep 2005 07:45:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81EjB0d040832 for <[e-mail]>; Thu, 1 Sep 2005 07:45:12 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j81EePuG031082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 1 Sep 2005 10:40:26 -0400
Date: Thu, 01 Sep 2005 10:45:08 -0400
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Last Call for refuse complete
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
The last call on the refuse draft finished a day ago. The authors will be 
producing a new draft reflecting last call comments shortly. It may be that 
we need another last call if changes are significant (e.g. reject and 
refuse are merged into one action), but we will wait and see. Thanks to all 
those who commented on this in the last couple of week.

Just as a warning we've got another three drafts to do last calls on this 
month, and we'll be starting on those next week.

-- 
Cyrus Daboo