Subject: Updated Sieve notification draft

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Sep 2005 15:26:46 +0100

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:+123456789"

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

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" "[email-masked]" {
            notify :high :message "This is probably very important";
            # Don't send any further notifications
            stop;
        }

        if header :contains "to" "[email-masked]" {
            # :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:[email-masked]?You%20got%20mail&subject=SIEVE"
               :id "foobar";

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

            notify :method "sms:+14085551212" :id "foobar"
                   :high :message "BOSS: ${subject}";
        }

        if header :contains "to" "[email-masked]" {
            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: [email-masked]
   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 <[email-masked]>

   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: (408) 720-3835
    EMail: [email-masked]

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

    Phone: (914) 784-7408
    Email: [email-masked]

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

    Email: [email-masked]

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
   [email-masked].

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.

---

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 27 Sep 2005 12:10:22 +0100

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Sep 2005 13:50:21 +0100

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

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

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

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

>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 rigorous…
Let me think about this one for a bit.

>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.
>
>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 previous notifications.
Done.

>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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 27 Sep 2005 17:56:04 +0200

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

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

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

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Sep 2005 18:24:04 +0100

>        notifications should be sent when mail is received.
I've deleted "when mail is received" part and used the suggested text.

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

>the users of that notification method.
Yes, I've changed "appended to the notification" to "included in the 
notification".

>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

---

From: Michael Haardt <[email-masked]>
Date: Wed, 28 Sep 2005 09:59:27 +0200

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

> probably done if XMPP notifications are described in an informative 

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.

> 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

---

From: Michael Haardt <[email-masked]>
Date: Wed, 28 Sep 2005 10:29:45 +0200

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

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.

> 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

---

From: Michael Haardt <[email-masked]>
Date: Wed, 28 Sep 2005 10:37:39 +0200

> 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

---

From: Michael Haardt <[email-masked]>
Date: Wed, 28 Sep 2005 10:50:57 +0200

> 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

---

From: Michael Haardt <[email-masked]>
Date: Wed, 28 Sep 2005 11:13:46 +0200

> be published soon as draft-ietf-sieve-notify-00.txt. The document is 

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.

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

>                [<":low" / ":normal" / ":high">]

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

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

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

>     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

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Sep 2005 07:13:13 -0700 (PDT)

> 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

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

> them, but perhaps recommend.

Sounds right.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 29 Sep 2005 18:39:53 -0400

> be published soon as draft-ietf-sieve-notify-00.txt. The document is 

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.

    > preformed. It defines the new action "notify".

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

    > 1.0

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?

    >  ... If an URI schema is

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

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.

    > 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

    > 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

---

From: Ned Freed <[email-masked]>
Date: Fri, 30 Sep 2005 08:05:05 -0700 (PDT)

> end of the script's execution (otherwise the "denotify" made no sense).

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

> 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

I hope not.

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

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

---

From: "Nigel Swinson" <[email-masked]>
Date: Fri, 30 Sep 2005 17:02:40 +0100

> 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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 30 Sep 2005 18:14:41 +0200

> usefully. (Tnink about the internationalization issues.)

I agree.

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

---

From: Ned Freed <[email-masked]>
Date: Fri, 30 Sep 2005 09:26:03 -0700 (PDT)

> 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

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 30 Sep 2005 13:58:24 -0400

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

    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:

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

> scripts that function properly, debug scripts, and just about everything

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

---

From: Michael Haardt <[email-masked]>
Date: Fri, 30 Sep 2005 22:14:14 +0200

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

> Notifications should contains what the action says they should contain.

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

> 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

Date: Fri, 30 Sep 2005 22:14:14 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

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

> Notifications should contains what the action says they should contain.

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

> 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

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 30 Sep 2005 13:58:24 -0400
To: Ned Freed <[email-masked]>
Cc: Mark E Mallett <[email-masked]>, Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

The kicker being:

mm

Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
To: Nigel Swinson <[email-masked]>
Date: Fri, 30 Sep 2005 09:26:03 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

				Ned

Subject: Re: Updated Sieve notification draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Fri, 30 Sep 2005 18:14:41 +0200
Sender: [email-masked]

I agree.

-- 
Kjetil T.

From: "Nigel Swinson" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: "Alexey Melnikov" <[email-masked]>, "MTA filtering mailing list" <[email-masked]>
Subject: Re: Updated Sieve notification draft
Date: Fri, 30 Sep 2005 17:02:40 +0100
Sender: [email-masked]

Nigel 

Cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
To: Mark E Mallett <[email-masked]>
Date: Fri, 30 Sep 2005 08:05:05 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

I hope not.

				Ned

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 29 Sep 2005 18:39:53 -0400
To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Hi-

Meaning?

Cc: [email-masked]
To: Michael Haardt <[email-masked]>
Date: Wed, 28 Sep 2005 07:13:13 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Sounds right.

				Ned

Date: Wed, 28 Sep 2005 11:13:46 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Michael

Date: Wed, 28 Sep 2005 10:50:57 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Michael

Date: Wed, 28 Sep 2005 10:37:39 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Michael

Date: Wed, 28 Sep 2005 10:29:45 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Michael

Date: Wed, 28 Sep 2005 09:59:27 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Michael

Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Wed, 28 Sep 2005 00:23:48 +0200
Sender: [email-masked]

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.

Cc: MTA filtering mailing list <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Sep 2005 13:31:16 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

> 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

Date: Tue, 27 Sep 2005 18:31:25 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

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?

Date: Tue, 27 Sep 2005 18:24:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Alexey

Subject: Re: Updated Sieve notification draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Tue, 27 Sep 2005 17:56:04 +0200
Sender: [email-masked]

I suggest:

well, you need "body".

Date: Tue, 27 Sep 2005 13:50:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Nigel Swinson <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Updated Sieve notification draft
Sender: [email-masked]

Hi Nigel,

Done.

Yes!

I think so.

Done.

Alexey

From: "Nigel Swinson" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Subject: Re: Updated Sieve notification draft
Date: Tue, 27 Sep 2005 12:10:22 +0100
Sender: [email-masked]

Abstract:

3.1 Notify Action
    In

Cheers

Nigel

Date: Tue, 27 Sep 2005 10:50:15 +0100
From: Alexey Melnikov <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
Sender: [email-masked]

Aaron Stone wrote:

>On Mon, Sep 26, 2005, Alexey Melnikov <[email-masked]> 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.

Date: Mon, 26 Sep 2005 23:54:52 -0000
To: "Alexey Melnikov" <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
From: "Aaron Stone" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Sender: [email-masked]

On Mon, Sep 26, 2005, Alexey Melnikov <[email-masked]> 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

Date: Mon, 26 Sep 2005 18:20:46 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: [email-masked]
Subject: Re: scoping and variables yet again
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-notify-00.txt 
Date: Mon, 26 Sep 2005 10:50:02 -0400
Sender: [email-masked]

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

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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 26 Sep 2005 15:45:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
Sender: [email-masked]

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

Date: Mon, 26 Sep 2005 15:26:46 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Updated Sieve notification draft
Sender: [email-masked]

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

Hi folks,

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"

Status of this Memo

Copyright Notice

Abstract

1.  Introduction

2.  Capability Identifier

3.  Actions

3.1.  Notify action

    Example:

    Example:

3.2.  Denotify Action

    The sequence:

      denotify;
      notify;

                                        # what is cancelled

    Example:

6.  IANA Considerations

   To: [email-masked]

7.  Acknowledgments

8.  References

    [XMPP]

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

    Phone: (408) 720-3835

    Wolfgang Segmuller

    Phone: (914) 784-7408

    Alexey Melnikov (Editor)
    Isode Limited

Disclaimer of Validity

Copyright Statement

Acknowledgment

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

Date: Mon, 26 Sep 2005 11:44:51 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

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

Date: Fri, 23 Sep 2005 22:44:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: "Mark E. Mallett" <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

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.

Cc: Ned Freed <[email-masked]>, [email-masked]
To: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Sep 2005 17:52:57 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

> 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

Cc: Ned Freed <[email-masked]>, MTA filtering mailing list <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 23 Sep 2005 09:22:04 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt
Sender: [email-masked]

> 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. [email-masked]
> 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

Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Fri, 23 Sep 2005 15:11:54 +0200
Sender: [email-masked]

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.

Date: Fri, 23 Sep 2005 14:05:28 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Sender: [email-masked]

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

Date: Fri, 23 Sep 2005 12:01:23 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
Sender: [email-masked]

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.

Date: Fri, 23 Sep 2005 11:48:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt  (relational test)
Sender: [email-masked]

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

Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Fri, 23 Sep 2005 11:58:49 +0200
Sender: [email-masked]

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. [email-masked]
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.

To: Ned Freed <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt 
Date: Thu, 22 Sep 2005 20:21:29 -0700
Sender: [email-masked]

Ned Freed <[email-masked]> 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

Cc: MTA filtering mailing list <[email-masked]>
To: Philip Guenther <[email-masked]>
Date: Thu, 22 Sep 2005 19:54:39 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt
Sender: [email-masked]

> 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

To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: removeflag \recent 
Date: Thu, 22 Sep 2005 19:42:00 -0700
Sender: [email-masked]

Kjetil Torgrim Homme <[email-masked]> 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

To: MTA filtering mailing list <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-vacation-03.txt 
Date: Thu, 22 Sep 2005 19:35:50 -0700
Sender: [email-masked]

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

To: MTA filtering mailing list <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt 
Date: Thu, 22 Sep 2005 19:02:35 -0700
Sender: [email-masked]

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

To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Stripping leading/trailing spaces in relational draft 
Date: Thu, 22 Sep 2005 15:02:08 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> 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

Date: Thu, 22 Sep 2005 22:35:04 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Sender: [email-masked]

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

Date: Thu, 22 Sep 2005 22:28:35 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-03.txt
Sender: [email-masked]

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

Subject: Re: Stripping leading/trailing spaces in relational draft
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Thu, 22 Sep 2005 20:51:11 +0200
Sender: [email-masked]

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.

Date: Thu, 22 Sep 2005 18:59:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: [email-masked]
Subject: Re: removeflag \recent
Sender: [email-masked]

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.

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 22 Sep 2005 13:56:51 -0400
To: [email-masked]
Subject: Re: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

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

Subject: Re: removeflag \recent
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Thu, 22 Sep 2005 19:51:54 +0200
Sender: [email-masked]

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.

Cc: [email-masked]
To: Michael Haardt <[email-masked]>
Date: Thu, 22 Sep 2005 10:35:11 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-03.txt
Sender: [email-masked]

> 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

Date: Thu, 22 Sep 2005 18:36:41 +0100
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 22 Sep 2005 13:26:33 -0400
To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

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

Cc: MTA filtering mailing list <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Sep 2005 10:11:12 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

> 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

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-03.txt
From: Michael Haardt <[email-masked]>
Date: Thu, 22 Sep 2005 16:42:47 +0200
Sender: [email-masked]

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

From: "Nigel Swinson" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Subject: Re: Stripping leading/trailing spaces in relational draft
Date: Thu, 22 Sep 2005 14:42:54 +0100
Sender: [email-masked]

Yeah I think we do.
 
----- Original Message ----- 
From: "Alexey Melnikov" <[email-masked]>
To: "MTA filtering mailing list" <[email-masked]>
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
> 
> 

Date: Wed, 21 Sep 2005 19:44:56 -0400
From: Cyrus Daboo <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Working Group Last Call: draft-ietf-sieve-vacation-03.txt
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-vacation-03.txt 
Date: Wed, 21 Sep 2005 15:50:02 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 21 Sep 2005 18:40:43 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt  (relational test)
Sender: [email-masked]

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?

Date: Wed, 21 Sep 2005 16:41:58 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Stripping leading/trailing spaces in relational draft
Sender: [email-masked]

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

Cc: [email-masked]
To: Mark E Mallett <[email-masked]>
Date: Wed, 21 Sep 2005 08:09:06 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

> 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 [email-masked] 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

Date: Wed, 21 Sep 2005 16:07:09 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Initial revisions of Sieve Loops and Sieve Notifications?
Sender: [email-masked]

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

Date: Wed, 21 Sep 2005 16:05:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: removeflag \recent
Sender: [email-masked]

Philip Guenther wrote:

>Alexey Melnikov <[email-masked]> 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?

Date: Wed, 21 Sep 2005 16:02:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
Sender: [email-masked]

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.

To: MTA filtering mailing list <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test) 
Date: Tue, 20 Sep 2005 15:41:57 -0700
Sender: [email-masked]

[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

Date: Tue, 20 Sep 2005 12:23:01 -0400
From: Cyrus Daboo <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt        (relational test)
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 20 Sep 2005 11:57:23 -0400
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Sender: [email-masked]

(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

Date: Mon, 19 Sep 2005 08:50:53 -0700
From: Rob Siemborski <[email-masked]>
To: Philip Guenther <[email-masked]>
Subject: Re: removeflag \recent
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On 9/18/05, Philip Guenther <[email-masked]> 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    |     [email-masked]
Software Engineer     |                       |            650-623-6925

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: removeflag \recent 
Date: Sun, 18 Sep 2005 20:28:56 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> 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

Date: Sat, 17 Sep 2005 01:06:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

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

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: scoping and variables yet again
Date: Fri, 16 Sep 2005 14:03:04 +0100
Sender: [email-masked]

> 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

Subject: scoping and variables yet again
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Fri, 16 Sep 2005 14:30:21 +0200
Sender: [email-masked]

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.

Date: Thu, 15 Sep 2005 22:11:07 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: removeflag \recent
Sender: [email-masked]

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.

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 15 Sep 2005 19:30:35 -0400
To: [email-masked]
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

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 [email-masked] 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-

Date: Thu, 15 Sep 2005 14:28:07 -0700
From: Tim Showalter <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: removeflag \recent
Sender: [email-masked]

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

Date: Thu, 15 Sep 2005 16:18:25 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Ned Freed <[email-masked]>, Michael Haardt <[email-masked]>
cc: Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Security review of SIEVE vacation
Originator-Info: login-token=Mulberry:01aj9W9dSny2m2is52nb2GZAGxjSDxc8/XtIRaoL8=; token_authority=[email-masked]
Sender: [email-masked]

On Thursday, September 15, 2005 10:44:48 AM -0700 Ned Freed 
<[email-masked]> 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?

Cc: Sam Hartman <[email-masked]>, Ned Freed <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
To: Michael Haardt <[email-masked]>
Date: Thu, 15 Sep 2005 10:44:48 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

> 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

Date: Thu, 15 Sep 2005 16:00:27 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Aaron Stone <[email-masked]>, [email-masked]
Subject: Re: An imapflags question
Sender: [email-masked]

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.

Date: Thu, 15 Sep 2005 15:03:11 +0200
From: Michael Haardt <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Ned Freed <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

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

To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
From: Michael Haardt <[email-masked]>
Date: Thu, 15 Sep 2005 14:50:15 +0200
Sender: [email-masked]

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

Date: Thu, 15 Sep 2005 12:24:38 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: removeflag \recent
Sender: [email-masked]

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

Date: Thu, 15 Sep 2005 10:21:58 +0100
Subject: Re: An imapflags question
From: Dave Cridland <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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.

Subject: An imapflags question
From: Aaron Stone <[email-masked]>
To: [email-masked]
Date: Wed, 14 Sep 2005 23:58:48 -0700
Sender: [email-masked]

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

Date: Wed, 14 Sep 2005 17:17:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt  (relational test)
Sender: [email-masked]

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.

Date: Wed, 14 Sep 2005 16:18:26 +0100
Subject: Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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.

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-01.txt
From: Michael Haardt <[email-masked]>
Date: Wed, 14 Sep 2005 16:23:53 +0200
Sender: [email-masked]

> 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

Date: Wed, 14 Sep 2005 07:01:36 -0700
From: Cyrus Daboo <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt
Sender: [email-masked]

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

To: Michael Haardt <[email-masked]>
Cc: Ned Freed <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Security review of SIEVE vacation
From: Sam Hartman <[email-masked]>
Date: Wed, 14 Sep 2005 10:00:04 -0400
Sender: [email-masked]

>>>>> "Michael" == Michael Haardt <[email-masked]> 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> [email-masked] 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.

Date: Wed, 14 Sep 2005 10:43:10 +0100
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

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.

Date: Wed, 14 Sep 2005 10:58:44 +0200
From: Michael Haardt <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

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 [email-masked] 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

Date: Tue, 13 Sep 2005 21:48:39 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Security review of SIEVE vacation
Originator-Info: login-token=Mulberry:01BaviNm8TV6pR9lq3OCkSpZwdGWGM31tyIBCbOys=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, September 13, 2005 06:25:06 PM -0700 Ned Freed 
<[email-masked]> 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

Cc: Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
To: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Sep 2005 18:25:06 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

> On Monday, September 12, 2005 07:31:42 PM +0100 Alexey Melnikov
> <[email-masked]> 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 "[email-masked]" 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

Date: Tue, 13 Sep 2005 13:37:31 -0700
From: Tim Showalter <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Security review of SIEVE vacation
Sender: [email-masked]

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 
[email-masked] is "yours" for the purpose of autoresponses.  At 
this point, it becomes a matter of policy.

Tim

Date: Tue, 13 Sep 2005 14:45:50 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Security review of SIEVE vacation
Originator-Info: login-token=Mulberry:012/NAQEVbtbQnPrjBDnFwr3Jld2tiJ7lIaG6lEXM=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, September 12, 2005 07:31:42 PM +0100 Alexey Melnikov 
<[email-masked]> 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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-rfc3598bis-01.txt 
Date: Mon, 12 Sep 2005 15:50:02 -0400
Sender: [email-masked]

--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., "[email-masked]"), 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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 8 Sep 2005 14:37:11 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt (relational test)
Sender: [email-masked]

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

Date: Tue, 06 Sep 2005 11:28:20 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Working Group Last Call: draft-ietf-sieve-3431bis-01.txt  (relational test)
Sender: [email-masked]

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

Date: Sun, 04 Sep 2005 23:02:57 +0100
From: Alexey Melnikov <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: Sieve Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Sender: [email-masked]

Aaron Stone wrote:

>On Tue, Aug 30, 2005, ""Nigel Swinson"" <[email-masked]>
>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.
>  
>

Cc: MTA filtering mailing list <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Date: Thu, 01 Sep 2005 09:45:49 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-spamtestbis-01.txt
Sender: [email-masked]

> 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

Date: Thu, 01 Sep 2005 16:10:16 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-spamtestbis-01.txt
Sender: [email-masked]

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

Date: Thu, 01 Sep 2005 10:45:08 -0400
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Last Call for refuse complete
Sender: [email-masked]

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