Re: draft-freed-sieve-in-xml status?

[Alexey Melnikov <[e-mail]>]

Ned Freed wrote:
>>> But I'm sitll a little confused as to what you're asking for here. If you're
>>> asking for removal of the explicit inline XML syntax examples in favor of a
>>> more abstract approach, I'd be fine with that if there's a WG consensus to make
>>> such a change.
>>>       
>> no - i'm very happy with the syntax examples
>>     
>> i would like to see the approach used in RFC 5023 (and others)
>> adopted, adding a normative description of the XML and making the
>> schema only informative.
>>     
> Personally, I find RFC 5023 approach, like the XOPEN object descriptions it's
> similar to, to be almost totally unreadable. Maybe it's the only reasonable way
> to do it when the element structure is quite complex, but that's not the case
> here.
>   
Speaking as an individual: I tend to agree with Ned here. I prefer 
having some formal syntax for defining XML + some examples demonstrating 
different Sieve features.
I think adding a descriptive definition of XML is a fair bit of work for 
little gain. However, I would not oppose to having some descriptive 
definition (which I think should be informative), especially if somebody 
suggests some text ;-).
> So, absent some fairly strong support for this from others in the group, I'm
> not going to pursue this.
>   






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBT8Pwuv064723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Dec 2008 01:25:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBT8Pwnx064722; Mon, 29 Dec 2008 01:25:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBT8PjmQ064604 for <[e-mail]>; Mon, 29 Dec 2008 01:25:57 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.11] ((unknown) [85.112.123.156])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 29 Dec 2008 08:25:44 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Mon, 29 Dec 2008 11:26:08 +0300
From: Alexey Melnikov <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
To: Ned Freed <[e-mail]>, Robert Burrell Donkin <[e-mail]>
CC: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:
>>> But I'm sitll a little confused as to what you're asking for here. If you're
>>> asking for removal of the explicit inline XML syntax examples in favor of a
>>> more abstract approach, I'd be fine with that if there's a WG consensus to make
>>> such a change.
>>>       
>> no - i'm very happy with the syntax examples
>>     
>> i would like to see the approach used in RFC 5023 (and others)
>> adopted, adding a normative description of the XML and making the
>> schema only informative.
>>     
> Personally, I find RFC 5023 approach, like the XOPEN object descriptions it's
> similar to, to be almost totally unreadable. Maybe it's the only reasonable way
> to do it when the element structure is quite complex, but that's not the case
> here.
>   
Speaking as an individual: I tend to agree with Ned here. I prefer 
having some formal syntax for defining XML + some examples demonstrating 
different Sieve features.
I think adding a descriptive definition of XML is a fair bit of work for 
little gain. However, I would not oppose to having some descriptive 
definition (which I think should be informative), especially if somebody 
suggests some text ;-).
> So, absent some fairly strong support for this from others in the group, I'm
> not going to pursue this.
>   





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSNe6gI039969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 16:40:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSNe6KU039968; Sun, 28 Dec 2008 16:40:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSNdtuo039819 for <[e-mail]>; Sun, 28 Dec 2008 16:40:06 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 28 Dec 2008 15:39:49 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 28 Dec 2008 15:39:43 -0800 (PST)
Date: Sun, 28 Dec 2008 14:31:18 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Mon, 15 Dec 2008 13:00:12 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, Dec 14, 2008 at 9:59 PM, Ned Freed <[e-mail]> wrote:
> >> On Sun, Dec 14, 2008 at 6:06 PM, Ned Freed <[e-mail]> wrote:
> >> >> i note that the draft describes the infoset rather than defining it in
> >> >> the standard way. is there a reason for this decision?
> >> >
> >> > I don't know what "the standard way" is you're referring to. Perhaps you
> >> > could provide a reference to an RFC where this has been used?
> >
> >> AIUI XML is maintained by w3c (rather than IEFT) so is a
> >> recommendation. http://www.w3.org/TR/xml-infoset/ is the current
> >> document.
> >
> > Quite true, however, the IETF has its own specification for XML is supposed to
> > be used in RFCs: RFC 3470. And while infosets are mentioned as one approach to
> > specifying things about an XML format, there's no recommendation, let alone
> > requirement, that they be used.
> >
> >> > This document is a little unusual in that it's defining a mapping of, if you
> >> > will, a non-XML infoset onto XML. As such, the natural approach seemed to be to
> >> > first discuss the structure of the language being mapped, then explain the
> >> > mapping, and finish up with additional unique-to-XML semantics.
> >
> >> i agree that most of this arangement is natural. it's just jumping to
> >> a schema seems - to me - a little premature and inflexible.
> >
> > First of all, the use of XML Schema is in fact too inflexible to be allowed
> > to continue. The next revision will use Relax instead.

> XML schema is flexible but the flexibility comes at the price of
> readability. one of relax variants would be a better choice.

> however (in my experience) the generative tools commonly used for XML
> and web service binding, and editor generation tend not to offer good
> relax support. IMO the draft should offer secondary informative XML
> Schema or Schemata to assist developers using these tools.

The problem is that the unique particle attribution limitation in XML Schema
effectively precludes using it without some compromises. I am therefore opposed
to continuing to include it.

> > But I'm sitll a little confused as to what you're asking for here. If you're
> > asking for removal of the explicit inline XML syntax examples in favor of a
> > more abstract approach, I'd be fine with that if there's a WG consensus to make
> > such a change.

> no - i'm very happy with the syntax examples

> i would like to see the approach used in RFC 5023 (and others)
> adopted, adding a normative description of the XML and making the
> schema only informative.

Personally, I find RFC 5023 approach, like the XOPEN object descriptions it's
similar to, to be almost totally unreadable. Maybe it's the only reasonable way
to do it when the element structure is quite complex, but that's not the case
here.

So, absent some fairly strong support for this from others in the group, I'm
not going to pursue this.

> >> sieve). there is a large and growing requirement for integration
> >> between mail and enterprise systems (typically coding in Java and .NET
> >> but also ruby and python). developers from enterprise backgrounds are
> >> typically strong on web+xml but very weak on mail.
> >
> > Yep, I've seen a lot of this as well. And the problem emcompasses far more than
> > Sieve: For example, a lot of people who are unfamiliar with email don't
> > understand very basic concepts such as the separation between envelope and
> > message content. (This particular issue actually pokes through into Sieve in
> > the form of whether an envelope or header test is appropriate.)

> i beg to differ slightly on this one

> some enterprise mail processing may happen during the SMTP transaction
> but it is more typical for the mail processing after storage. not all
> mail stored arrives through SMTP and so it is typical for any envelope
> information to be reduced to simple MIME headers.

Robert, with all due respect, you may have substantial expertise on the XML
front, but your comments here are actually doing little more than illustrate
the validity of my argument that there's a general issue with people not
getting how email works that isn't going to get fixed by anything we do here.
If you want this addressed the place to look is the email architecure
specifications being worked on by Dave Crocker.

And it is NOT typical for envelope information to be stored as headers. There
are several reasons for this:

(1) Envelopes only exist between the time of submission and final delivery.
    Transport actions do record certain bits of envelope information in
    trace header fields and final delivery is supposed to copy some additional
    envelope information into a couple of header fields, but these are NOT
    a message envelope and it is mistake to assume they are.

(2) During the time the envelope exists it is highy mutable, often changing
    form at every hop. This makes header storage of envelope information
    somewhat problematic.

(3) There are several SMTP extension that add to the envelope in various ways,
    requiring negotiation of what envelope information can and cannot be
    passed from one system to another. This tends to interact badly with
    schemes that store envelope information as a static part of the message.

(4) The fact that protocols other than SMTP are used for various email
    operations doesn't necessarily impact header/envelope separability.
    Other protocols maintain this separation and at least one of them, X.400,
    actually has a far greater degree of separation than SMTP does.

(5) Because there are effectively no controls on what ends up in headers, it
    is fairly easy for the separation between "header" headers and "envelope"
    headers to get lost. Among other things, this can create serious
    security vulnerabilities.

Now, this is not to say there aren't various ad-hoc schemes in use where active
envelope information ends up getting stuffed into the header. Such schemes date
back to BITNET's use of X-Envelope-To: to work around the 8x8 limit and
probably long before. But in my experience at least these things invariably
fail to provide a full and correct mapping for all of the possible information
that can exist in an SMTP (or X.400) envelope. And as a consequence they
invariably cause problems because of their inability to truly express envelope
semantics.

Indeed, if you have to capture envelope information in a static form - the main
current use-case for this is compliance archiving - in most cases you're better
off NOT using header-based schemes. We even have a standard format defined for
this: Batch SMTP. Although the format that's probably used the most is the one
Exchange generates that they call "envelope journaling", which puts the
envelope in the first text part of a MIME multipart. (On a side note, if anyone
knows where there's a precise and complete specification of the syntax used for
envelope journaling, I've appreciate a pointer.)

> most developers in
> these mail processing environments do not need to understand the
> difference between envelope and message content because - for them -
> there is no difference.

Yeah, that's what a lot of them think. The problem is they're quite simply
wrong, and it is isn't a harmless thing to be wrong about. I get plenty of
support calls from customers who got screwed by this lack of understanding.

And it is NOT a minor detail when someone sets up a compliance archiving system
that ends up in many cases not being able to determine who actually sent or
received a given message. (I only wish I was making up this example.)

> Sieve works very well as a general MIME document processing language.

Actuallly that's not Sieve's purpose at all and it isn't something Sieve is
currently good at. In fact we've only recently taken the first fairly tentative
step down the MIME processing path with the MIME loops extension and possibly
the convert extension. We'll see how well that turns out, but I have to say I'm
not optimistic that it will replace existing ad-hoc MIME processing facilities
like MIMEdefang.

> the envelope tests are - in many ways - peculiar since the rest of the
> specification really isn't mail specific. there are potentially some
> very interesting applications in this area so it would be a shame - i
> think - for the expert group to focus too strongly on SMTP at the
> expense of other IMHO equally valid Sieve use cases.

I don't object to the use of Sieve in other contexts - in principle. But the
devil is in the details. A good example of this is the use of Sieve in an IMAP
server as defined in draft-ietf-lemonade-imap-sieve-05.txt. This doesn't seem
like too much of a stretch from existing usage, but when I reviewed this
document a while back I found all sorts of semantic mismatches, some of them
quite serious.

> > But here's the dilemma: This stuff is complicated and in some cases fairly
> > subtle. This in turn means that the reiteration of even a subset of the
> > underlying design principles that implementors need to know takes up a lot of
> > space and will still fall short of the mark of giving the necessary guidance.
> > But it may lead to the belief that reading this specification (or for that
> > matter this one and RFC 5228) is in fact sufficient to understand how to use
> > Sieve. It quite simply isn't.

> again, i beg to differ

> sieve is very similar structurally to the guerrilla standards used in
> enterprise mail system for more than 5 years now. for most mail
> processing applications, only the container builders need to have a
> good understanding of the protocols. application developers are
> offered a safe environment and an OOP interface. i see no reason why
> sieve should be any different.

Understanding of the protocols isn't necessary, but I'm very much afraid  that
there's no avoiding an understanding of email semantics if you want things to
work properly. We may wish it were otherwise, but it just isn't.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBPHitmI089310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Dec 2008 10:44:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBPHitM8089309; Thu, 25 Dec 2008 10:44:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBPHircr089303 for <[e-mail]>; Thu, 25 Dec 2008 10:44:55 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 9B69C3A6A20; Thu, 25 Dec 2008 09:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-freed-sieve-ihave-04.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 25 Dec 2008 09:45:01 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Email Filtering: Ihave Extension
	Author(s)       : N. Freed
	Filename        : draft-freed-sieve-ihave-04.txt
	Pages           : 7
	Date            : 2008-12-25

This document describes the "ihave" extension to the Sieve email
filtering language.  The "ihave" extension provides a means to write
scripts that can take advantage of optional Sieve features but can
still run when those optional features are not available.  The
extension also defines a new error control command intended to be
used to report situations where no combination of available
extensions satisfies the needs of the script.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-freed-sieve-ihave-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBPDr8AV072826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Dec 2008 06:53:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBPDr8mb072825; Thu, 25 Dec 2008 06:53:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBPDr7OD072818 for <[e-mail]>; Thu, 25 Dec 2008 06:53:08 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.11] ((unknown) [85.112.123.156])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 25 Dec 2008 13:53:07 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 25 Dec 2008 16:53:17 +0300
From: Alexey Melnikov <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
To: SIEVE <[e-mail]>
Subject: WGLC on draft-ietf-sieve-notify-sip-message-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folk,
With my co-chair hat on:

This message officially starts the Sieve Working Group Last Call for the 
following document:
Sieve Notification Mechanism: SIP MESSAGE
<http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-sip-message-00.txt> 


The Working Group Last Call for this document starts on December 26th 
and will end on January 23rd (4 weeks to compensate for winter holidays).

Please send any comments to the Sieve mailing list or to the document 
authors. If you chose to do the latter, please CC Cyrus Daboo 
<[e-mail]>.
Reviews that found no issues are also welcomed, so if you review the 
document and find it acceptable, please let the mailing 
list/authors+chairs know as well.

Thank you,
Alexey, Sieve WG co-chairs



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBPC6sO5063747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Dec 2008 05:06:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBPC6sc9063746; Thu, 25 Dec 2008 05:06:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBPC6gCJ063717 for <[e-mail]>; Thu, 25 Dec 2008 05:06:53 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.11] ((unknown) [85.112.123.156])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 25 Dec 2008 12:06:40 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 25 Dec 2008 15:06:49 +0300
From: Alexey Melnikov <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
To: Robert Burrell Donkin <[e-mail]>
CC: Ned Freed <[e-mail]>, [e-mail]
Subject: How to get implementors involved  (was Re: draft-freed-sieve-in-xml status?)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert Burrell Donkin wrote:
>>> IMO it is a method (but not the only one) of producing reliable
>>> relatively bug free software. i think this is a reasonable
>>> pre-requisite for good interoperability. a good suite should aim to
>>> reduce the numbers of poor implementations which claim compatibility
>>> rather than try to ensure that good implementations interoperate
>>> perfectly.
>>>       
>> I'm always cautious about extrapolating from limited data - and we haven't seen
>> all that much use of scripts being moved from one implementation to another.
>> But to the extent we have, the problems that have shown up have been interop
>> issues. Unfortunately there are several Sieve implementations out there that
>> have chosen to ignore the extensions we've defined and roll their own to do
>> things the base specification does not cover.
>>     
> is there any (lightweight) way for implementors to let this group know
> about the extensions they've rolled? (other than showing on this list)
>   
I think subscribing to the mailing list is a low enough bar, but if 
people think that that is too heavyweight, then they may contact me 
directly.
But note that such contacts are going to be purely informal in their 
nature and have nothing to do with me be the Sieve WG chair. I just 
happen to know authors of various Sieve extensions ;-) and also happen 
own sieve.info domain.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBK8DkWA092587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Dec 2008 01:13:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBK8DkeE092586; Sat, 20 Dec 2008 01:13:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBK8DWZk092553 for <[e-mail]>; Sat, 20 Dec 2008 01:13:43 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 18so788050fkq.10 for <[e-mail]>; Sat, 20 Dec 2008 00:13:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xYxemfKqGHkgSsYO+PmjU4BCLG9fbvNGX39Ttm6GnJo=; b=tdo3oGtzlAYnQrYnQqOUXkAWbcwpNYCAus7AOduVCCWd+fIvl+eYPr5L5ZvsBh6guc TRuxsOLh6q2oURe7zhI6rg+z3nZ2PKRbMbxgzbpuc+OL9BRG8QihokVRir+Kzz5ygA3Z qDUaBD/8oH+OYjmushaCNWu4Bk/cfpZ/3YiHM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Zk6HQeDAbe6KXr8a0Msa2Y23qFEwyuf0svUIn9zbyTpHLuyVBiE7Zbfddz3mUH/4wc S2CT1ONHagg3fEr48+tkP1PxD+a4IOO44CSnwufPMiV2gKhaip3LMWnqSQ2mjGerXcJ2 RN3JdoPgbuZLX/F07rsAHAVe5QVqFSirOb/LE=
Received: by 10.181.208.11 with SMTP id k11mr1395684bkq.180.1229760811613; Sat, 20 Dec 2008 00:13:31 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sat, 20 Dec 2008 00:13:31 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 20 Dec 2008 08:13:31 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Arnt Gulbrandsen" <[e-mail]>, [e-mail], "Alexey Melnikov" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Dec 15, 2008 at 5:18 PM, Ned Freed <[e-mail]> wrote:
>> Ned Freed writes:
>> >>  is there a compliance test suite?
>> >
>> > Not as far as I know.
>
>> I wrote the guts of something like that after Prague IETF, where there
>> was a discussion about advancing sieve to draft. I stopped working on
>> it that when various people didn't reply to email about it (I did not
>> feel up to a one-man crusade), but people seem to care more now and
>> I'll return to it when one of my current drafts passes IESG.
>
>> > I certainly have no plans to write one or subject our implementation
>> > to any that someone else develops. I doubt if anyone else does
>> > either.
>
>> And I do hope you will review the document and run the code.
>
> Not if it's labelled as a compliance test. Again, I have no objections to
> unit
> tests or sample scripts and use them all the time.
>
> Compliance tests are another matter entirely. I realize evenyone has nothing
> but the best intentions here, but you know what's paved with those...
>
> If we release something we call a compliance suite it would be terribly easy
> for someone to take advantage of all that nice new copyright boilerplate
> that
> allows unrestricted use and take the code and turn it into a for-profit
> compliance test. It's but one step from there to RFPs requiring passage
> of that test.
>
> Really, you cannot know just how radioactive these things can be until
> you've
> gone through a bunch of them. You may think that such tests are amenable to
> a
> bright line standard of pass/fail, but that's just not how it ever ends up.
> There's always interpretation of results involved, especially when  you're
> probing for implementation limits (which these things always seem to do),
> and
> that leads to, um, let's call them "discussions" between the implementor and
> tester.

+1

the economics of Compliance Testing have been the principle cause of
the problems at the JCP. experts have to be employed to create,
maintain and supervise TCKs. however, experience at the JCP has also
shown that it is possible to create open source TCKs through
collaboration which are good enough to achieve reasonable compability
without the cost problems that beset traditional CTs.

i agree that issuing a samples RFC would be very useful especially if
these samples were created with the intention of elucidating
compliance. in other words, describing compliance cases which are not
CTs.

i'm not sure that issuing automatic test code through an RFC would be
a good plan. any code is likely to be tightly couple to the test
framework and langauge used to execute it (eg nUnit in .NET). i think
it would be better to just supply the sample data and a verbal
description of the use case.

i suggest that interested participants from the group set up an
offshore open source project using a liberal license (MIT, say) where
appropriate test fixtures could be developed, allowing easier
automated testing of implementations. compliance tests (in the sense
of tests created with the aim of demonstrating compatibility for
difficult cases) would be included as well as tests aimed at
development.  this would clearly flagged as an unofficial effort aimed
at encouraging the development good implementations (and so the spread
of the specification) rather than as an official part of the standards
effort.

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBJIsdpS054375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2008 11:54:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBJIsdqF054374; Fri, 19 Dec 2008 11:54:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBJIsQu6054352 for <[e-mail]>; Fri, 19 Dec 2008 11:54:37 -0700 (MST) (envelope-from [e-mail])
Received: by fxm13 with SMTP id 13so233224fxm.10 for <[e-mail]>; Fri, 19 Dec 2008 10:54:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Xde2Zghi06Kbc7HuIEwQ9kDlLUs8AuBZx5gGXdw/AmY=; b=hvLu1m4wDfJn3C8gx/AoBVtDQyjBW7ky5GiCThkb65OFBo9918VdT6aIOYtVbUd+4X 1oILODFLZJpmaftDDVjScsiotMXd/R7QIpV639v9KSi7HbIVSSmBEW9IYJn3AY+A718Y XZg4fxAI+UwpwXFZzB2N/OICKi/25eUIz3Lbo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JYhST3rp5q/SqMW+22DYkCuTt6BsnZYbAOsE4dMYYrkNq7HNpZiHJQKO8A0az8GS3Z s2urqsFa2yKe9wkCY4LjNDkOxsqPrW9RUPkXy9Cj5JJBcjbrebd1UJIYA8a2Kw68WnMk t91OEvQsx4Fp5NPg6N8jmh/zNOUmkzKVoTFE0=
Received: by 10.180.252.8 with SMTP id z8mr1168849bkh.158.1229712865680; Fri, 19 Dec 2008 10:54:25 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Fri, 19 Dec 2008 10:54:25 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 19 Dec 2008 18:54:25 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Alexey Melnikov" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Dec 15, 2008 at 4:04 AM, Ned Freed <[e-mail]> wrote:
>> On Sun, Dec 14, 2008 at 6:20 PM, Ned Freed <[e-mail]> wrote:
>> >> is there a compliance test suite?
>> >
>> > Not as far as I know. I certainly have no plans to write one or subject our
>> > implementation to any that someone else develops. I doubt if anyone else does
>> > either.
>> >
>> > The IETF isn't big on compliance test suites as a rule - the overarching goal
>> > here is interoperability, not compliance.
>
>> however, AFACT the charter of this group does include testing
>
> Unit tests != compliance test suites != interop testing. And the differences
> really matter.

intention != execution

given the traditional problems that good interoperability and
compliance testing have offered, there's a movement to take another
look at these issues applying the lessons learnt from the experience
of development-centered automated testing.

>> > And this IMNSHO is a very good thing. in the past I've worked on software,
>> > notably an X.400 implementation, governed by standards that emphasize
>> > compliance testing. What I've observed is that after passing multiple very
>> > extensive compliance test suites, the software still failed to interoperate
>> > worth a damn and required all sorts of tweaks before it could.
>
>> there is no silver interoperability bullet :-)
>
> Actually, I sort of disagree. We've held interop test events in the past for
> IMAP and SMTP that have been hugely successful in weeding out implementation
> problems and making stuff place nice together.
>
> It may not be a silver bullet, but it's surprisingly close. The main problem is
> participation, or rather lack of it - getting some of the major vendors to show
> up has been tough. And when there are popular implementations out there that
> makes no pretense of following the standard - and there are -  it's a real
> problem.

interoperability conferences are very useful but expensive, and this
expense disenfranchises

for example, this year m$ paid for serious interoperability testing
(along the lines you suggestsed) in the web services space including
flying FOSS developers around the world. i've heard very good things
about this but most interesting long term movement is that M$ is now
engaging with many of these developers to develop automated test
suites which demonstrate continued interoperability amongst the group.
AIUI the problem is that F2F is very expensive but interoperability is
an ongoing problem. automated testing is now mainstream and the
techiques developed should be applicable more widely.

> Now, Sieve presents special problems for the sort of testing that works best
> for protocols. Sieve is a language, not a protocol, and that makes it kinda
> tough to throw two implementation on the wire and see if they can communicate.

script based protocol testing can - with reasonable ease - be used to
automate this style of functional test

> So the charter includes the idea of developing an interop test suite. I'm not
> entirely clear how that's going to work, but hopefully it will do so by
> building up a suite of scripts covering things various implementations have
> found to be problematic and making sure other implementations handle them the
> same way. (if I have time I'll toss in some of the unit tests we use.)

one of the problem with this approach to testing is that it does
nothing to help implementors develop the basic function correctly. i
understand that this is the skill in developing traditional compliance
and interoperability suites, and i can understand how good
implementations find this very useful. they do nothing to encourage
new implemetations to get the basics right which IMO is equally
important.

>> all the stuff i help to develop is agile FOSS (TDD and BDD). automated
>> tests will need to be developed so it's just a question of whether the
>> tests exist already and can be shared and reused between
>> implementations. the unit tests themselves are only really effectively
>> portable between the moderns (.NET, java, python) but it's the
>> verified example mappings which will take the time.
>
> You now appear to be talking about unit tests. We use agile processes here as
> well and unit tests are part of what we do.

i would prefer to avoid splitting hairs about what exactly is a unit test

> But these are not at all the same
> as compliance tests or interop testing. Compliances tests focus on compliance
> with the specification - it's implicit in the name. A proper set of unit
> tests are written while looking at an actual implementation, and can look at
> known edge cases in an implementation, regression tests to make sure reported
> bugs don't appear, and code coverage. This is all great stuff and very
> valuable.

when developing against a specification, a range of automated tests
are valuable. these may well include automated created with unit
testing tools that aren't really best described as unit test (as well
as developer created tests that use other testing tools).

for example, when developing an xml serializer for sieve, i would
expect to create unit tests for each object in the pipeline, BDD
integration tests for partially assembled pipelines and functional
sieve script -> xml document tests. tests in the first category will
only be use internally, the second are only likely to be useful for
libraries sharing the interfaces defined but the functional sieve ->
xml document tests should be useful more generally. IMHO pooling the
third category would be worthwhile.

i agree that this isn't sufficient for a good compliance test suite -
it's unlikely to provide good enough coverage of difficult cases which
a compliance expert would create - but it should provide a reasonable
starting point and reduce the effort involved by allowing experts to
focus exclusively on difficult cases.

>> > As a result of this and several other experiences I must confess to
>> > considerable cynicism that compliance testing represents a path to
>> > interoperability. In my experience it does not, and has been for the most part
>> > a colossal waste of time.
>
>> automated testing has come a very long way in the last decade but i
>> understand your perspective
>
> GUI testing may have changed  by becoming more automatable (or not - this is
> not my area and I don't keep up with the state of the art), but I haven't seen
> all that much change in most other areas. Back in the late 70s and early 80s
> when I did math modelling software we actually did far more extensive unit
> testing and had better code coverage than we do now.

automated developer testing (TDD BDD etc) has now mainstreamed.
generally testing toolsets such as xUnit and xMock drove the rise of
FOSS and the (post-)modern languages (java, .NET, python, ruby) over
the last decade. this isn't to say that developers didn't test before
but automated testing and the agile methods it enables have
transformed the development landscape.

>> IMO it is a method (but not the only one) of producing reliable
>> relatively bug free software. i think this is a reasonable
>> pre-requisite for good interoperability. a good suite should aim to
>> reduce the numbers of poor implementations which claim compatibility
>> rather than try to ensure that good implementations interoperate
>> perfectly.
>
> I'm always cautious about extrapolating from limited data - and we haven't seen
> all that much use of scripts being moved from one implementation to another.
> But to the extent we have, the problems that have shown up have been interop
> issues. Unfortunately there are several Sieve implementations out there that
> have chosen to ignore the extensions we've defined and roll their own to do
> things the base specification does not cover.

is there any (lightweight) way for implementors to let this group know
about the extensions they've rolled? (other than showing on this list)

> <snip>
>
>> > The bottom line, such as it is, is that there's effectively no leeway in the
>> > copyright boilerplate you have to use if you want your stuff published as an
>> > RFC. So I, and I suspect a lot of others, simply go with the flow and use
>> > whatever we're told we have to use. If this is problematic for you, the place
>> > to take that up is on the IPR WG list. It is not within our charter here to
>> > consider such matters in any case.
>
>> does the IEFT require copyright assignment?
>
> Yes, there's a thing called the IETF Trust that rights are assigned to.

copyright assignment should be unnecessary unless the IEFT intends to
sue (which IMO would not be a positive development)

> In fact they're going even further and asking for people to sign an agreement
> granting rights to stuff in old RFCs published before copyright assignment
> was required. It isn't clear to me how this can handle stuff like the
> RFCs I've written with, say. Jon Postel (sadly deceased) as the coauthor, but
> again, IANAL and I really try to stay as far away from this as possible.

does the IEFT plan to grant back an unlimited exploitation license to
the original authors?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHC5dfV076382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 05:05:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBHC5dI2076381; Wed, 17 Dec 2008 05:05:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHC5b8S076373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 17 Dec 2008 05:05:38 -0700 (MST) (envelope-from [e-mail])
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 46B0221042; Wed, 17 Dec 2008 13:05:37 +0100 (CET)
X-AuditID: c1b4fb3c-ad75dbb00000304c-60-4948eb11da65
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2E48520FDE; Wed, 17 Dec 2008 13:05:37 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 13:05:27 +0100
Received: from [147.214.183.72] ([147.214.183.72]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 13:05:27 +0100
Message-ID: <[e-mail]>
Date: Wed, 17 Dec 2008 13:05:27 +0100
From: Magnus Westerlund <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Dave Cridland <[e-mail]>
CC: [e-mail]
Subject: Re: ABNF or example error in RFC 5228
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 17 Dec 2008 12:05:27.0155 (UTC) FILETIME=[BFA9C430:01C9603F]
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland skrev:
> On Wed Dec 17 11:18:26 2008, Dave Cridland wrote:
>> On Wed Dec 17 10:33:38 2008, Magnus Westerlund wrote:
>>> Section 3.2 for example contains the following example:
>>>
>>>    Example:  require ["fileinto", "reject"];
>>>
>>> However if one looks at the ABNF for string-list it says:
>>>
>>>    string-list  = "[" string *("," string) "]" / string
>>>                     ; if there is only a single string, the brackets
>>>                     ; are optional
>>
>> Are you referring to the "," instead of "," *WSP which is actually  used?
>>
>> If so, then yes, there's a minor error, which could be put as an 
>> erratum.
> 
> Actually, no, there isn't an error there.
> 
> Section 8.2, from which the above ABNF fragment is extracted, begins "No
> whitespace or comments appear below."
> 
> Section 8.1 says "[whitespace characters] are ignored except as they
> separate tokens."

Okay, the whitespacing was exactly what I saw was the problem as I
didn't see that comment. Implicit whitespacing is in my personal opinion
problematic, but that has no impact on the issue I raised. So apparently
no real issue.

Sorry for taking up your time.

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHBUA1O072456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 04:30:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBHBU9fF072454; Wed, 17 Dec 2008 04:30:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHBU8lh072447 for <[e-mail]>; Wed, 17 Dec 2008 04:30:09 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Wed, 17 Dec 2008 11:30:02 +0000
Subject: Re: ABNF or example error in RFC 5228
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 17 Dec 2008 11:30:01 +0000
From: Dave Cridland <[e-mail]>
To: Magnus Westerlund <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed Dec 17 11:18:26 2008, Dave Cridland wrote:
> On Wed Dec 17 10:33:38 2008, Magnus Westerlund wrote:
>> Section 3.2 for example contains the following example:
>> 
>>    Example:  require ["fileinto", "reject"];
>> 
>> However if one looks at the ABNF for string-list it says:
>> 
>>    string-list  = "[" string *("," string) "]" / string
>>                     ; if there is only a single string, the  
>> brackets
>>                     ; are optional
> 
> Are you referring to the "," instead of "," *WSP which is actually   
> used?
> 
> If so, then yes, there's a minor error, which could be put as an   
> erratum.

Actually, no, there isn't an error there.

Section 8.2, from which the above ABNF fragment is extracted, begins  
"No whitespace or comments appear below."

Section 8.1 says "[whitespace characters] are ignored except as they  
separate tokens."

So I was talking rubbish, sorry.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHBIi7A071607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 04:18:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBHBIi48071606; Wed, 17 Dec 2008 04:18:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHBIWwL071593 for <[e-mail]>; Wed, 17 Dec 2008 04:18:43 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Wed, 17 Dec 2008 11:18:27 +0000
Subject: Re: ABNF or example error in RFC 5228
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 17 Dec 2008 11:18:26 +0000
From: Dave Cridland <[e-mail]>
To: Magnus Westerlund <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed Dec 17 10:33:38 2008, Magnus Westerlund wrote:
> Section 3.2 for example contains the following example:
> 
>    Example:  require ["fileinto", "reject"];
> 
> However if one looks at the ABNF for string-list it says:
> 
>    string-list  = "[" string *("," string) "]" / string
>                     ; if there is only a single string, the brackets
>                     ; are optional

Are you referring to the "," instead of "," *WSP which is actually  
used?

If so, then yes, there's a minor error, which could be put as an  
erratum.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHAwvop069920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 03:58:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBHAwvCP069919; Wed, 17 Dec 2008 03:58:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout3.freenet.de (mout3.freenet.de [195.4.92.93]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHAwj2F069906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 17 Dec 2008 03:58:57 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout3.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #73) id 1LCu72-0007Lg-Dd; Wed, 17 Dec 2008 11:58:44 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:39558) by 11.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #73) id 1LCu72-00052R-BG; Wed, 17 Dec 2008 11:58:44 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #73) id 1LCu70-0003bD-PA; Wed, 17 Dec 2008 11:58:42 +0100
Date: Wed, 17 Dec 2008 11:58:42 +0100
To: [e-mail], [e-mail]
Subject: Re: ABNF or example error in RFC 5228
References: <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Could you elaborate where exactly the examples fail to be a word of
the grammar?

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHAvKg1069827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 03:57:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBHAvKwH069826; Wed, 17 Dec 2008 03:57:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHAv9av069802 for <[e-mail]>; Wed, 17 Dec 2008 03:57:19 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.130] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 17 Dec 2008 10:57:07 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Dec 2008 10:56:45 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Magnus Westerlund <[e-mail]>
CC: [e-mail]
Subject: Re: ABNF or example error in RFC 5228
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Magnus Westerlund wrote:

>Hi,
>  
>
Hi Magnus,

>When reviewing the ihave document I stumbled on what I believe to be a
>bug in RFC 5228 regarding string list:
>
>2.4.2.1.  String Lists
>
>   When matching patterns, it is frequently convenient to match against
>   groups of strings instead of single strings.  For this reason, a list
>   of strings is allowed in many tests, implying that if the test is
>   true using any one of the strings, then the test is true.
>
>   For instance, the test 'header :contains ["To", "Cc"]
>   ["[e-mail]", "[e-mail]"]' is true if either a To
>   header or Cc header of the input message contains either of the email
>   addresses "[e-mail]" or "[e-mail]".
>
>   Conversely, in any case where a list of strings is appropriate, a
>   single string is allowed without being a member of a list: it is
>   equivalent to a list with a single member.  This means that the test
>   'exists "To"' is equivalent to the test 'exists ["To"]'.
>
>
>Section 3.2 for example contains the following example:
>
>   Example:  require ["fileinto", "reject"];
>
>However if one looks at the ABNF for string-list it says:
>
>   string-list  = "[" string *("," string) "]" / string
>                    ; if there is only a single string, the brackets
>                    ; are optional
>
>   string       = quoted-string / multi-line
>   quoted-string      = DQUOTE quoted-text DQUOTE
>   multi-line         = "text:" *(SP / HTAB) (hash-comment / CRLF)
>                        *(multiline-literal / multiline-dotstart)
>                        "." CRLF
>  
>
I am looking at the ABNF and not seeing anything wrong. Maybe I was 
looking for too long at this.
So can you elaborate on what you think is wrong?

>So it seems that the description, the examples of string lists doesn't
>match the ABNF syntax for string lists. If I am correct, I think the WG
>needs to address this somehow.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHAZFJ4068529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 03:35:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBHAZFhb068528; Wed, 17 Dec 2008 03:35:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBHAZ27k068518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 17 Dec 2008 03:35:14 -0700 (MST) (envelope-from [e-mail])
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 89F6720C79 for <[e-mail]>; Wed, 17 Dec 2008 11:35:01 +0100 (CET)
X-AuditID: c1b4fb3c-aaf58bb00000304c-1e-4948d5d546ec
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7360920C78 for <[e-mail]>; Wed, 17 Dec 2008 11:35:01 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 11:33:39 +0100
Received: from [147.214.183.72] ([147.214.183.72]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 11:33:38 +0100
Message-ID: <[e-mail]>
Date: Wed, 17 Dec 2008 11:33:38 +0100
From: Magnus Westerlund <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [e-mail]
Subject: ABNF or example error in RFC 5228
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 17 Dec 2008 10:33:38.0981 (UTC) FILETIME=[EC891D50:01C96032]
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

When reviewing the ihave document I stumbled on what I believe to be a
bug in RFC 5228 regarding string list:

2.4.2.1.  String Lists

   When matching patterns, it is frequently convenient to match against
   groups of strings instead of single strings.  For this reason, a list
   of strings is allowed in many tests, implying that if the test is
   true using any one of the strings, then the test is true.

   For instance, the test 'header :contains ["To", "Cc"]
   ["[e-mail]", "[e-mail]"]' is true if either a To
   header or Cc header of the input message contains either of the email
   addresses "[e-mail]" or "[e-mail]".

   Conversely, in any case where a list of strings is appropriate, a
   single string is allowed without being a member of a list: it is
   equivalent to a list with a single member.  This means that the test
   'exists "To"' is equivalent to the test 'exists ["To"]'.


Section 3.2 for example contains the following example:

   Example:  require ["fileinto", "reject"];

However if one looks at the ABNF for string-list it says:

   string-list  = "[" string *("," string) "]" / string
                    ; if there is only a single string, the brackets
                    ; are optional

   string       = quoted-string / multi-line
   quoted-string      = DQUOTE quoted-text DQUOTE
   multi-line         = "text:" *(SP / HTAB) (hash-comment / CRLF)
                        *(multiline-literal / multiline-dotstart)
                        "." CRLF


So it seems that the description, the examples of string lists doesn't
match the ABNF syntax for string lists. If I am correct, I think the WG
needs to address this somehow.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGGq5JO013021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 09:52:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGGq5V0013020; Tue, 16 Dec 2008 09:52:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGGq4pc013014 for <[e-mail]>; Tue, 16 Dec 2008 09:52:05 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 610433A6A9E; Tue, 16 Dec 2008 08:52:11 -0800 (PST)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-sieve-managesieve (A Protocol for  Remotely Managing Sieve Scripts) to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 16 Dec 2008 08:52:11 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Sieve Mail Filtering Language 
WG (sieve) to consider the following document:

- 'A Protocol for Remotely Managing Sieve Scripts '
   <draft-ietf-sieve-managesieve-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2008-12-30. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17794&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFEuqZ007090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 08:14:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGFEuQp007089; Tue, 16 Dec 2008 08:14:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFEt3t007083 for <[e-mail]>; Tue, 16 Dec 2008 08:14:56 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 1FAEB3A6A8A; Tue, 16 Dec 2008 07:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-05.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 16 Dec 2008 07:15:02 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-05.txt
	Pages           : 49
	Date            : 2008-12-16

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-managesieve-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGD1kST099234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 06:01:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGD1kgA099233; Tue, 16 Dec 2008 06:01:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGD1ZdZ099222 for <[e-mail]>; Tue, 16 Dec 2008 06:01:46 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 16 Dec 2008 13:01:34 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2008 13:01:10 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: sieve mailing list <[e-mail]>
Subject: Re: Protocol Action: 'Sieve Notification Mechanism: mailto' to Proposed Standard
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG wrote:

>The IESG has approved the following document:
>
>- 'Sieve Notification Mechanism: mailto '
>   <draft-ietf-sieve-notify-mailto-10.txt> as a Proposed Standard
>
>This document is the product of the Sieve Mail Filtering Language Working 
>Group. 
>
>The IESG contact persons are Lisa Dusseault and Chris Newman.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-10.txt
>  
>
Hooooraaaa!



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBG9RH52085498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 02:27:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBG9RHm8085497; Tue, 16 Dec 2008 02:27:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBG9R5n1085486 for <[e-mail]>; Tue, 16 Dec 2008 02:27:16 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.241.64] (92.40.241.64.sub.mbb.three.co.uk [92.40.241.64])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 16 Dec 2008 09:27:03 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2008 09:26:35 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail], Lisa Dusseault <[e-mail]>, Lisa Dusseault <[e-mail]>
Subject: Re: ManageSIEVE review: conflating two functions
References: <[e-mail]> <[e-mail]> <C9QunEKX/[e-mail]>
In-Reply-To: <C9QunEKX/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> Lisa Dusseault writes:
>
>> Ok, so there's already CHECKSCRIPT, which leaves me even more 
>> clueless  why ADDSCRIPT would be defined to operate differently while 
>> anonymous,  rather than just be disabled.
>
> Catering to old clients.

I think several servers/clients try to use PUTSCRIPT "". I am not 
convinced that anybody is using ANONYMOUS for the same purpose. So I 
don't feel bad about removing the ANONYMOUS verification mode.

> Ordinarily I'm all in favour of catering to old clients, but in this 
> case I think they need a dose of upgradation to fix the + bug anyway.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBG8MHwj082874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 01:22:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBG8MHnF082873; Tue, 16 Dec 2008 01:22:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBG8M5tW082857 for <[e-mail]>; Tue, 16 Dec 2008 01:22:16 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 8096E4AC1B; Tue, 16 Dec 2008 09:22:04 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1229415724-1366-1/6/17 (4 recipients); Tue, 16 Dec 2008 09:22:04 +0100
Message-Id: <C9QunEKX/[e-mail]>
Date: Tue, 16 Dec 2008 09:21:42 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: ManageSIEVE review: conflating two functions
Cc: Lisa Dusseault <[e-mail]>, Lisa Dusseault <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lisa Dusseault writes:
> Ok, so there's already CHECKSCRIPT, which leaves me even more clueless 
>  why ADDSCRIPT would be defined to operate differently while 
> anonymous,  rather than just be disabled.

Catering to old clients.

Ordinarily I'm all in favour of catering to old clients, but in this 
case I think they need a dose of upgradation to fix the + bug anyway.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBG412OD072459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 21:01:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBG412sZ072458; Mon, 15 Dec 2008 21:01:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBG40oN1072432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 15 Dec 2008 21:01:01 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBG40jjq002532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 23:00:46 -0500 (EST)
Date: Mon, 15 Dec 2008 23:00:44 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Lisa Dusseault <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: ManageSIEVE review: conflating two functions
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, December 15, 2008 11:44:19 AM -0800 Lisa Dusseault 
<[e-mail]> wrote:

>
>
> Anonymous mode:
>
>     Implementations MAY advertise the ANONYMOUS SASL mechanism
>     [SASL-ANON].  This indicates that the server supports ANONYMOUS SIEVE
>     script syntax verification.  Only the CAPABILITY, PUTSCRIPT and
>     LOGOUT commands are available to the anonymous user.  All other
>     commands defined in the base ManageSieve protocol MUST give NO
>     responses, however ManageSieve extensions MAY allow other commands in
>     the ANONYMOUS Sieve script verification mode.  Furthermore the
>     PUTSCRIPT command MUST NOT persistently store any data.  In this mode
>     a positive response to the PUTSCRIPT command indicates that the given
>     script does not have any syntax errors.
>
> This conflates two things (which is generally bad for extensibility):
> anonymous authentication, with script syntax verification.  It would be
> better not to conflate these things...

Uh, wow.  That's.... special.
Yeah, let's not do that.


-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFNxt8Z059880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 16:59:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFNxtAH059879; Mon, 15 Dec 2008 16:59:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFNxsUH059873 for <[e-mail]>; Mon, 15 Dec 2008 16:59:54 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 47A513A69E6; Mon, 15 Dec 2008 16:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-04.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 15 Dec 2008 16:00:01 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-04.txt
	Pages           : 49
	Date            : 2008-12-15

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-managesieve-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFNVOJA058834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 16:31:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFNVOaW058833; Mon, 15 Dec 2008 16:31:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFNVM6K058826 for <[e-mail]>; Mon, 15 Dec 2008 16:31:22 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 3B4F73A6A1C; Mon, 15 Dec 2008 15:31:29 -0800 (PST)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, sieve mailing list <[e-mail]>, sieve chair <[e-mail]>
Subject: Protocol Action: 'Sieve Notification Mechanism: mailto'  to Proposed Standard 
Message-Id: <[e-mail]>
Date: Mon, 15 Dec 2008 15:31:29 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Sieve Notification Mechanism: mailto '
   <draft-ietf-sieve-notify-mailto-10.txt> as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working 
Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

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



Technical Summary

The SIEVE notify-mailto extension defines how to use a mailto URI 
with the SIEVE notify extension to generate email notifications in 
response to incoming email matching specified SIEVE criteria.

The security considerations section covers several identified security
concerns.

Working Group Summary

This document has been discussed and reviewed in the SIEVE Working Group.
There is strong consensus in the Working Group to publish this document
as a Proposed Standard.

Document Quality

Several implementers have indicated they will implement this extension.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFLqBgs054487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 14:52:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFLqBeZ054486; Mon, 15 Dec 2008 14:52:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFLqAvB054479 for <[e-mail]>; Mon, 15 Dec 2008 14:52:10 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.41.175] (92.40.41.175.sub.mbb.three.co.uk [92.40.41.175])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 15 Dec 2008 21:52:09 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 21:51:27 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Lisa Dusseault <[e-mail]>
CC: Lisa Dusseault <[e-mail]>, [e-mail]
Subject: Re: ManageSIEVE review: conflating two functions
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Lisa Dusseault wrote:
>
>> Ok, so there's already CHECKSCRIPT, which leaves me even more 
>> clueless  why ADDSCRIPT would be defined to operate differently while 
>> anonymous,  rather than just be disabled.
>
> I probably need to add a bit of history on this:
>
> Originally the document allowed a client to verify a script by 
> specifying the empty script name in the PUTSCRIPT command. This was a 
> bit of a hack.
> Then somebody suggested to use SASL ANONYMOUS authentication, which is 
> a special authentication mechanism that tells the server that the user 
> is effectively unauthenticated.
> Then Stephan pointed out that some sysadmins wouldn't want to just let 
> any client to use their ManageSieve server for script verification (by 
> allowing SASL ANONYMOUS), but would like to allow authenticated users 
> to do script verfication. After some discussion with the WG the new 
> CHECKSCRIPT command was added.
>
> But anyway, now that you've mentioned this, I think there is no point 
> in having script verification through ANONYMOUS. So I suggest deleting 
> it.

And I've just found the following comment in my XML source (just before 
the paragraph):

<!--cref: Should this paragraph be deleted?-->



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFLoiNg054437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 14:50:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFLoiim054436; Mon, 15 Dec 2008 14:50:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFLoX3v054427 for <[e-mail]>; Mon, 15 Dec 2008 14:50:43 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.41.175] (92.40.41.175.sub.mbb.three.co.uk [92.40.41.175])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 15 Dec 2008 21:50:29 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 21:49:50 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Lisa Dusseault <[e-mail]>
CC: Lisa Dusseault <[e-mail]>, [e-mail]
Subject: Re: ManageSIEVE review: conflating two functions
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lisa Dusseault wrote:

> Ok, so there's already CHECKSCRIPT, which leaves me even more 
> clueless  why ADDSCRIPT would be defined to operate differently while 
> anonymous,  rather than just be disabled.

I probably need to add a bit of history on this:

Originally the document allowed a client to verify a script by 
specifying the empty script name in the PUTSCRIPT command. This was a 
bit of a hack.
Then somebody suggested to use SASL ANONYMOUS authentication, which is a 
special authentication mechanism that tells the server that the user is 
effectively unauthenticated.
Then Stephan pointed out that some sysadmins wouldn't want to just let 
any client to use their ManageSieve server for script verification (by 
allowing SASL ANONYMOUS), but would like to allow authenticated users to 
do script verfication. After some discussion with the WG the new 
CHECKSCRIPT command was added.

But anyway, now that you've mentioned this, I think there is no point in 
having script verification through ANONYMOUS. So I suggest deleting it.

> Lisa
>
> On Dec 15, 2008, at 11:44 AM, Lisa Dusseault wrote:
>
>> Anonymous mode:
>>
>>   Implementations MAY advertise the ANONYMOUS SASL mechanism
>>   [SASL-ANON].  This indicates that the server supports ANONYMOUS  SIEVE
>>   script syntax verification.  Only the CAPABILITY, PUTSCRIPT and
>>   LOGOUT commands are available to the anonymous user.  All other
>>   commands defined in the base ManageSieve protocol MUST give NO
>>   responses, however ManageSieve extensions MAY allow other commands  in
>>   the ANONYMOUS Sieve script verification mode.  Furthermore the
>>   PUTSCRIPT command MUST NOT persistently store any data.  In this  mode
>>   a positive response to the PUTSCRIPT command indicates that the  given
>>   script does not have any syntax errors.
>>
>> This conflates two things (which is generally bad for  
>> extensibility):  anonymous authentication, with script syntax  
>> verification.  It would be better not to conflate these things, in  
>> case there is ever any other purpose to anonymous mode, or any need  
>> for script syntax verification while authenticated.  How about a  
>> TRYSCRIPT method that acts as PUTSCRIPT but never stores the  
>> script?  Then the anonymous mode can be defined, in this version of  
>> managesieve, as allowing TRYSCRIPT but not PUTSCRIPT.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFK2nAN049422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 13:02:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFK2nZ1049421; Mon, 15 Dec 2008 13:02:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFK2mSf049415 for <[e-mail]>; Mon, 15 Dec 2008 13:02:48 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 271AF77D6FE; Mon, 15 Dec 2008 12:02:48 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J+q8GuJ2dAm; Mon, 15 Dec 2008 12:02:47 -0800 (PST)
Received: from [192.168.1.102] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id A9B9E77D6FD; Mon, 15 Dec 2008 12:02:47 -0800 (PST)
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Lisa Dusseault <[e-mail]>
To: Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: ManageSIEVE review: conflating two functions
Date: Mon, 15 Dec 2008 12:02:47 -0800
References: <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ok, so there's already CHECKSCRIPT, which leaves me even more clueless  
why ADDSCRIPT would be defined to operate differently while anonymous,  
rather than just be disabled.

Lisa

On Dec 15, 2008, at 11:44 AM, Lisa Dusseault wrote:

>
> Anonymous mode:
>
>   Implementations MAY advertise the ANONYMOUS SASL mechanism
>   [SASL-ANON].  This indicates that the server supports ANONYMOUS  
> SIEVE
>   script syntax verification.  Only the CAPABILITY, PUTSCRIPT and
>   LOGOUT commands are available to the anonymous user.  All other
>   commands defined in the base ManageSieve protocol MUST give NO
>   responses, however ManageSieve extensions MAY allow other commands  
> in
>   the ANONYMOUS Sieve script verification mode.  Furthermore the
>   PUTSCRIPT command MUST NOT persistently store any data.  In this  
> mode
>   a positive response to the PUTSCRIPT command indicates that the  
> given
>   script does not have any syntax errors.
>
> This conflates two things (which is generally bad for  
> extensibility):  anonymous authentication, with script syntax  
> verification.  It would be better not to conflate these things, in  
> case there is ever any other purpose to anonymous mode, or any need  
> for script syntax verification while authenticated.  How about a  
> TRYSCRIPT method that acts as PUTSCRIPT but never stores the  
> script?  Then the anonymous mode can be defined, in this version of  
> managesieve, as allowing TRYSCRIPT but not PUTSCRIPT.
>
>
> Lisa



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFJiv8D048617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 12:44:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFJivgw048616; Mon, 15 Dec 2008 12:44:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFJikwc048600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 15 Dec 2008 12:44:57 -0700 (MST) (envelope-from [e-mail])
Received: from gateout02 (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id 8D8033D806F for <[e-mail]>; Mon, 15 Dec 2008 19:44:45 +0000 (GMT)
Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02 via smtad (C8.MAIN.3.45U)  with ESMTP id XID914mLoTSt2522Xo2; Mon, 15 Dec 2008 19:44:45 -0000
X-USANET-Source: 165.212.116.254 IN   [e-mail] GW1.EXCHPROD.USA.NET
X-USANET-MsgId: XID914mLoTSt2522Xo2
Received: from [192.168.1.102] ([74.95.2.169]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 12:44:20 -0700
Message-Id: <[e-mail]>
From: Lisa Dusseault <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: ManageSIEVE review: conflating two functions
Date: Mon, 15 Dec 2008 11:44:19 -0800
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 15 Dec 2008 19:44:21.0164 (UTC) FILETIME=[86629EC0:01C95EED]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anonymous mode:

    Implementations MAY advertise the ANONYMOUS SASL mechanism
    [SASL-ANON].  This indicates that the server supports ANONYMOUS  
SIEVE
    script syntax verification.  Only the CAPABILITY, PUTSCRIPT and
    LOGOUT commands are available to the anonymous user.  All other
    commands defined in the base ManageSieve protocol MUST give NO
    responses, however ManageSieve extensions MAY allow other commands  
in
    the ANONYMOUS Sieve script verification mode.  Furthermore the
    PUTSCRIPT command MUST NOT persistently store any data.  In this  
mode
    a positive response to the PUTSCRIPT command indicates that the  
given
    script does not have any syntax errors.

This conflates two things (which is generally bad for extensibility):   
anonymous authentication, with script syntax verification.  It would  
be better not to conflate these things, in case there is ever any  
other purpose to anonymous mode, or any need for script syntax  
verification while authenticated.  How about a TRYSCRIPT method that  
acts as PUTSCRIPT but never stores the script?  Then the anonymous  
mode can be defined, in this version of managesieve, as allowing  
TRYSCRIPT but not PUTSCRIPT.


Lisa



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFIZK9K044366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 11:35:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFIZKdQ044365; Mon, 15 Dec 2008 11:35:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFIZ9tm044348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 15 Dec 2008 11:35:19 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBFIZ3nD013977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 13:35:04 -0500 (EST)
Date: Mon, 15 Dec 2008 13:35:03 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Ned Freed <[e-mail]>, Robert Burrell Donkin <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, [e-mail], [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Sunday, December 14, 2008 08:04:46 PM -0800 Ned Freed 
<[e-mail]> wrote:

>> does the IEFT require copyright assignment?
>
> Yes, there's a thing called the IETF Trust that rights are assigned to.

Actually, no, though this is a common misconception.
Our process requires that you grant (license) certain rights to the IETF 
Trust, many including the right to sublicense.  However, unlike some other 
SDO's, we do _not_ require assignment of copyright; the copyright on an 
IETF document remains with the original author(s).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFHZN0p041355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 10:35:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFHZNMk041354; Mon, 15 Dec 2008 10:35:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFHZCJm041343 for <[e-mail]>; Mon, 15 Dec 2008 10:35:22 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 15 Dec 2008 09:34:46 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 15 Dec 2008 09:34:43 -0800 (PST)
Date: Mon, 15 Dec 2008 09:18:48 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Mon, 15 Dec 2008 11:03:47 +0100" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Robert Burrell Donkin <[e-mail]>, Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ned Freed writes:
> >>  is there a compliance test suite?
> >
> > Not as far as I know.

> I wrote the guts of something like that after Prague IETF, where there
> was a discussion about advancing sieve to draft. I stopped working on
> it that when various people didn't reply to email about it (I did not
> feel up to a one-man crusade), but people seem to care more now and
> I'll return to it when one of my current drafts passes IESG.

> > I certainly have no plans to write one or subject our implementation
> > to any that someone else develops. I doubt if anyone else does
> > either.

> And I do hope you will review the document and run the code.

Not if it's labelled as a compliance test. Again, I have no objections to unit
tests or sample scripts and use them all the time.

Compliance tests are another matter entirely. I realize evenyone has nothing
but the best intentions here, but you know what's paved with those...

If we release something we call a compliance suite it would be terribly easy
for someone to take advantage of all that nice new copyright boilerplate that
allows unrestricted use and take the code and turn it into a for-profit
compliance test. It's but one step from there to RFPs requiring passage
of that test.

Really, you cannot know just how radioactive these things can be until you've
gone through a bunch of them. You may think that such tests are amenable to a
bright line standard of pass/fail, but that's just not how it ever ends up.
There's always interpretation of results involved, especially when  you're
probing for implementation limits (which these things always seem to do), and
that leads to, um, let's call them "discussions" between the implementor and
tester.

I'm going to refrain from giving specific examples because to be blunt I'd
rather not open that particular folder of old mail and have to remember the
details of what transpired.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFHRLGh040965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 10:27:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFHRLfA040964; Mon, 15 Dec 2008 10:27:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFHR9gt040950 for <[e-mail]>; Mon, 15 Dec 2008 10:27:20 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.192] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 15 Dec 2008 17:27:08 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 17:26:21 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Re: draft-freed-sieve-in-xml status?]
Content-Type: multipart/mixed; boundary="------------070607050500080605020409"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------070607050500080605020409
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Forwarding to the mailing list with Ned's permission.


--------------070607050500080605020409
Content-Type: message/rfc822;
 name="Re: draft-freed-sieve-in-xml status?"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: draft-freed-sieve-in-xml status?"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.3v2) with LMTP; Mon, 15 Dec 2008 16:57:48 +0000 (GMT)
Received: from [172.16.2.192] (shiny.isode.com [62.3.217.250]) 
          by rufus.isode.com (submission channel) via TCP with ESMTPA 
          id <[e-mail]>; Mon, 15 Dec 2008 16:57:47 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 16:57:05 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
            Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
References: <[e-mail]>
            <[e-mail]>
            <[e-mail]>
            <[e-mail]>
            <[e-mail]>
            <[e-mail]>
            <[e-mail]>
            <[e-mail]>
            <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ned Freed wrote:

>
>> Can we just standardize a namespace URI (but don't require use of
>> namespaces) and be done with this issue?
>
>
> I have no objection as long as we don't clutter up the examples with 
> it. RFC
> 3470 has this to say about namespace usage in RFCs:
>
>  In the case of namespaces in IETF standards-track documents, it would be
>  useful if there were some permanent part of the IETF's own web space 
> that
>  could be used for this purpose. In lieu of such, other permanent URIs 
> can
>  be used, e.g., URNs in the IETF URN namespace (see [11] and [12]). 
> Although
>  there are instances of IETF specifications creating new URI schemes to
>  define XML namespaces, this practice is strongly discouraged.
>
> RFC 3688 then created the necessary allocation and an associated 
> registry:
>
>  ns -- XML Namespaces [W3C.REC-xml-names] are named by a URI. They 
> have no
>  real, machine-parseable representation. Thus, the registered document 
> will be
>  either the specification or a reference to it. In the case where a 
> URI is not
>  provided by the registrant, the IANA will assign a URN of the form
>  'urn:ietf:params:xml:ns:<id> which will be the XML Namespace's name.
>
> It is also expected that schemata will be registered. However, since 
> we're
> about to switch to Relax NG and AFAICT the schema registry is for
> XML Schema language stuff only, this won't apply to us as of the next
> revision. So we'll end up with an IANA Considerations section like the
> following:
>
> 7.  IANA Considerations
>
>   This section registers a new XML namespace per the procedures in RFC
>   3688 [RFC3688].
>
> URI:  urn:ietf:params:xml:ns:sieve
>
> Registrant Contact:  IETF Sieve working group <[e-mail]>
>
> XML:
>
>  BEGIN
>  <?xml version="1.0"?>
>  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
>    "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
>  <html xmlns="http://www.w3.org/1999/xhtml">
>  <head>
>    <meta http-equiv="content-type"
>          content="text/html;charset=iso-8859-1"/>
>    <title>Sieve Namespace</title>
>  </head>
>  <body>
>    <h1>Namespace for Sieve Language objects expressed in XML</h1>
>    <h2>urn:ietf:params:xml:ns:sieve</h2>
>    <p>See <a href="http://www.rfc-editor.org/rfc/rfc5361.txt">
>    RFC 5361</a>.
>    </p>
>  </body>
>  </html>
>  END
>
> Unless there are objections I'll include this in the next draft.

This looks good to me. Thanks!

BTW, my reply was directly to you. However I think your reply should go 
to the mailing list. Can you either forward your reply to the mailing 
list or can I do that?


--------------070607050500080605020409--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFDxk82029856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 06:59:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFDxksD029855; Mon, 15 Dec 2008 06:59:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFDxZKD029843 for <[e-mail]>; Mon, 15 Dec 2008 06:59:45 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id BCC1D4AC99; Mon, 15 Dec 2008 14:59:34 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1229349574-1366-1/6/3 for [e-mail]; Mon, 15 Dec 2008 14:59:34 +0100
Message-Id: <[e-mail]>
Date: Mon, 15 Dec 2008 14:59:10 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> I stopped working on it that when various people didn't reply to 
>> email about it (I did not feel up to a one-man crusade),
>
> Sorry for that. I think this is important, but I had too many other 
> things I needed to finish at the time.

No problem. IMO any single person doesn't make much of a difference anyway.

Water under the bridge now. You'll see a draft sometime, probably not 
this year since I've only four working days left..

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFDQ3NC028224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 06:26:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFDQ3R0028223; Mon, 15 Dec 2008 06:26:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFDPnpp028211 for <[e-mail]>; Mon, 15 Dec 2008 06:26:01 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 15 Dec 2008 13:25:48 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 13:25:18 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> Ned Freed writes:
>
>>>  is there a compliance test suite?
>>
>> Not as far as I know.
>
> I wrote the guts of something like that after Prague IETF, where there 
> was a discussion about advancing sieve to draft. I stopped working on 
> it that when various people didn't reply to email about it (I did not 
> feel up to a one-man crusade),

Sorry for that. I think this is important, but I had too many other 
things I needed to finish at the time.

> but people seem to care more now and I'll return to it when one of my 
> current drafts passes IESG.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFD3SJt026896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 06:03:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFD3SUL026895; Mon, 15 Dec 2008 06:03:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFD3EGX026879 for <[e-mail]>; Mon, 15 Dec 2008 06:03:26 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so4675117bwz.10 for <[e-mail]>; Mon, 15 Dec 2008 05:03:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+wlqCp4EsJ/zgNrC+cNvE8MDog2CjSuK+uES3jSnka4=; b=JY7Oje6Ypz9e89mC1kAehmvLu9xFLMsSM9VdyUwqb9cE0V1A60XuHPUGiK6xXQUAwm XDymcHwrnLOIRDI+XQu8uidzlAmCcP21o/64j5ohg2Dttl9PLpNvT9RT0Nm+Lb9F22qA ewU924AJ+gg1O+WEXtt68709TADtKDXrqMzsA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=W8xITXaAOOEO7xMUx2DoG+mokMwMkltfFJplrZolu6eQOgNLNWdczH2AySuoq7zDa8 cG4NLyQ3/zPEquSyMG9aajIXPCucCDHZp5BI0BN95lkj9HXmDoDOs08kYR09RNh3W1H/ DnUKdqzgId0cf3rAIYB3Ykf2puMK6wjv/817s=
Received: by 10.181.199.16 with SMTP id b16mr2525369bkq.142.1229346012537; Mon, 15 Dec 2008 05:00:12 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Mon, 15 Dec 2008 05:00:12 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 13:00:12 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Dec 14, 2008 at 9:59 PM, Ned Freed <[e-mail]> wrote:
>> On Sun, Dec 14, 2008 at 6:06 PM, Ned Freed <[e-mail]> wrote:
>> >> i note that the draft describes the infoset rather than defining it in
>> >> the standard way. is there a reason for this decision?
>> >
>> > I don't know what "the standard way" is you're referring to. Perhaps you
>> > could provide a reference to an RFC where this has been used?
>
>> AIUI XML is maintained by w3c (rather than IEFT) so is a
>> recommendation. http://www.w3.org/TR/xml-infoset/ is the current
>> document.
>
> Quite true, however, the IETF has its own specification for XML is supposed to
> be used in RFCs: RFC 3470. And while infosets are mentioned as one approach to
> specifying things about an XML format, there's no recommendation, let alone
> requirement, that they be used.
>
>> > This document is a little unusual in that it's defining a mapping of, if you
>> > will, a non-XML infoset onto XML. As such, the natural approach seemed to be to
>> > first discuss the structure of the language being mapped, then explain the
>> > mapping, and finish up with additional unique-to-XML semantics.
>
>> i agree that most of this arangement is natural. it's just jumping to
>> a schema seems - to me - a little premature and inflexible.
>
> First of all, the use of XML Schema is in fact too inflexible to be allowed
> to continue. The next revision will use Relax instead.

XML schema is flexible but the flexibility comes at the price of
readability. one of relax variants would be a better choice.

however (in my experience) the generative tools commonly used for XML
and web service binding, and editor generation tend not to offer good
relax support. IMO the draft should offer secondary informative XML
Schema or Schemata to assist developers using these tools.

> But I'm sitll a little confused as to what you're asking for here. If you're
> asking for removal of the explicit inline XML syntax examples in favor of a
> more abstract approach, I'd be fine with that if there's a WG consensus to make
> such a change.

no - i'm very happy with the syntax examples

i would like to see the approach used in RFC 5023 (and others)
adopted, adding a normative description of the XML and making the
schema only informative.

> Beyond that, however, lies a slippery slope. If what you're after is a
> restatement of Sieve elements and semantics in infoset form, that is not going
> to happen on my watch. RFC 5228 is the definitive source of information about
> such things. It may be a little awkward for implementors to have to interpolate
> back through the specifications to get at the meaning of things they have in
> their XML, but the alternative of having two separate specifications that are
> bound to be inconsistent in some way or other is much worse.

no, not restatement

>> > This approach is perhaps not the best choice for someone coming at this trying
>> > to get at Sieve semantics starting with XML, but I believe consumers of the
>> > document with that mindset will be distinctly in the minority. The main focus
>> > here is to provide people familiar with Sieve a means of mapping Sieve to XML
>> > so that XML tools can be applied.
>
>> my experience is entirely opposite
>
>> developers that use the java libraries i work on have good XML but
>> lack a good understanding of underlying mail technologies (for example
>> sieve). there is a large and growing requirement for integration
>> between mail and enterprise systems (typically coding in Java and .NET
>> but also ruby and python). developers from enterprise backgrounds are
>> typically strong on web+xml but very weak on mail.
>
> Yep, I've seen a lot of this as well. And the problem emcompasses far more than
> Sieve: For example, a lot of people who are unfamiliar with email don't
> understand very basic concepts such as the separation between envelope and
> message content. (This particular issue actually pokes through into Sieve in
> the form of whether an envelope or header test is appropriate.)

i beg to differ slightly on this one

some enterprise mail processing may happen during the SMTP transaction
but it is more typical for the mail processing after storage. not all
mail stored arrives through SMTP and so it is typical for any envelope
information to be reduced to simple MIME headers. most developers in
these mail processing environments do not need to understand the
difference between envelope and message content because - for them -
there is no difference.

Sieve works very well as a general MIME document processing language.
the envelope tests are - in many ways - peculiar since the rest of the
specification really isn't mail specific. there are potentially some
very interesting applications in this area so it would be a shame - i
think - for the expert group to focus too strongly on SMTP at the
expense of other IMHO equally valid Sieve use cases.

> But here's the dilemma: This stuff is complicated and in some cases fairly
> subtle. This in turn means that the reiteration of even a subset of the
> underlying design principles that implementors need to know takes up a lot of
> space and will still fall short of the mark of giving the necessary guidance.
> But it may lead to the belief that reading this specification (or for that
> matter this one and RFC 5228) is in fact sufficient to understand how to use
> Sieve. It quite simply isn't.

again, i beg to differ

sieve is very similar structurally to the guerrilla standards used in
enterprise mail system for more than 5 years now. for most mail
processing applications, only the container builders need to have a
good understanding of the protocols. application developers are
offered a safe environment and an OOP interface. i see no reason why
sieve should be any different.

> IMO what's needed is a proper architectural specification for email. We're
> trying to get one of those done, but progress has been very slow.

providing that mail is interpreted sufficiently broadly, i agree

<snip>

>> > Had this been the more usual case of simply defining an XML formal, I have to
>> > admit that I would have gone with the informal approach used in, say, RFC 2629.
>> > I'm not all that keen on lots of formalism  - IMO it often hinders
>> > understanding more than it helps.
>
>> IMHO the problem is getting the right level of formalism
>
>> more modern approaches to specification (eg Atom
>> http://www.rfc-editor.org/rfc/rfc5023.txt etc) tend to make the schema
>> only informative and the description of the infoset normative. this
>> would be more flexible for example, by allowing different schema
>> langauges to be used, alterations in namespace or additional
>> annotations in foreign vocabularies.
>
> But doesn't this fly in the face of your earlier suggestion of doing this
> by annotating the schema?

i'll explain a little more what i meant by that

i was suggesting that might be worthwhile creating an independent,
clean room schema (based on the RFC), documenting it then releasing
under a suitable FOSS license (MIT). similar - in spirit - to the
Annotated XML Specification
http://www.xml.com/pub/a/axml/axmlintro.html.

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFA4QLZ014774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 03:04:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFA4QMe014773; Mon, 15 Dec 2008 03:04:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFA4DtF014746 for <[e-mail]>; Mon, 15 Dec 2008 03:04:24 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 798FA4AC6D; Mon, 15 Dec 2008 11:04:12 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1229335450-84063-1/6/7 (4 recipients); Mon, 15 Dec 2008 11:04:10 +0100
Message-Id: <[e-mail]>
Date: Mon, 15 Dec 2008 11:03:47 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Robert Burrell Donkin <[e-mail]>, Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed writes:
>>  is there a compliance test suite?
>
> Not as far as I know.

I wrote the guts of something like that after Prague IETF, where there 
was a discussion about advancing sieve to draft. I stopped working on 
it that when various people didn't reply to email about it (I did not 
feel up to a one-man crusade), but people seem to care more now and 
I'll return to it when one of my current drafts passes IESG.

> I certainly have no plans to write one or subject our implementation 
> to any that someone else develops. I doubt if anyone else does 
> either.

And I do hope you will review the document and run the code.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBF4qZge001696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 21:52:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBF4qZHB001695; Sun, 14 Dec 2008 21:52:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBF4qNmj001683 for <[e-mail]>; Sun, 14 Dec 2008 21:52:33 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 14 Dec 2008 20:52:20 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Dec 2008 20:52:17 -0800 (PST)
Date: Sun, 14 Dec 2008 20:04:46 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 14 Dec 2008 22:24:52 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, Dec 14, 2008 at 6:20 PM, Ned Freed <[e-mail]> wrote:
> >> is there a compliance test suite?
> >
> > Not as far as I know. I certainly have no plans to write one or subject our
> > implementation to any that someone else develops. I doubt if anyone else does
> > either.
> >
> > The IETF isn't big on compliance test suites as a rule - the overarching goal
> > here is interoperability, not compliance.

> however, AFACT the charter of this group does include testing

Unit tests != compliance test suites != interop testing. And the differences
really matter.

> > And this IMNSHO is a very good thing. in the past I've worked on software,
> > notably an X.400 implementation, governed by standards that emphasize
> > compliance testing. What I've observed is that after passing multiple very
> > extensive compliance test suites, the software still failed to interoperate
> > worth a damn and required all sorts of tweaks before it could.

> there is no silver interoperability bullet :-)

Actually, I sort of disagree. We've held interop test events in the past for
IMAP and SMTP that have been hugely successful in weeding out implementation
problems and making stuff place nice together.

It may not be a silver bullet, but it's surprisingly close. The main problem is
participation, or rather lack of it - getting some of the major vendors to show
up has been tough. And when there are popular implementations out there that
makes no pretense of following the standard - and there are -  it's a real
problem.

Now, Sieve presents special problems for the sort of testing that works best
for protocols. Sieve is a language, not a protocol, and that makes it kinda
tough to throw two implementation on the wire and see if they can communicate.
So the charter includes the idea of developing an interop test suite. I'm not
entirely clear how that's going to work, but hopefully it will do so by
building up a suite of scripts covering things various implementations have
found to be problematic and making sure other implementations handle them the
same way. (if I have time I'll toss in some of the unit tests we use.)

> all the stuff i help to develop is agile FOSS (TDD and BDD). automated
> tests will need to be developed so it's just a question of whether the
> tests exist already and can be shared and reused between
> implementations. the unit tests themselves are only really effectively
> portable between the moderns (.NET, java, python) but it's the
> verified example mappings which will take the time.

You now appear to be talking about unit tests. We use agile processes here as
well and unit tests are part of what we do. But these are not at all the same
as compliance tests or interop testing. Compliances tests focus on compliance
with the specification - it's implicit in the name. A proper set of unit
tests are written while looking at an actual implementation, and can look at
known edge cases in an implementation, regression tests to make sure reported
bugs don't appear, and code coverage. This is all great stuff and very
valuable.

> > As a result of this and several other experiences I must confess to
> > considerable cynicism that compliance testing represents a path to
> > interoperability. In my experience it does not, and has been for the most part
> > a colossal waste of time.

> automated testing has come a very long way in the last decade but i
> understand your perspective

GUI testing may have changed  by becoming more automatable (or not - this is
not my area and I don't keep up with the state of the art), but I haven't seen
all that much change in most other areas. Back in the late 70s and early 80s
when I did math modelling software we actually did far more extensive unit
testing and had better code coverage than we do now.

> IMO it is a method (but not the only one) of producing reliable
> relatively bug free software. i think this is a reasonable
> pre-requisite for good interoperability. a good suite should aim to
> reduce the numbers of poor implementations which claim compatibility
> rather than try to ensure that good implementations interoperate
> perfectly.

I'm always cautious about extrapolating from limited data - and we haven't seen
all that much use of scripts being moved from one implementation to another.
But to the extent we have, the problems that have shown up have been interop
issues. Unfortunately there are several Sieve implementations out there that
have chosen to ignore the extensions we've defined and roll their own to do
things the base specification does not cover.

<snip>

> > The bottom line, such as it is, is that there's effectively no leeway in the
> > copyright boilerplate you have to use if you want your stuff published as an
> > RFC. So I, and I suspect a lot of others, simply go with the flow and use
> > whatever we're told we have to use. If this is problematic for you, the place
> > to take that up is on the IPR WG list. It is not within our charter here to
> > consider such matters in any case.

> does the IEFT require copyright assignment?

Yes, there's a thing called the IETF Trust that rights are assigned to.

In fact they're going even further and asking for people to sign an agreement
granting rights to stuff in old RFCs published before copyright assignment
was required. It isn't clear to me how this can handle stuff like the
RFCs I've written with, say. Jon Postel (sadly deceased) as the coauthor, but
again, IANAL and I really try to stay as far away from this as possible.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEN33gD089442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 16:03:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEN33bC089441; Sun, 14 Dec 2008 16:03:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEN32ch089435 for <[e-mail]>; Sun, 14 Dec 2008 16:03:02 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 14 Dec 2008 15:03:00 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Dec 2008 15:02:57 -0800 (PST)
Date: Sun, 14 Dec 2008 13:59:42 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 14 Dec 2008 21:04:59 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, Dec 14, 2008 at 6:06 PM, Ned Freed <[e-mail]> wrote:
> >> i note that the draft describes the infoset rather than defining it in
> >> the standard way. is there a reason for this decision?
> >
> > I don't know what "the standard way" is you're referring to. Perhaps you
> > could provide a reference to an RFC where this has been used?

> AIUI XML is maintained by w3c (rather than IEFT) so is a
> recommendation. http://www.w3.org/TR/xml-infoset/ is the current
> document.

Quite true, however, the IETF has its own specification for XML is supposed to
be used in RFCs: RFC 3470. And while infosets are mentioned as one approach to
specifying things about an XML format, there's no recommendation, let alone
requirement, that they be used.

> > This document is a little unusual in that it's defining a mapping of, if you
> > will, a non-XML infoset onto XML. As such, the natural approach seemed to be to
> > first discuss the structure of the language being mapped, then explain the
> > mapping, and finish up with additional unique-to-XML semantics.

> i agree that most of this arangement is natural. it's just jumping to
> a schema seems - to me - a little premature and inflexible.

First of all, the use of XML Schema is in fact too inflexible to be allowed
to continue. The next revision will use Relax instead.

But I'm sitll a little confused as to what you're asking for here. If you're
asking for removal of the explicit inline XML syntax examples in favor of a
more abstract approach, I'd be fine with that if there's a WG consensus to make
such a change.

Beyond that, however, lies a slippery slope. If what you're after is a
restatement of Sieve elements and semantics in infoset form, that is not going
to happen on my watch. RFC 5228 is the definitive source of information about
such things. It may be a little awkward for implementors to have to interpolate
back through the specifications to get at the meaning of things they have in
their XML, but the alternative of having two separate specifications that are
bound to be inconsistent in some way or other is much worse.

> > This approach is perhaps not the best choice for someone coming at this trying
> > to get at Sieve semantics starting with XML, but I believe consumers of the
> > document with that mindset will be distinctly in the minority. The main focus
> > here is to provide people familiar with Sieve a means of mapping Sieve to XML
> > so that XML tools can be applied.

> my experience is entirely opposite

> developers that use the java libraries i work on have good XML but
> lack a good understanding of underlying mail technologies (for example
> sieve). there is a large and growing requirement for integration
> between mail and enterprise systems (typically coding in Java and .NET
> but also ruby and python). developers from enterprise backgrounds are
> typically strong on web+xml but very weak on mail.

Yep, I've seen a lot of this as well. And the problem emcompasses far more than
Sieve: For example, a lot of people who are unfamiliar with email don't
understand very basic concepts such as the separation between envelope and
message content. (This particular issue actually pokes through into Sieve in
the form of whether an envelope or header test is appropriate.)

But here's the dilemma: This stuff is complicated and in some cases fairly
subtle. This in turn means that the reiteration of even a subset of the
underlying design principles that implementors need to know takes up a lot of
space and will still fall short of the mark of giving the necessary guidance.
But it may lead to the belief that reading this specification (or for that
matter this one and RFC 5228) is in fact sufficient to understand how to use
Sieve. It quite simply isn't.

IMO what's needed is a proper architectural specification for email. We're
trying to get one of those done, but progress has been very slow.

> i think that there needs to be an equal focus should be on allowing
> mainstream enterprise developers familar with XML and web technologies
> to apply familiar methods and techniques to mail. this will allow
> easier and more efficient editor development.

I wish it was this easy. The mistakes I see such people make regularly cannot
be addressed by reiteration of Sieve's design here.

> FWIW i think that the draft works quite well from this perspective but
> an annotated schema

I'm far from convinced that an annotated schema will solve this problem. But in
any case, annotatiing the schema would be fine with me. I'll try and do that
when I post an update with the Relax schema.

> with an appropriate open source (eg MIT) license
> would be very useful way of introducing developers to Sieve.

I've already commented on this in a separate response.

> > Had this been the more usual case of simply defining an XML formal, I have to
> > admit that I would have gone with the informal approach used in, say, RFC 2629.
> > I'm not all that keen on lots of formalism  - IMO it often hinders
> > understanding more than it helps.

> IMHO the problem is getting the right level of formalism

> more modern approaches to specification (eg Atom
> http://www.rfc-editor.org/rfc/rfc5023.txt etc) tend to make the schema
> only informative and the description of the infoset normative. this
> would be more flexible for example, by allowing different schema
> langauges to be used, alterations in namespace or additional
> annotations in foreign vocabularies.

But doesn't this fly in the face of your earlier suggestion of doing this
by annotating the schema?

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEMiC4d088567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 15:44:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEMiCu9088566; Sun, 14 Dec 2008 15:44:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEMiB56088558 for <[e-mail]>; Sun, 14 Dec 2008 15:44:11 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so4073317bwz.10 for <[e-mail]>; Sun, 14 Dec 2008 14:44:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nmyZ6tdFl0rcFlRg63kNS7qeen4e04+htoAKcfJH0D4=; b=HBgvplMWwaHPpzwDBIr7YaNAfCtww7cK970G/LpGV5932L/adgclbQorBlcDzsMocx yG+K+iPBTqQtpuKBamm1MKJCJLSpeHbnqdrjSi1FhNpStUPgI3cVtCNMN73I2fRO8nRy fzA6TDGlGpg3laLdVqbt5CZenn+qhqtS9906s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=kxHDwQq94lvIKjX1R5IiuPvTYPR7AapCZcSGmACq8VYmOPDwopri1DhjwnK5JKAxjk KP7I/op404wZjxYIcPo3y80jPTgnBn0G2DMZ8Y7NYcPN39bB3bSffwLuol8rL3EJuKQF 9LNSmyCaEiOgtA/C0oH0TVwcYXh4nv6+eJpP0=
Received: by 10.181.146.14 with SMTP id y14mr2289478bkn.16.1229294646180; Sun, 14 Dec 2008 14:44:06 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 14 Dec 2008 14:44:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 22:44:06 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Dec 14, 2008 at 9:52 PM, Ned Freed <[e-mail]> wrote:
>> On Sun, Dec 14, 2008 at 5:46 PM, Ned Freed <[e-mail]> wrote:
>> >> i note that the xml lacks a namespace.
>> >
>> > Yes, but AFAIK nothing prevents you from assigning this vocabulary to a
>> > namespace if you wanted to mix it with some other vocabulary. But since
>> > the need for such mixing doesn't arise in the document itself, why
>> > bother with the added complexity?
>
>> by specifying the default namespace, any GUIs who require namespace
>> support must deviate from the standard and maintain their own schema.
>
> And by the same token, those that don't support namespaces (and there's
> lots of XML stuff out there that doesn't), will have trouble.

namespaces degrade gracefully provided the prefix is standardised

> I think this is a wash.

huh?

>> this makes the standard much less generally useful than it might be
>> otherwise.
>
> I disagree. I think yoy're making a mountain out of, at best, a molehill.

namespaces have been a standard so long now that most modern tools are
based around them. in simple terms, without namespaces the standard
can't be used correctly in ws*, with most generative XML binders or
generative editors.

>> >> could someone explain this design decision?
>> >
>> > Well, I suppose this could have been done by having, say, one namespace for
>> > Sieve stuff and another for annotations. But that adds a ton of complexity
>> > with no real gains as far as I can see.
>
>> failing to separate these concerns makes the standard much less useful
>> for two broad classes of GUI - generative and web service backed
>> editors.
>
> That may be your opinion. i quite simply disagree.

what specifically are you disagreeing with?

>> >> i also note that there is no separate of concerns between the editor
>> >> annotations and the substantive xml. could anyone explain this design
>> >> decision?
>> >
>> > Because it would add unnecessary complexity to the design. The implication that
>> > editor annotations are insubstantive is also incorrect - in a GUI those
>> > annotations are the focus and it's the Sieve content that's secondary.
>
>> i think this depends on the GUI. for generative approaches generally,
>> the annotations will need to be ignored.
>
>> were these annotations based on any existing standard?
>
> Nope.

so why insist on that particular solution when there are a variety of
solutions used by different tools?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEMP6bc087988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 15:25:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEMP5XW087987; Sun, 14 Dec 2008 15:25:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEMOr9U087969 for <[e-mail]>; Sun, 14 Dec 2008 15:25:04 -0700 (MST) (envelope-from [e-mail])
Received: by fxm13 with SMTP id 13so39770fxm.10 for <[e-mail]>; Sun, 14 Dec 2008 14:24:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+pR95+L9QkiR6okhapODRStwK+3flV0j5wDOXhlBFK4=; b=B+7XZ+MNQ8p+JEzRmoNCln853a2y2Fm7IBr+Bi/pVyU4Wsrz7EBKKZT6ALruqVDJv3 Lthbh247UfTdg9a5dg4KNRkRSfUsc/wKsoUK62iTGF7tMjUshZNC9X6MyC98tsRsiggq l81SBAxKlW/dh/cL4YmuPP8aau1cN7o5hqz9o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=gw19mD++cF69MTY92xRo+UqElgfcoEZa+gJEFKwi5q0TvpJpgvPghJiaPcY2LDj/Hb kRxDj7T0bRcyXtCMCwL2f8xMOw7fClwKMxjqrQGW9b8/aRhpeJqTpWAMXHkK3EGVeJQf hYMKz0RgQd8qFtaxfq2oJN7YndXKSzFt+4Ycg=
Received: by 10.181.148.2 with SMTP id a2mr2273802bko.117.1229293492828; Sun, 14 Dec 2008 14:24:52 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 14 Dec 2008 14:24:52 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 22:24:52 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Alexey Melnikov" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Dec 14, 2008 at 6:20 PM, Ned Freed <[e-mail]> wrote:
>> is there a compliance test suite?
>
> Not as far as I know. I certainly have no plans to write one or subject our
> implementation to any that someone else develops. I doubt if anyone else does
> either.
>
> The IETF isn't big on compliance test suites as a rule - the overarching goal
> here is interoperability, not compliance.

however, AFACT the charter of this group does include testing

> And this IMNSHO is a very good thing. in the past I've worked on software,
> notably an X.400 implementation, governed by standards that emphasize
> compliance testing. What I've observed is that after passing multiple very
> extensive compliance test suites, the software still failed to interoperate
> worth a damn and required all sorts of tweaks before it could.

there is no silver interoperability bullet :-)

all the stuff i help to develop is agile FOSS (TDD and BDD). automated
tests will need to be developed so it's just a question of whether the
tests exist already and can be shared and reused between
implementations. the unit tests themselves are only really effectively
portable between the moderns (.NET, java, python) but it's the
verified example mappings which will take the time.

> As a result of this and several other experiences I must confess to
> considerable cynicism that compliance testing represents a path to
> interoperability. In my experience it does not, and has been for the most part
> a colossal waste of time.

automated testing has come a very long way in the last decade but i
understand your perspective

IMO it is a method (but not the only one) of producing reliable
relatively bug free software. i think this is a reasonable
pre-requisite for good interoperability. a good suite should aim to
reduce the numbers of poor implementations which claim compatibility
rather than try to ensure that good implementations interoperate
perfectly.

<snip>

>> is there a (standard) copy of the schema available under a reasonable
>> (MIT, BSD) license?
>
> Well, now you't hit on a sore point. My understanding is that the intent is for
> the copyright on RFCs to allow essentially unrestricted reuse of all the
> material RFCs contains: Text, programs, schemata, etc. But the actual copyright
> that's applied falls short of this.

yes

(this usually means having to create clean room implementation of
schema from descriptions in the RFC)

> Attempts are ongoing to fix this, culminating in some new copyright boilerplate
> that apparently will be required for use in another couple of days even though
> the update to xml2rfc, the primary tool a lot of folks use to produce Internet
> Drafts , has not been released yet. (And yes, I'm aware there's a beta that
> supports it. Just what I need: More beta software in my life.)

:-)

> Will the new boilerplate give you the permission you need to simply use the
> schema from the specificaiton. Hopefully the answer to that is yes. But IANAL,
> and there are already more than enough engineers around here playing at being
> laywers. We don't need any more, so I'm taking no position on any of this
> stuff.

(apache is lucky enough to have friendly lawyers so this isn't such an
issue for me)

> The bottom line, such as it is, is that there's effectively no leeway in the
> copyright boilerplate you have to use if you want your stuff published as an
> RFC. So I, and I suspect a lot of others, simply go with the flow and use
> whatever we're told we have to use. If this is problematic for you, the place
> to take that up is on the IPR WG list. It is not within our charter here to
> consider such matters in any case.

does the IEFT require copyright assignment?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBELwHUq086884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 14:58:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBELwHME086883; Sun, 14 Dec 2008 14:58:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBELwGEZ086876 for <[e-mail]>; Sun, 14 Dec 2008 14:58:16 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 14 Dec 2008 13:58:14 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Dec 2008 13:58:11 -0800 (PST)
Date: Sun, 14 Dec 2008 13:56:15 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 14 Dec 2008 20:39:54 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, Dec 14, 2008 at 6:02 PM, Ned Freed <[e-mail]> wrote:
> >> the standard talks a lot about graphical user interfaces. i'd be
> >> interested to learn how it's been implemented.
> >
> > We're using an variant of what's in the draft (an earlier version) in our web
> > client. The details are rather complex, but basically what happens is that the
> > client uses the alternate representation in order to avoid having to parse and
> > otherwise deal with Sieve syntax.

> yes - sieve parsing is probably too difficult for web applications

Well, I'm not sure I'd go that far, although the whole Javascript environment
is such a nightware you may well be right.

But regardless, the point is why force people to implement another parser in a
hugely overconstained environment when they don't need to?

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBELtgg1086814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 14:55:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBELtg0t086812; Sun, 14 Dec 2008 14:55:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBELtf0A086793 for <[e-mail]>; Sun, 14 Dec 2008 14:55:41 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 14 Dec 2008 13:55:38 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Dec 2008 13:55:35 -0800 (PST)
Date: Sun, 14 Dec 2008 13:52:27 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 14 Dec 2008 20:35:28 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, Dec 14, 2008 at 5:46 PM, Ned Freed <[e-mail]> wrote:
> >> i note that the xml lacks a namespace.
> >
> > Yes, but AFAIK nothing prevents you from assigning this vocabulary to a
> > namespace if you wanted to mix it with some other vocabulary. But since
> > the need for such mixing doesn't arise in the document itself, why
> > bother with the added complexity?

> by specifying the default namespace, any GUIs who require namespace
> support must deviate from the standard and maintain their own schema.

And by the same token, those that don't support namespaces (and there's
lots of XML stuff out there that doesn't), will have trouble.

I think this is a wash.

> this makes the standard much less generally useful than it might be
> otherwise.

I disagree. I think yoy're making a mountain out of, at best, a molehill.

> >> could someone explain this design decision?
> >
> > Well, I suppose this could have been done by having, say, one namespace for
> > Sieve stuff and another for annotations. But that adds a ton of complexity
> > with no real gains as far as I can see.

> failing to separate these concerns makes the standard much less useful
> for two broad classes of GUI - generative and web service backed
> editors.

That may be your opinion. i quite simply disagree.

> >> i also note that there is no separate of concerns between the editor
> >> annotations and the substantive xml. could anyone explain this design
> >> decision?
> >
> > Because it would add unnecessary complexity to the design. The implication that
> > editor annotations are insubstantive is also incorrect - in a GUI those
> > annotations are the focus and it's the Sieve content that's secondary.

> i think this depends on the GUI. for generative approaches generally,
> the annotations will need to be ignored.

> were these annotations based on any existing standard?

Nope.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBELq829086604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 14:52:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBELq8TG086603; Sun, 14 Dec 2008 14:52:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBELpvQs086590 for <[e-mail]>; Sun, 14 Dec 2008 14:52:07 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 14 Dec 2008 13:51:54 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Dec 2008 13:51:51 -0800 (PST)
Date: Sun, 14 Dec 2008 10:20:53 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Tue, 09 Dec 2008 17:56:21 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> is there a compliance test suite?

Not as far as I know. I certainly have no plans to write one or subject our
implementation to any that someone else develops. I doubt if anyone else does
either.

The IETF isn't big on compliance test suites as a rule - the overarching goal
here is interoperability, not compliance.

And this IMNSHO is a very good thing. in the past I've worked on software,
notably an X.400 implementation, governed by standards that emphasize
compliance testing. What I've observed is that after passing multiple very
extensive compliance test suites, the software still failed to interoperate
worth a damn and required all sorts of tweaks before it could.

As a result of this and several other experiences I must confess to
considerable cynicism that compliance testing represents a path to
interoperability. In my experience it does not, and has been for the most part
a colossal waste of time.

> if so, does it have a reasonable license? (eg MIT BSD)

The presence of absence of such a license for Sieve implementations, XML
converter implementations, compliance tests, etc. etc. really isn't relevant
here.

> is there a (standard) copy of the schema available under a reasonable
> (MIT, BSD) license?

Well, now you't hit on a sore point. My understanding is that the intent is for
the copyright on RFCs to allow essentially unrestricted reuse of all the
material RFCs contains: Text, programs, schemata, etc. But the actual copyright
that's applied falls short of this.

Attempts are ongoing to fix this, culminating in some new copyright boilerplate
that apparently will be required for use in another couple of days even though
the update to xml2rfc, the primary tool a lot of folks use to produce Internet
Drafts , has not been released yet. (And yes, I'm aware there's a beta that
supports it. Just what I need: More beta software in my life.)

Will the new boilerplate give you the permission you need to simply use the
schema from the specificaiton. Hopefully the answer to that is yes. But IANAL,
and there are already more than enough engineers around here playing at being
laywers. We don't need any more, so I'm taking no position on any of this
stuff.

The bottom line, such as it is, is that there's effectively no leeway in the
copyright boilerplate you have to use if you want your stuff published as an
RFC. So I, and I suspect a lot of others, simply go with the flow and use
whatever we're told we have to use. If this is problematic for you, the place
to take that up is on the IPR WG list. It is not within our charter here to
consider such matters in any case.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEL5O7a006990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 14:05:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEL5OxT006989; Sun, 14 Dec 2008 14:05:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEL5M5L006983 for <[e-mail]>; Sun, 14 Dec 2008 14:05:23 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so4001551bwz.10 for <[e-mail]>; Sun, 14 Dec 2008 13:05:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rB8WhxjzTn1ZV38xb7N1B4EWtie4+eu1UxXM1TxwtlM=; b=S3hokx7Dr2jq0Em6Qq+DdUEItkOinCyXOrzqiYeW96jIBLRxkCM/vvQYK3e6OdOuVQ m2Mq5/TmaaM2c/uFXF4Bv1kpxHV7FdwVHKYzUYObMVjs7q+xLosz88XZV9CFA57WPaiT jyHWurLma6BAbwNfwACPMyJ1Dub1tiBjCyqm8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IHxVQaOA05gcCgC9ECJuE1m5VXI5Wv5VqhAq4MflroEIAL/5J7IAX+XpY6uvLcFl2K 2v1fsNH05xSo89Lgnqf4oQBzfDtFJdidn/theW5TGnigasIsmfSwkmtbbuGcBldgInrs QwiZdiZ4rAbIAMplYOzfJ3OQoOh3SqJCS7Z8w=
Received: by 10.180.224.13 with SMTP id w13mr2252062bkg.160.1229288699742; Sun, 14 Dec 2008 13:04:59 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 14 Dec 2008 13:04:59 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 21:04:59 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Dec 14, 2008 at 6:06 PM, Ned Freed <[e-mail]> wrote:
>> i note that the draft describes the infoset rather than defining it in
>> the standard way. is there a reason for this decision?
>
> I don't know what "the standard way" is you're referring to. Perhaps you
> could provide a reference to an RFC where this has been used?

AIUI XML is maintained by w3c (rather than IEFT) so is a
recommendation. http://www.w3.org/TR/xml-infoset/ is the current
document.

> This document is a little unusual in that it's defining a mapping of, if you
> will, a non-XML infoset onto XML. As such, the natural approach seemed to be to
> first discuss the structure of the language being mapped, then explain the
> mapping, and finish up with additional unique-to-XML semantics.

i agree that most of this arangement is natural. it's just jumping to
a schema seems - to me - a little premature and inflexible.

> This approach is perhaps not the best choice for someone coming at this trying
> to get at Sieve semantics starting with XML, but I believe consumers of the
> document with that mindset will be distinctly in the minority. The main focus
> here is to provide people familiar with Sieve a means of mapping Sieve to XML
> so that XML tools can be applied.

my experience is entirely opposite

developers that use the java libraries i work on have good XML but
lack a good understanding of underlying mail technologies (for example
sieve). there is a large and growing requirement for integration
between mail and enterprise systems (typically coding in Java and .NET
but also ruby and python). developers from enterprise backgrounds are
typically strong on web+xml but very weak on mail.

i think that there needs to be an equal focus should be on allowing
mainstream enterprise developers familar with XML and web technologies
to apply familiar methods and techniques to mail. this will allow
easier and more efficient editor development.

FWIW i think that the draft works quite well from this perspective but
an annotated schema with an appropriate open source (eg MIT) license
would be very useful way of introducing developers to Sieve.

> Had this been the more usual case of simply defining an XML formal, I have to
> admit that I would have gone with the informal approach used in, say, RFC 2629.
> I'm not all that keen on lots of formalism  - IMO it often hinders
> understanding more than it helps.

IMHO the problem is getting the right level of formalism

more modern approaches to specification (eg Atom
http://www.rfc-editor.org/rfc/rfc5023.txt etc) tend to make the schema
only informative and the description of the infoset normative. this
would be more flexible for example, by allowing different schema
langauges to be used, alterations in namespace or additional
annotations in foreign vocabularies.

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEKdvOe006151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 13:39:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEKdv4i006150; Sun, 14 Dec 2008 13:39:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEKdtYv006143 for <[e-mail]>; Sun, 14 Dec 2008 13:39:56 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so3982136bwz.10 for <[e-mail]>; Sun, 14 Dec 2008 12:39:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Q3USkj6FC+vocO7nTXaYjxnC7wNZgS+t6lzo/VsU/oQ=; b=dVFX8ZXK2eFJLWgTxD83610o6KH3PStGpOf3+hPiGUo+mpdyE+2ySOb3RMAT8FfIrl /vMzAC8HAO1vD5ODGXJF+SifB18GDoXGbINXjBO734tuJSzo2F72LzMitavRJJR+/T+G eq/uF2XEEbVHXK2YhHAgcFUubI1fd0eXBB3j4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TP1x7THkeC4N8Y+rQCvxTAdLkw+KX0PWhgweQs0BmZ0DNVs31wI5iiNyR9lzUbXBQ6 DAcjZ2hEUN4Aa0J2IZe4W3S04riXydwEQBdufBHMl+xJqR6wKEXvC8vrzSAJhMeWS2pO gIPbCZmS7STcCu1ZPRjxOwfoS1TGBifd8zzdk=
Received: by 10.181.144.11 with SMTP id w11mr2247349bkn.81.1229287194725; Sun, 14 Dec 2008 12:39:54 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 14 Dec 2008 12:39:54 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 20:39:54 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Dec 14, 2008 at 6:02 PM, Ned Freed <[e-mail]> wrote:
>> the standard talks a lot about graphical user interfaces. i'd be
>> interested to learn how it's been implemented.
>
> We're using an variant of what's in the draft (an earlier version) in our web
> client. The details are rather complex, but basically what happens is that the
> client uses the alternate representation in order to avoid having to parse and
> otherwise deal with Sieve syntax.

yes - sieve parsing is probably too difficult for web applications

i'm aware of a sieve editor that uses web services that sounds similar

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEKZhJ8006086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 13:35:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEKZhm1006085; Sun, 14 Dec 2008 13:35:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEKZVoJ006074 for <[e-mail]>; Sun, 14 Dec 2008 13:35:42 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so3978544bwz.10 for <[e-mail]>; Sun, 14 Dec 2008 12:35:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bK4k5jKUN8N/Tlb5IdK9OpXteYTvYr2EwITJZVcu3o0=; b=RGjejY8/KlNs2MLrG/zYsvfh3GG0ySqSpx7VdsefD1PnwGxf2t/hqgNgAZ3Px8u7Ic vX9qMzi0CZ4+xUvpxWkRkqCubUuWyiDAdVzAO4c7xMoxNRNa2TGkXcsjfXnBymgDEqYK 20W7Fz8c1q8Dlgk5/2zz0kq9CRaRnGQvlRdc4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TSAOBO5NYO+uZwEUOK2FtfQCQtw/0QbBoEzU1TrUC9R4cVW3D5OTB6tKuPp+7DDfp/ JvbXMBz0kDt8hCaIM0xdRbOUh9jteBxA2KMyibK6ZQQjkqJXoY4WrsqxB09/8ChVzcup isvggFdXt7hrdySlzvLux72oYR0Y31TfAbseI=
Received: by 10.181.226.2 with SMTP id d2mr2241359bkr.204.1229286928714; Sun, 14 Dec 2008 12:35:28 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 14 Dec 2008 12:35:28 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 20:35:28 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Dec 14, 2008 at 5:46 PM, Ned Freed <[e-mail]> wrote:
>> i note that the xml lacks a namespace.
>
> Yes, but AFAIK nothing prevents you from assigning this vocabulary to a
> namespace if you wanted to mix it with some other vocabulary. But since
> the need for such mixing doesn't arise in the document itself, why
> bother with the added complexity?

by specifying the default namespace, any GUIs who require namespace
support must deviate from the standard and maintain their own schema.
this makes the standard much less generally useful than it might be
otherwise.

>> could someone explain this design decision?
>
> Well, I suppose this could have been done by having, say, one namespace for
> Sieve stuff and another for annotations. But that adds a ton of complexity
> with no real gains as far as I can see.

failing to separate these concerns makes the standard much less useful
for two broad classes of GUI - generative and web service backed
editors.

>> i also note that there is no separate of concerns between the editor
>> annotations and the substantive xml. could anyone explain this design
>> decision?
>
> Because it would add unnecessary complexity to the design. The implication that
> editor annotations are insubstantive is also incorrect - in a GUI those
> annotations are the focus and it's the Sieve content that's secondary.

i think this depends on the GUI. for generative approaches generally,
the annotations will need to be ignored.

were these annotations based on any existing standard?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEIKgE2001016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 11:20:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEIKguu001015; Sun, 14 Dec 2008 11:20:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEIKgt9001009 for <[e-mail]>; Sun, 14 Dec 2008 11:20:42 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 14 Dec 2008 10:20:40 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Dec 2008 10:20:37 -0800 (PST)
Date: Sun, 14 Dec 2008 10:06:20 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 14 Dec 2008 11:01:27 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> i note that the draft describes the infoset rather than defining it in
> the standard way. is there a reason for this decision?

I don't know what "the standard way" is you're referring to. Perhaps you
could provide a reference to an RFC where this has been used?

This document is a little unusual in that it's defining a mapping of, if you
will, a non-XML infoset onto XML. As such, the natural approach seemed to be to
first discuss the structure of the language being mapped, then explain the
mapping, and finish up with additional unique-to-XML semantics.

This approach is perhaps not the best choice for someone coming at this trying
to get at Sieve semantics starting with XML, but I believe consumers of the
document with that mindset will be distinctly in the minority. The main focus
here is to provide people familiar with Sieve a means of mapping Sieve to XML
so that XML tools can be applied.

Had this been the more usual case of simply defining an XML formal, I have to
admit that I would have gone with the informal approach used in, say, RFC 2629.
I'm not all that keen on lots of formalism  - IMO it often hinders
understanding more than it helps.

				Ned




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEI6EKv000124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 11:06:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEI6ELe000123; Sun, 14 Dec 2008 11:06:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEI6ElB000117 for <[e-mail]>; Sun, 14 Dec 2008 11:06:14 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 14 Dec 2008 10:06:12 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Dec 2008 10:06:10 -0800 (PST)
Date: Sun, 14 Dec 2008 10:02:36 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 14 Dec 2008 11:41:44 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> the standard talks a lot about graphical user interfaces. i'd be
> interested to learn how it's been implemented.

We're using an variant of what's in the draft (an earlier version) in our web
client. The details are rather complex, but basically what happens is that the
client uses the alternate representation in order to avoid having to parse and
otherwise deal with Sieve syntax.

> do any existing desktop GUIs use this mapping?

I don't know.

> do any existing web GUIs use this mapping?

Yes, see above.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEI2cdS099927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 11:02:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEI2cMD099926; Sun, 14 Dec 2008 11:02:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEI2RfK099916 for <[e-mail]>; Sun, 14 Dec 2008 11:02:37 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 14 Dec 2008 10:02:25 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Dec 2008 10:02:23 -0800 (PST)
Date: Sun, 14 Dec 2008 09:46:19 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
In-reply-to: "Your message dated Sun, 14 Dec 2008 11:55:52 +0000" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> i note that the xml lacks a namespace.

Yes, but AFAIK nothing prevents you from assigning this vocabulary to a
namespace if you wanted to mix it with some other vocabulary. But since
the need for such mixing doesn't arise in the document itself, why
bother with the added complexity?

> could someone explain this design decision?

Well, I suppose this could have been done by having, say, one namespace for
Sieve stuff and another for annotations. But that adds a ton of complexity
with no real gains as far as I can see.

> i also note that there is no separate of concerns between the editor
> annotations and the substantive xml. could anyone explain this design
> decision?

Because it would add unnecessary complexity to the design. The implication that
editor annotations are insubstantive is also incorrect - in a GUI those
annotations are the focus and it's the Sieve content that's secondary.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEBttbF084260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 04:55:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEBtt1I084259; Sun, 14 Dec 2008 04:55:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEBtrP6084253 for <[e-mail]>; Sun, 14 Dec 2008 04:55:54 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so3628272bwz.10 for <[e-mail]>; Sun, 14 Dec 2008 03:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=pLET603R3C/bt3630VyG0SQ7bO/6IHdDuFLN4FMf1S4=; b=Rx3d2Rhb8c+fgHvwAViLfOFqBbcRqKKV0Ac/9p+ixFAPDyy3HGD54xzXF3XIJLc2EG ok7VZMXsgs0caOojfP1CEwY0FizM+fyj6RVPDVyBAXC1Vcwg/N3DZlKZtztdqThjE5Ke LeIb4ab7W8BpZaCYe5pWlnX3kOysmwoeZV+yY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tmCENUsB8YJQ0a0kXSCukrSACaHSoCKBk+fEfzYJPp/GTDAVTpHJSz0GE0YqmcZW49 jR/qKn+X0x13KkxGVUNSLKcUJcqq75xJ9QXySxxK3cLr9JKh6fFnhRjLXR8pbUnA8vv2 R51QJnn16aJOnBLZ+NFCPweuFz5dx3tTCgGSw=
Received: by 10.181.202.12 with SMTP id e12mr2098603bkq.138.1229255752307; Sun, 14 Dec 2008 03:55:52 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 14 Dec 2008 03:55:52 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 11:55:52 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Dec 9, 2008 at 5:56 PM, Robert Burrell Donkin
<[e-mail]> wrote:
> On Tue, Dec 9, 2008 at 3:36 PM, Alexey Melnikov
> <[e-mail]> wrote:
>> Hi Robert,
>>
>> Robert Burrell Donkin wrote:
>>
>>> i note that http://tools.ietf.org/html/draft-freed-sieve-in-xml-01
>>> expired on August 28, 2008 but i cannot find a new draft. what's the
>>> current status of this draft?
>>>
>>
>> Speaking as a WG co-chair: I am waiting for Ned to publish a new revision so
>> that Cyrus and I can start Working Group Last Call on the document.
>
> thanks
>
> a couple of futher questions:
>
> is there a compliance test suite? if so, does it have a reasonable
> license? (eg MIT BSD)
>
> is there a (standard) copy of the schema available under a reasonable
> (MIT, BSD) license?
>
> - robert

i note that the xml lacks a namespace. could someone explain this
design decision?

i also note that there is no separate of concerns between the editor
annotations and the substantive xml. could anyone explain this design
decision?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEBflCs083233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 04:41:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEBflSh083232; Sun, 14 Dec 2008 04:41:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEBfjhe083225 for <[e-mail]>; Sun, 14 Dec 2008 04:41:46 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so3620302bwz.10 for <[e-mail]>; Sun, 14 Dec 2008 03:41:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2ZDh7bSOhrx84IiXq/hT6+9iyvRJbymEv04/CO4dYak=; b=ri8Zg665zGvaczgqDS+wHg1D97QWuNJ4v2w78/W9DtkjlrnqCHk/+avXA/jrv4AuPt gXuQFctouR2gYOMpNQ0IYKLiApJ5cWwsfu/37qx3cwkajJ1ot4B4agGcDesaWS/vEum4 M1+3ivN11hL5Fszn5ytUjfh0D9FWvxVhzKg4k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=d0gXRKObVb671VaM7DZVErq1L6uIJwau3iilTajRyW/m1FHfaCemFSP5rMlTVUqslY qE5fqvDE4/NHboPa0GIJxAEI/3RglJoLf4h2IFRevXPnST+LWmUovfoOq9DS7e0cHOED nZfL1hHAJTamu9XtitCs7HRm/qfFR7Mc8sBFc=
Received: by 10.180.224.13 with SMTP id w13mr2091384bkg.160.1229254904650; Sun, 14 Dec 2008 03:41:44 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 14 Dec 2008 03:41:44 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 11:41:44 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Dec 9, 2008 at 5:56 PM, Robert Burrell Donkin
<[e-mail]> wrote:
> On Tue, Dec 9, 2008 at 3:36 PM, Alexey Melnikov
> <[e-mail]> wrote:
>> Hi Robert,
>>
>> Robert Burrell Donkin wrote:
>>
>>> i note that http://tools.ietf.org/html/draft-freed-sieve-in-xml-01
>>> expired on August 28, 2008 but i cannot find a new draft. what's the
>>> current status of this draft?
>>>
>>
>> Speaking as a WG co-chair: I am waiting for Ned to publish a new revision so
>> that Cyrus and I can start Working Group Last Call on the document.
>
> thanks
>
> a couple of futher questions:
>
> is there a compliance test suite? if so, does it have a reasonable
> license? (eg MIT BSD)
>
> is there a (standard) copy of the schema available under a reasonable
> (MIT, BSD) license?

the standard talks a lot about graphical user interfaces. i'd be
interested to learn how it's been implemented.

do any existing desktop GUIs use this mapping?

do any existing web GUIs use this mapping?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEB1ef5081002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Dec 2008 04:01:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBEB1eYS081001; Sun, 14 Dec 2008 04:01:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBEB1Stu080983 for <[e-mail]>; Sun, 14 Dec 2008 04:01:39 -0700 (MST) (envelope-from [e-mail])
Received: by bwz5 with SMTP id 5so3600328bwz.10 for <[e-mail]>; Sun, 14 Dec 2008 03:01:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fG34CjqCB5z9cK6DAujG517IwLfdsNXBwv/VnMyvrq0=; b=o+ELWn7AODzOMLp3jsBuw/mnCWxKpUa8hCq6WHycUk8O6bSCmLQL67Nu795UsB6pgx E/uq1WaTSJP57fKRTvKaB1CIFJIt8iR+ME20dnpxp0MYrs3wZFbcnZrWFOd4OCrdAga9 Q5DNHoNGn7MZFZqL/5ENVmAHDk9G6gqyXrjU4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pelWKp66x7A3bAGVpa1kFwfeZmnX2l39nM9cZFvDLuWIg35MLUoyNHchGwhdjnpbyX H6G9UiNg1wljDQC72BJmLRGUbZr5dDqLIScLJRBc4NmB7YFpoV3ewssK5xwZ+VjEt/BD OGagOWDXxNElv9JgNzEVYAqss5w7StsSfBDsA=
Received: by 10.181.145.7 with SMTP id x7mr2072361bkn.177.1229252487221; Sun, 14 Dec 2008 03:01:27 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Sun, 14 Dec 2008 03:01:27 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 11:01:27 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Dec 9, 2008 at 5:56 PM, Robert Burrell Donkin
<[e-mail]> wrote:
> On Tue, Dec 9, 2008 at 3:36 PM, Alexey Melnikov
> <[e-mail]> wrote:
>> Hi Robert,
>>
>> Robert Burrell Donkin wrote:
>>
>>> i note that http://tools.ietf.org/html/draft-freed-sieve-in-xml-01
>>> expired on August 28, 2008 but i cannot find a new draft. what's the
>>> current status of this draft?
>>>
>>
>> Speaking as a WG co-chair: I am waiting for Ned to publish a new revision so
>> that Cyrus and I can start Working Group Last Call on the document.
>
> thanks
>
> a couple of futher questions:
>
> is there a compliance test suite? if so, does it have a reasonable
> license? (eg MIT BSD)
>
> is there a (standard) copy of the schema available under a reasonable
> (MIT, BSD) license?

i note that the draft describes the infoset rather than defining it in
the standard way. is there a reason for this decision?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBC0F0pm041936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 17:15:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBC0F06S041935; Thu, 11 Dec 2008 17:15:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBC0Em8h041895 for <[e-mail]>; Thu, 11 Dec 2008 17:14:58 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 11 Dec 2008 16:14:43 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 11 Dec 2008 16:14:38 -0800 (PST)
Date: Thu, 11 Dec 2008 11:53:09 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: A little sieve help
In-reply-to: "Your message dated Thu, 11 Dec 2008 13:50:20 -0500" <[e-mail]>
To: Patrick Baldwin <[e-mail]>
Cc: Aaron Stone <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <1228960410.29598.1672.camel@turtle> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Is there some other way I should be trying to use sieve to prevent a
> possible mail loop?

First of all, sieve implementations are required to check for redirect loops
and break them if necessary. This means that accidental redirection loops
should be a nonissue - if they are an issue something is broken in your Sieve
implementation.

This leaves two other cases: intentional loops, such as when want both A and B
to get a copy of every message no matter where it was originally sent, and
bounce loops.

Adding headers and checking for them later does break loops in this case, but
unless you're able to add the header on both A and B it won't break the loop
until one duplicate is received. You're much better off finding a header or
some other telltake that's added naturally by either side and checking for it
in the other side. Received: fields are often a useful place to look for such
telltales.

Bounce loops are a nastier bit of business. A true bounce loop should not be
able to form because of the requirement on redirect that it not change
empty envelope from addresses. But this means that a bounce will be redirected
and then dropped by the other end, which breaks the loop but adds overhead
you'd probably like to avoid.

The other problem with bounce loops is that not all MTAs or filtering
mechanisms are standards compliant, and you may find cases where envelope from
addresses get filled in by forwarders (bad) or bounces are sent to header From:
fields (also bad). Again, if your Sieve implementation does any of these
things, it's broken.

Probably the most effective way to deal with them is to simply not forward
messages with an empty envelope address, e.g.

    if not envelope :is "from" "" { redirect "a@b"; }

But that will prevent forwarding of all bounces, which may not be what you
want. If that's unworkable, you're back to looking for telltales the other
system inserts into the DSNs it generates. Find one of those, test for it,
and if it is present don't redirect the message.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBMivQa038103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 15:44:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBMivrR038102; Thu, 11 Dec 2008 15:44:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBMiuAb038096 for <[e-mail]>; Thu, 11 Dec 2008 15:44:56 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id D76BA3A69DF; Thu, 11 Dec 2008 14:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-notify-sip-message-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 11 Dec 2008 14:45:01 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Notification Mechanism: SIP MESSAGE
	Author(s)       : A. Melnikov, et al.
	Filename        : draft-ietf-sieve-notify-sip-message-00.txt
	Pages           : 10
	Date            : 2008-12-11

This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent over the SIP
MESSAGE.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-notify-sip-message-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBImtCk027659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 11:48:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBImt3P027658; Thu, 11 Dec 2008 11:48:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bostonserver.studsvik-analytic.com (firewall.studsvik-analytic.com [155.212.59.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBImhIn027638 for <[e-mail]>; Thu, 11 Dec 2008 11:48:54 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.169.115] (eddie [192.168.169.115]) by bostonserver.studsvik-analytic.com (8.12.5/8.12.5) with ESMTP id mBBIdnfv029426; Thu, 11 Dec 2008 13:39:49 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 11 Dec 2008 13:50:20 -0500
From: Patrick Baldwin <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: A little sieve help
References: <[e-mail]> <1228960410.29598.1672.camel@turtle>
In-Reply-To: <1228960410.29598.1672.camel@turtle>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:
> This mailing list mostly works on Sieve as a standard, 

Is there another list that would be better for user questions?

> but a few user
> questions now and then is good -- someone is using this stuff! ;-)
>
>   

That's the plan.

> On Wed, 2008-12-10 at 17:31 -0500, Patrick Baldwin wrote:
>
> [snip procmail script]
>
>   
>> In sieve, I was thinking something like:
>>
>> require ["fileinto","regex","envelope"];
>>
>> if address :is "To" "online" {
>>   fileinto "online";
>> } elsif address :is "To" "Support" { 
>>   fileinto "Support";
>>     
> }
>   
>> if address :is "From" "<ship address>" {
>>   fileinto "SHIPMENTS";
>> }
>>     
>
> :matches might be what you want, rather than :is.
>
>   

Sure was, thanks.

>> redirect "<user name>@gmail.com";
>> keep;
>>
>> stop;
>>     
>
> Stop is not needed at the end of the script, but doesn't hurt.
>
>   
>> ...but I'm really not sure.  I also haven't figured out how to have sieve
>> insert a header to avoid mail loops like I did with procmail.
>>     
>
> libsieve doesn't support the editheader extension yet, RFC 5293. It's on
> my todo list...
>
>
>   

Is there some other way I should be trying to use sieve to prevent a 
possible mail loop?


Regards,

-- 
Patrick Baldwin
Systems Administrator
Studsvik Scandpower
617-965-7455 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBB1vv6v079857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 18:57:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBB1vv4U079856; Wed, 10 Dec 2008 18:57:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBB1vjKx079847 for <[e-mail]>; Wed, 10 Dec 2008 18:57:56 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.34] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 031C51F9E; Wed, 10 Dec 2008 18:01:44 -0800 (PST)
Subject: Re: A little sieve help
From: Aaron Stone <[e-mail]>
To: Patrick Baldwin <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 10 Dec 2008 17:53:30 -0800
Message-Id: <1228960410.29598.1672.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.2 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This mailing list mostly works on Sieve as a standard, but a few user
questions now and then is good -- someone is using this stuff! ;-)

On Wed, 2008-12-10 at 17:31 -0500, Patrick Baldwin wrote:

[snip procmail script]

> In sieve, I was thinking something like:
> 
> require ["fileinto","regex","envelope"];
> 
> if address :is "To" "online" {
>   fileinto "online";
> } elsif address :is "To" "Support" { 
>   fileinto "Support";
}
> if address :is "From" "<ship address>" {
>   fileinto "SHIPMENTS";
> }

:matches might be what you want, rather than :is.

> redirect "<user name>@gmail.com";
> keep;
> 
> stop;

Stop is not needed at the end of the script, but doesn't hurt.

> 
> ...but I'm really not sure.  I also haven't figured out how to have sieve
> insert a header to avoid mail loops like I did with procmail.

libsieve doesn't support the editheader extension yet, RFC 5293. It's on
my todo list...

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBAMU1xM070815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 15:30:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBAMU1Zw070814; Wed, 10 Dec 2008 15:30:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bostonserver.studsvik-analytic.com (firewall.studsvik-analytic.com [155.212.59.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBAMTxkH070798 for <[e-mail]>; Wed, 10 Dec 2008 15:30:00 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.169.115] (eddie [192.168.169.115]) by bostonserver.studsvik-analytic.com (8.12.5/8.12.5) with ESMTP id mBAML5fv004642 for <[e-mail]>; Wed, 10 Dec 2008 17:21:05 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 10 Dec 2008 17:31:36 -0500
From: Patrick Baldwin <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: A little sieve help
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, I'm in the process of moving my mail to a new server, which will be 
using sieve
instead of procmail.  I've run into some difficulty, and this list was 
the only one I could
find mentioned in conjunction with sieve; if this is an inappropriate 
venue for my questions,
my apologies.

First I tried the conversion script mentioned in:

http://dovecot.org/list/dovecot/2007-March/020895.html

But that didn't produce any output.

I'm trying to turn this procmail script into a sieve script (alterations 
from real
script in <>):

:0
* ^TO_(online)
| /usr/local/bin/dmail +online

:0
* ^TO_(support|internal)
| /usr/local/bin/dmail +Support

:0
* ^From:.ship@.*(<company-name>\.com)
| /usr/local/bin/dmail +SHIPMENTS

:0c
* !^FROM_DAEMON
* !^FROM_MAILER
* !^X-Loop: to_gmail
| (formail -i"Cc:" -I"To: <user name>@gmail.com" \
               -A"X-Loop: to_gmail" \
  ) | $SENDMAIL -t

:0
| /usr/local/bin/dmail


In sieve, I was thinking something like:

require ["fileinto","regex","envelope"];

if address :is "To" "online" {
  fileinto "online";
} elsif address :is "To" "Support" { 
  fileinto "Support";

if address :is "From" "<ship address>" {
  fileinto "SHIPMENTS";
}

redirect "<user name>@gmail.com";
keep;

stop;


...but I'm really not sure.  I also haven't figured out how to have sieve
insert a header to avoid mail loops like I did with procmail.

Any help much appreciated.

Regards,

-- 
Patrick Baldwin
Systems Administrator
Studsvik Scandpower
617-965-7455 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBA9Uc4i015694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 02:30:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBA9UcRV015693; Wed, 10 Dec 2008 02:30:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBA9UQK6015681 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 10 Dec 2008 02:30:38 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1LALOi-0000u0-QM; Wed, 10 Dec 2008 10:30:24 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.5] (d90-134-5-214.cust.tele2.de [90.134.5.214]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id mBA9ULjX032516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 10 Dec 2008 09:30:24 GMT
Message-ID: <[e-mail]>
Date: Wed, 10 Dec 2008 10:30:21 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: sieveurl-list-scripts += [owner "/"]
References: <[e-mail]> <[e-mail]>            <[e-mail]> <1228509838.16036.21.camel@turtle> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Again about "include :global" and authorization ID. 
draft-ietf-sieve-managesieve-03, Section 3. Sieve URL Scheme defines

sieveurl = sieveurl-server / sieveurl-list-scripts /
            sieveurl-script

sieveurl-server = "sieve://" authority

sieveurl-list-scripts = "sieve://" authority ["/"]

sieveurl-script = "sieve://" authority "/"
                   [owner "/"] scriptname


[owner "/"] in sieveurl-scrupt provides the possibility to edit the 
scripts of the other users, but sieveurl-list-scripts cannot show how 
are the scripts of that users named.  What about including [owner "/"] 
in sieveurl-list-scripts, making it to:

sieveurl-list-scripts = "sieve://" authority ["/"] [owner "/"]

In this way one can see a list of scripts, that are managed by other users.

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


Alexey Melnikov wrote:
> 
> Aaron Stone wrote:
> 
>> On Sun, 2008-11-30 at 17:58 +0000, Alexey Melnikov wrote:
>>  
>>
>>>>> My suggestion is to let the user see the global scripts, when the 
>>>>> authorization ID is the empty string.  In terms of the Sieve URL 
>>>>> Scheme, the global scripts could be accessible when owner = '\0'.  
>>>>> I mean when
>>>>>         sieveurl-script = "sieve://" [ authority ] "/"
>>>>>                           [owner "/"] scriptname
>>>>> has the form
>>>>>         sieveurl-script = "sieve://" [ authority ] "//" scriptname
>>>>> then requested are the global scripts.
>>>>>       
>>>> While I think having a standardized way of accessing global scripts 
>>>> would be a good idea, I am not convinced that the empty string is 
>>>> going to be Ok.
>>>> This might have some weird side effects on URI parsers (but I am not 
>>>> sure).     
>> Some URI parsers will collapse repeated slashes, some won't. I've seen
>> weird behavior before when slashes were duplicated in HTTP requests and
>> a non-collapsing URI parser was in place. Is there a "correct"
>> normative behavior for this?
>>
> I think handling of repeated slashes in URIs is URI-scheme specific. 
> (The behavior you describe is quite sensible for HTTP, because 
> filesystems convert "//" to "/".)
> The only rule is that if a URI scheme allows for relative path URIs, 
> they can't start with unencoded "//", as this would be indistinguishable 
> from URI's "authority" component (username + host + port).
> 
> In "sieve:" URIs I've prohibited relative path form, so that shouldn't 
> be an issue.
> 
>> Aaron 
>>> I've updated the draft to include your proposal. It looks like 
>>> "owner" can be empty, as long as "authority" is not.
>>>   
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9IGS2Y074836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 11:16:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB9IGSd7074835; Tue, 9 Dec 2008 11:16:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9IGRHK074829 for <[e-mail]>; Tue, 9 Dec 2008 11:16:27 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 9 Dec 2008 18:16:26 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 09 Dec 2008 18:16:11 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Aaron Stone <[e-mail]>
CC: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>, IETF Sieve WG <[e-mail]>
Subject: Re: managesieve: formats; :global; read-only; checkscript
References: <[e-mail]> <[e-mail]> <[e-mail]> <1228509838.16036.21.camel@turtle>
In-Reply-To: <1228509838.16036.21.camel@turtle>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Sun, 2008-11-30 at 17:58 +0000, Alexey Melnikov wrote:
>  
>
>>>>My suggestion is to let the user see the global scripts, when the 
>>>>authorization ID is the empty string.  In terms of the Sieve URL 
>>>>Scheme, the global scripts could be accessible when owner = '\0'.  I 
>>>>mean when
>>>>         sieveurl-script = "sieve://" [ authority ] "/"
>>>>                           [owner "/"] scriptname
>>>>has the form
>>>>         sieveurl-script = "sieve://" [ authority ] "//" scriptname
>>>>then requested are the global scripts.
>>>>        
>>>>
>>>While I think having a standardized way of accessing global scripts 
>>>would be a good idea, I am not convinced that the empty string is 
>>>going to be Ok.
>>>This might have some weird side effects on URI parsers (but I am not 
>>>sure).      
>>>
>Some URI parsers will collapse repeated slashes, some won't. I've seen
>weird behavior before when slashes were duplicated in HTTP requests and
>a non-collapsing URI parser was in place. Is there a "correct"
>normative behavior for this?
>
I think handling of repeated slashes in URIs is URI-scheme specific. 
(The behavior you describe is quite sensible for HTTP, because 
filesystems convert "//" to "/".)
The only rule is that if a URI scheme allows for relative path URIs, 
they can't start with unencoded "//", as this would be indistinguishable 
from URI's "authority" component (username + host + port).

In "sieve:" URIs I've prohibited relative path form, so that shouldn't 
be an issue.

>Aaron  
>
>>I've updated the draft to include your proposal. It looks like "owner" 
>>can be empty, as long as "authority" is not.
>>    
>>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9I5l9M074124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 11:05:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB9I5lV8074123; Tue, 9 Dec 2008 11:05:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f11.google.com (mail-fx0-f11.google.com [209.85.220.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9I5ZL7074114 for <[e-mail]>; Tue, 9 Dec 2008 11:05:47 -0700 (MST) (envelope-from [e-mail])
Received: by fxm4 with SMTP id 4so20751fxm.10 for <[e-mail]>; Tue, 09 Dec 2008 10:05:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Sp7VM+wa0yXGMVOd/wSYfL8C+YAP3j/KwGIHBkbLjEY=; b=D0pmcWqLWGsOCVcis/9GY4D4b9h4/KFaLjIxyrLTy2Cm60k3GJfXiiHr20RQDX8Ly4 pYdyRToWGJM5NNmvU6amPvqjNPZZuokr3Pqtq0ye7baSm42l2+E7pjunqVccbRFqMj4O KvvvxIP6TbG8HytdAJgbwL+a8h9y6ttfb4kzs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ttyeIfMblU0b0KaLOzb5U04bLBytf3/cimTV+HzzgLIgd1E3wbNOfy2QTndIejZdZc tT617R0U8UtqZhpdEYTSM6KsREovuaQGhdsVfd8BbgTaMC/KWMz24HThm2DDlV1XfKKy OHr2/8g4NGx1ncn9jIoJBEk60pn7D4BPKu0yk=
Received: by 10.181.198.10 with SMTP id a10mr114821bkq.120.1228845381890; Tue, 09 Dec 2008 09:56:21 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Tue, 9 Dec 2008 09:56:21 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 9 Dec 2008 17:56:21 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Dec 9, 2008 at 3:36 PM, Alexey Melnikov
<[e-mail]> wrote:
> Hi Robert,
>
> Robert Burrell Donkin wrote:
>
>> i note that http://tools.ietf.org/html/draft-freed-sieve-in-xml-01
>> expired on August 28, 2008 but i cannot find a new draft. what's the
>> current status of this draft?
>>
>
> Speaking as a WG co-chair: I am waiting for Ned to publish a new revision so
> that Cyrus and I can start Working Group Last Call on the document.

thanks

a couple of futher questions:

is there a compliance test suite? if so, does it have a reasonable
license? (eg MIT BSD)

is there a (standard) copy of the schema available under a reasonable
(MIT, BSD) license?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9FasEA064956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 08:36:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB9Fas8R064955; Tue, 9 Dec 2008 08:36:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9FarO5064949 for <[e-mail]>; Tue, 9 Dec 2008 08:36:54 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 9 Dec 2008 15:36:52 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 09 Dec 2008 15:36:46 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Robert Burrell Donkin <[e-mail]>
CC: [e-mail]
Subject: Re: draft-freed-sieve-in-xml status?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Robert,

Robert Burrell Donkin wrote:

>i note that http://tools.ietf.org/html/draft-freed-sieve-in-xml-01
>expired on August 28, 2008 but i cannot find a new draft. what's the
>current status of this draft?
>  
>
Speaking as a WG co-chair: I am waiting for Ned to publish a new 
revision so that Cyrus and I can start Working Group Last Call on the 
document.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9FLB2k064167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 08:21:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB9FLATq064166; Tue, 9 Dec 2008 08:21:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9FKxlm064156 for <[e-mail]>; Tue, 9 Dec 2008 08:21:10 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 9 Dec 2008 15:20:58 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 09 Dec 2008 15:20:53 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>>>I don't consider of the frequency of display important, but the fact
>>>that the value may unveil which mailbox the notification originated from,
>>>violating my privacy looking at the networks the notification may cross.
>>>      
>>>
>>I think you are asking for owner-token being used instead of owner-email.
>>    
>>
>The owner-token may solve the problem, but there is no technical reason
>to restrict owner-email not doing that as well, plus giving a mail
>address instead of letting the victim figure out who to ask.
>  
>
I agree. But saying that owner-email is or isn't related to :from is of 
no help in this case.

>>>That does not mean I would like to see ":from" influencing the
>>>owner.  All I would like to specify is WHO is responsible, so
>>>people using Sieve can be sure WHO to address for a changed
>>>owner address, should they care.  If we say
>>>
>>> The parameter value depends on the implementation
>>>      
>>>
>>So far so good.
>>    
>>
>I would be glad to see that included!
>  
>
>>> The only
>>> requirement is that the address reaches the owner of the script.
>>>      
>>>
>>I don't think this is even true. The only requirement is that the 
>>sysadmin operating the system that is running the Sieve engine can 
>>figure out which Sieve script (and for which user) generated a notification.
>>    
>>
>Now I am really confused.  I thought the owner would be the user the
>script belongs to, not the admin of the sending system.
>
Correct. But it doesn't mean that it is reachable via email ;-).
My point is that the requirement to be "reachable" might be too strong 
for some deployments.

>The admin should always be able to figure out abuse.
>
>Anyway: If we can agree on "it's implementation-dependent", we don't
>have to define further terms, and it addresses all my issues.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9Bnetr051493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 04:49:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB9BneaX051492; Tue, 9 Dec 2008 04:49:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout3.freenet.de (mout3.freenet.de [195.4.92.93]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9BnR0q051475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 9 Dec 2008 04:49:39 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.14] (helo=4.mx.freenet.de) by mout3.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #65) id 1LA15i-0002PE-SH; Tue, 09 Dec 2008 12:49:26 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:51934) by 4.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #68) id 1LA15i-0001dv-OA; Tue, 09 Dec 2008 12:49:26 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #72) id 1LA15h-0002b9-KH; Tue, 09 Dec 2008 12:49:25 +0100
Date: Tue, 09 Dec 2008 12:49:25 +0100
To: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >I don't consider of the frequency of display important, but the fact
> >that the value may unveil which mailbox the notification originated from,
> >violating my privacy looking at the networks the notification may cross.
> >  
> >
> I think you are asking for owner-token being used instead of owner-email.

The owner-token may solve the problem, but there is no technical reason
to restrict owner-email not doing that as well, plus giving a mail
address instead of letting the victim figure out who to ask.

> >That does not mean I would like to see ":from" influencing the
> >owner.  All I would like to specify is WHO is responsible, so
> >people using Sieve can be sure WHO to address for a changed
> >owner address, should they care.  If we say
> >
> >  The parameter value depends on the implementation
> >
> So far so good.

I would be glad to see that included!

> >  The only
> >  requirement is that the address reaches the owner of the script.
> >  
> >
> I don't think this is even true. The only requirement is that the 
> sysadmin operating the system that is running the Sieve engine can 
> figure out which Sieve script (and for which user) generated a notification.

Now I am really confused.  I thought the owner would be the user the
script belongs to, not the admin of the sending system.  The admin should
always be able to figure out abuse.

Anyway: If we can agree on "it's implementation-dependent", we don't
have to define further terms, and it addresses all my issues.

> I would not argue against having another example, that shows that 
> owner-email can be different.

Perhaps that's a good idea, despite showing something that depends on
the implementation, but at least people see it does!

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9BLKOq049834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 04:21:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB9BLKtd049833; Tue, 9 Dec 2008 04:21:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB9BL8LZ049826 for <[e-mail]>; Tue, 9 Dec 2008 04:21:19 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.191.252] (92.40.191.252.sub.mbb.three.co.uk [92.40.191.252])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 9 Dec 2008 11:21:06 +0000
Message-ID: <[e-mail]>
Date: Tue, 09 Dec 2008 11:20:50 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>>>I don't think Michael and I are going to agree on this, so I'd like to 
>>>hear from other WG participants.  Does anyone else have an opinion?
>>>      
>>>
>>owner-* is not something that's displayed often, so it's not important 
>>what's there as long as it's correct. In the case of From I think it's 
>>important to have the preferred form of the address, but owner-* is not 
>>displayed often enough.
>>
>>For this reason I think it's better to give the implementation all of 
>>the responsibility, and not even give the script author a chance to 
>>typo.
>>    
>>
>I think we talk about two issues here: Do we need more text to describe
>the parameter value for owner? Barry says no, I say yes.
>  
>
I am largely with Barry on this. See below.

>The next is: Who may influence the value?
>
>We agree on so far is that ":from" does not set the owner unconditionally,
>and not even on the condition it is accepted as sender for sure.
>We further agree that sender and owner may differ.
>
>The example contains the common case of owner and sender being equal
>and I want to make sure that people reading the text know for sure
>that's not a fixed rule.  The value may be any other address as well,
>as long as it belongs to the owner.
>
>I don't consider of the frequency of display important, but the fact
>that the value may unveil which mailbox the notification originated from,
>violating my privacy looking at the networks the notification may cross.
>  
>
I think you are asking for owner-token being used instead of owner-email.

>That does not mean I would like to see ":from" influencing the
>owner.  All I would like to specify is WHO is responsible, so
>people using Sieve can be sure WHO to address for a changed
>owner address, should they care.  If we say
>
>  The parameter value depends on the implementation
>
So far so good.

>  and may or may
>  not be related to the sender of the notification message.
>
But it is *always* related to the sender of the notification in some way.

>  The only
>  requirement is that the address reaches the owner of the script.
>  
>
I don't think this is even true. The only requirement is that the 
sysadmin operating the system that is running the Sieve engine can 
figure out which Sieve script (and for which user) generated a notification.

>all my issues would be addressed, because it defines who is responsible
>and that I can not expect ":from" to hide my identity, but that I
>must look at what the implementation has to offer, and it allows the
>implementation to use e.g. encrypted owner addresses or anything else.
>  
>

I would not argue against having another example, that shows that 
owner-email can be different.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB71FEnA044852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2008 18:15:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB71FE4U044851; Sat, 6 Dec 2008 18:15:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB71F1qU044840 for <[e-mail]>; Sat, 6 Dec 2008 18:15:12 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 6 Dec 2008 17:14:59 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 06 Dec 2008 17:14:57 -0800 (PST)
Date: Sat, 06 Dec 2008 17:14:48 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
In-reply-to: "Your message dated Fri, 05 Dec 2008 20:48:51 +0100" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Barry Leiba writes:
> > I don't think Michael and I are going to agree on this, so I'd like to
> > hear from other WG participants.  Does anyone else have an opinion?

> owner-* is not something that's displayed often, so it's not important
> what's there as long as it's correct. In the case of From I think it's
> important to have the preferred form of the address, but owner-* is not
> displayed often enough.

> For this reason I think it's better to give the implementation all of
> the responsibility, and not even give the script author a chance to
> typo.

+1

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB60iCaW065140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 17:44:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB60iC8C065139; Fri, 5 Dec 2008 17:44:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB60iBFn065133 for <[e-mail]>; Fri, 5 Dec 2008 17:44:11 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id A7D153A69CE; Fri,  5 Dec 2008 16:44:15 -0800 (PST)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-sieve-mime-loop (Sieve Email Filtering:  MIME part Tests, Iteration, Extraction, Replacement and  Enclosure) to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri,  5 Dec 2008 16:44:15 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Sieve Mail Filtering Language WG
 
(sieve) to consider the following document:

- 'Sieve Email Filtering: MIME part Tests, Iteration, Extraction, 
   Replacement and Enclosure '
   <draft-ietf-sieve-mime-loop-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2008-12-19. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-08.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14462&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5Kbeaf054078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 13:37:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB5KbdGh054077; Fri, 5 Dec 2008 13:37:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout3.freenet.de (mout3.freenet.de [195.4.92.93]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5KbRTj054061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 5 Dec 2008 13:37:39 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.19] (helo=9.mx.freenet.de) by mout3.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #65) id 1L8hQU-0004cw-C0 for [e-mail]; Fri, 05 Dec 2008 21:37:26 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:51280) by 9.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #68) id 1L8hQU-0006r7-BJ for [e-mail]; Fri, 05 Dec 2008 21:37:26 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #72) id 1L8hQT-0006EA-HF for [e-mail]; Fri, 05 Dec 2008 21:37:25 +0100
Date: Fri, 05 Dec 2008 21:37:25 +0100
To: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > I don't think Michael and I are going to agree on this, so I'd like to 
> > hear from other WG participants.  Does anyone else have an opinion?

> owner-* is not something that's displayed often, so it's not important 
> what's there as long as it's correct. In the case of From I think it's 
> important to have the preferred form of the address, but owner-* is not 
> displayed often enough.
>
> For this reason I think it's better to give the implementation all of 
> the responsibility, and not even give the script author a chance to 
> typo.

I think we talk about two issues here: Do we need more text to describe
the parameter value for owner? Barry says no, I say yes.

The next is: Who may influence the value?

We agree on so far is that ":from" does not set the owner unconditionally,
and not even on the condition it is accepted as sender for sure.
We further agree that sender and owner may differ.

The example contains the common case of owner and sender being equal
and I want to make sure that people reading the text know for sure
that's not a fixed rule.  The value may be any other address as well,
as long as it belongs to the owner.

I don't consider of the frequency of display important, but the fact
that the value may unveil which mailbox the notification originated from,
violating my privacy looking at the networks the notification may cross.

That does not mean I would like to see ":from" influencing the
owner.  All I would like to specify is WHO is responsible, so
people using Sieve can be sure WHO to address for a changed
owner address, should they care.  If we say

  The parameter value depends on the implementation and may or may
  not be related to the sender of the notification message.  The only
  requirement is that the address reaches the owner of the script.

all my issues would be addressed, because it defines who is responsible
and that I can not expect ":from" to hide my identity, but that I
must look at what the implementation has to offer, and it allows the
implementation to use e.g. encrypted owner addresses or anything else.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5JmpwP051840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 12:48:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB5JmpB7051839; Fri, 5 Dec 2008 12:48:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5JmcHC051825 for <[e-mail]>; Fri, 5 Dec 2008 12:48:50 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id B8EA84ACA8; Fri,  5 Dec 2008 20:48:37 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.5) with esmtp id 1228506517-84809-1/6/10 for [e-mail]; Fri, 5 Dec 2008 20:48:37 +0100
Message-Id: <[e-mail]>
Date: Fri, 5 Dec 2008 20:48:51 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Barry Leiba writes:
> I don't think Michael and I are going to agree on this, so I'd like to 
> hear from other WG participants.  Does anyone else have an opinion?

owner-* is not something that's displayed often, so it's not important 
what's there as long as it's correct. In the case of From I think it's 
important to have the preferred form of the address, but owner-* is not 
displayed often enough.

For this reason I think it's better to give the implementation all of 
the responsibility, and not even give the script author a chance to 
typo.

My two cents.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5IK28k046778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 11:20:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB5IK2VO046777; Fri, 5 Dec 2008 11:20:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5IJxaa046760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 5 Dec 2008 11:20:01 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB5IJUWW017807 for <[e-mail]>; Fri, 5 Dec 2008 13:19:30 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB5IJxjd156328 for <[e-mail]>; Fri, 5 Dec 2008 13:19:59 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB5IJVpK028011 for <[e-mail]>; Fri, 5 Dec 2008 13:19:31 -0500
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB5IJVaj027974; Fri, 5 Dec 2008 13:19:31 -0500
Received: from Uranus-009002090249.watson.ibm.com ([9.2.90.249]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1228501199.3211; Fri, 05 Dec 2008 13:19:59 -0400
Date: Fri, 05 Dec 2008 13:19:56 -0500
From: Barry Leiba <[e-mail]>
To: [e-mail]
cc: Michael Haardt <[e-mail]>
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> >   It is up to the implementation if ":from" sets the parameter value.
>>
>> Absolutely not.
>> It is critical that the value represent the *owner* of the script, and that is
>> the *only* criterion that's relevant.  The "from" might or might not be the
>> same  as the owner, and has no direct bearing on this.
>
> If the owner has multiple addresses, he may want to use a certain one.
> Do I get you right in that the choice MUST be made outside Sieve and
> the implementation MUST NOT use the value of ":from" for a hint?
>
> If so:
>
>   The sender address specified by ":from" MUST NOT set the parameter
>   value, the value MUST be set by the implementation to the owner of
>   the script.
>
> That would be consistent with the choice of the token, but as you can
> see from my first interpretation, something needs to be said about this.

I'm not saying that the implementation should or should not use ":from" to set 
this.  I'm saying that the ownership of the script and what to put in the owner-* 
parameter(s) is known only to the implementation, and that we can give NO advice 
on this other than to say, as we have, that it's a value that can be used to 
contact the owner.

I don't think Michael and I are going to agree on this, so I'd like to hear from 
other WG participants.  Does anyone else have an opinion?

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5He2i9045062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 10:40:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB5He2vJ045061; Fri, 5 Dec 2008 10:40:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [195.4.92.90]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5HdoMQ045040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 5 Dec 2008 10:40:01 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.27] (helo=17.mx.freenet.de) by mout0.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #65) id 1L8eeb-0007hl-0N; Fri, 05 Dec 2008 18:39:49 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:43969) by 17.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #68) id 1L8eea-0000XL-Vp; Fri, 05 Dec 2008 18:39:48 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #72) id 1L8eea-0006Ak-D8; Fri, 05 Dec 2008 18:39:48 +0100
Date: Fri, 05 Dec 2008 18:39:48 +0100
To: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > I disagree and would appreciate adding
> >
> >   It is up to the implementation if ":from" sets the parameter value.
>
> Absolutely not.
> It is critical that the value represent the *owner* of the script, and that is 
> the *only* criterion that's relevant.  The "from" might or might not be the same 
> as the owner, and has no direct bearing on this.

If the owner has multiple addresses, he may want to use a certain one.
Do I get you right in that the choice MUST be made outside Sieve and
the implementation MUST NOT use the value of ":from" for a hint?

If so:

  The sender address specified by ":from" MUST NOT set the parameter
  value, the value MUST be set by the implementation to the owner of
  the script.

That would be consistent with the choice of the token, but as you can
see from my first interpretation, something needs to be said about this.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5GKLRv041304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 09:20:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB5GKLlZ041303; Fri, 5 Dec 2008 09:20:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5GKAXX041295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 5 Dec 2008 09:20:21 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB5GJeS7006903 for <[e-mail]>; Fri, 5 Dec 2008 11:19:40 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB5GK9GM188578 for <[e-mail]>; Fri, 5 Dec 2008 11:20:09 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB5GJfQL007532 for <[e-mail]>; Fri, 5 Dec 2008 11:19:41 -0500
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB5GJfPw007524; Fri, 5 Dec 2008 11:19:41 -0500
Received: from Uranus-009002090249.watson.ibm.com ([9.2.90.249]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1228494010.3168; Fri, 05 Dec 2008 11:20:10 -0400
Date: Fri, 05 Dec 2008 11:20:07 -0500
From: Barry Leiba <[e-mail]>
To: Michael Haardt <[e-mail]>
cc: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I disagree and would appreciate adding
>
>   It is up to the implementation if ":from" sets the parameter value.

Absolutely not.
It is critical that the value represent the *owner* of the script, and that is 
the *only* criterion that's relevant.  The "from" might or might not be the same 
as the owner, and has no direct bearing on this.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5GAHQR040776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 09:10:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB5GAH9F040775; Fri, 5 Dec 2008 09:10:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [195.4.92.91]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5GA500040755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 5 Dec 2008 09:10:17 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.17] (helo=7.mx.freenet.de) by mout1.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #65) id 1L8dFk-0001AW-4I; Fri, 05 Dec 2008 17:10:04 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:42200) by 7.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #68) id 1L8dFj-0005vC-Va; Fri, 05 Dec 2008 17:10:04 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #72) id 1L8dFh-00068F-Rr; Fri, 05 Dec 2008 17:10:01 +0100
Date: Fri, 05 Dec 2008 17:10:01 +0100
To: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Fine with me, but now it is required: Who is responsible for setting
> > that address in the owner-email? The implementation? The user? Is it
> > related to ":from"?
> >
> > Since the point is to identify the sender, I suppose the implementation
> > is responsible for the values of owner or token
>
> The point is not to identify the "sender"; it's to identify the owner of the 
> sieve script, and that's all made clear in section 2.7.1.  Only the 
> implementation knows how to do that.  I don't think there's more that needs to be 
> said there.

I disagree and would appreciate adding

  It is up to the implementation if ":from" sets the parameter value.

before the example in section 2.7.1.  That allows an implementation not
to do that, exposing the script owner, or allowing it if it can be sure
the information is correct, offering more privacy.  Either way, it says
the implementation is authoritative for setting the value.  I feel as
it is, it may be misunderstood, because in the example in section 3 the
owner is identical to the sender, but just coincidentally so.

It does not change the current semantics, but expresses what is obvious
to you and possibly not as obvious to somebody else.  The largest
misunderstanding about common sense is it being common, isn't it? ;)

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5FaP6E039061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 08:36:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB5FaP7W039060; Fri, 5 Dec 2008 08:36:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5FaEOY039031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 5 Dec 2008 08:36:25 -0700 (MST) (envelope-from [e-mail])
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB5FYm2b017961 for <[e-mail]>; Fri, 5 Dec 2008 08:34:48 -0700
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB5FaA3x118852 for <[e-mail]>; Fri, 5 Dec 2008 08:36:11 -0700
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB5FaAkC017453 for <[e-mail]>; Fri, 5 Dec 2008 08:36:10 -0700
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB5FaAEx017440; Fri, 5 Dec 2008 08:36:10 -0700
Received: from Uranus-009002090249.watson.ibm.com ([9.2.90.249]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1228491371.3151; Fri, 05 Dec 2008 10:36:11 -0400
Date: Fri, 05 Dec 2008 10:36:08 -0500
From: Barry Leiba <[e-mail]>
To: Michael Haardt <[e-mail]>
cc: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Fine with me, but now it is required: Who is responsible for setting
> that address in the owner-email? The implementation? The user? Is it
> related to ":from"?
>
> Since the point is to identify the sender, I suppose the implementation
> is responsible for the values of owner or token

The point is not to identify the "sender"; it's to identify the owner of the 
sieve script, and that's all made clear in section 2.7.1.  Only the 
implementation knows how to do that.  I don't think there's more that needs to be 
said there.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5FW9pI038723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 08:32:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB5FW9FM038722; Fri, 5 Dec 2008 08:32:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout4.freenet.de (mout4.freenet.de [195.4.92.94]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB5FVu41038707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 5 Dec 2008 08:32:08 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout4.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #65) id 1L8cep-0001x8-Mu; Fri, 05 Dec 2008 16:31:55 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:42623) by 11.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #68) id 1L8cep-0005Ly-M9; Fri, 05 Dec 2008 16:31:55 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #72) id 1L8ceo-000674-Pc; Fri, 05 Dec 2008 16:31:54 +0100
Date: Fri, 05 Dec 2008 16:31:54 +0100
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Changed in "2.7.1.  The Auto-Submitted header field":
>
>    The auto-notified Auto-Submitted field MUST include one or both of
>    the following parameters:

Fine with me, but now it is required: Who is responsible for setting
that address in the owner-email? The implementation? The user? Is it
related to ":from"?

Since the point is to identify the sender, I suppose the implementation
is responsible for the values of owner or token, but we should make
that clear.  An example for the owner could be the envelope recipient
of the triggering message (for those who can't imagine what the owner
might be).

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4KPw67073774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 13:25:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB4KPwZH073773; Thu, 4 Dec 2008 13:25:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4KPkTJ073765 for <[e-mail]>; Thu, 4 Dec 2008 13:25:57 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 18so3700758fkq.10 for <[e-mail]>; Thu, 04 Dec 2008 12:25:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=cP3PEVmJq0jxFuGxye8LSc1ppnUBt8zK9gwp+NLcg0Y=; b=bwgth3iaaF3AxHezNaUdwI6+KNF/qaeixIfyT4Bo17GvVKRx34lrVoIFj6xRQcHgYs 46YivV0cjz/zPuLT9Z9pFx5ZpyElNzZiPj+BBHQRzC7bnSZj3Ra4XRzt9Q1QA64LtTQh OTo+13cbkWWONyIp1Gndw+KzP/Nfjs+GqCaLc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=axKWc2tRiv2nGE6ASO08JK5KElL0YrkXPCGcTQvox9y6YlBe811pCgsOxiFsVW5wwl 8UKkuWjJSuVnYW6EHgV5TOXClYp02W5Ko3UFDec/Nu+JNaxDf/yUdTAeWXkSVr+e+rZu S0ppvRMZKAMdU5hpgmXwiVfbV0cXJZzHJ/9k8=
Received: by 10.181.198.10 with SMTP id a10mr5154375bkq.120.1228422345108; Thu, 04 Dec 2008 12:25:45 -0800 (PST)
Received: by 10.181.9.9 with HTTP; Thu, 4 Dec 2008 12:25:45 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 4 Dec 2008 20:25:45 +0000
From: "Robert Burrell Donkin" <[e-mail]>
To: [e-mail]
Subject: draft-freed-sieve-in-xml status?
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

i note that http://tools.ietf.org/html/draft-freed-sieve-in-xml-01
expired on August 28, 2008 but i cannot find a new draft. what's the
current status of this draft?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4GrbbS056516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 09:53:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB4Grbm7056515; Thu, 4 Dec 2008 09:53:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4GrQLD056494 for <[e-mail]>; Thu, 4 Dec 2008 09:53:37 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id A10804ACA1; Thu,  4 Dec 2008 17:53:25 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1228409604-51002-1/6/40 for [e-mail]; Thu, 4 Dec 2008 17:53:24 +0100
Message-Id: <[e-mail]>
Date: Thu, 4 Dec 2008 17:53:36 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Fine stuff.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4GbTs9055492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 09:37:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB4GbT49055491; Thu, 4 Dec 2008 09:37:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4GbH8Q055474 for <[e-mail]>; Thu, 4 Dec 2008 09:37:28 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.246.29] (92.40.246.29.sub.mbb.three.co.uk [92.40.246.29])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 4 Dec 2008 16:37:13 +0000
Message-ID: <[e-mail]>
Date: Thu, 04 Dec 2008 16:36:55 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Barry Leiba wrote:

> I've just posted a final version of draft-ietf-sieve-notify-mailto.  
> It resolves all the last-call and IESG issues, including Cullen's 
> DISCUSS position, which he should be clearing when he reviews this 
> version.
>
> There are some editorial changes to fix some nits and some old 
> references.
> The substantive changes are these:
>
> Changed in "2.7.1.  The Auto-Submitted header field":
>
>   The auto-notified Auto-Submitted field MUST include one or both of
>   the following parameters:
>
> This makes at least one of the "owner-*" parameters required, so that 
> we can be sure that an accidental recipient of notification messages 
> will have a way to contact the sending domain and get the problem fixed.

I think this is needed in order to comply with the traceability 
requirement specified in the Sieve notify document.

> Added to "5.  Security Considerations":
>
>   Email addresses specified as recipients of notifications might not be
>   owned by the entity that owns the Sieve script.  As a result, a
>   notification recipient could wind up as the target of unwanted
>   notifications, either through intent (using scripts to mount a mail-
>   bomb attack) or by accident (an address was mistyped or has been
>   reassigned).  The situation is arguably no worse than any other in
>   which a recipient gets unwanted email, and some of the same
>   mechanisms can be used in this case.  But those deploying this
>   extension have to be aware of the potential extra problems here,
>   where scripts might be created through means that do not adequately
>   validate email addresses, and such scripts might then be forgotten
>   and left to run indefinitely.
>
>   In particular, note that the Auto-Submitted header field is required
>   to include a value that a recipient can use when contacting the
>   source domain of the notification message (see Section 2.7.1).  That
>   value will allow the domain to track down the script's owner and have
>   the script corrected or disabled.  Domains that enable this extension
>   MUST be prepared to respond to such complaints, in order to limit the
>   damage caused by a faulty script.
>
>   Problems can also show up if notification messages are sent to a
>   gateway into another service, such as SMS.  Information from the
>   email message is often lost in the gateway translation, and in this
>   case critical information needed to avoid loops, to contact the
>   script owner, and to resolve other problems might be lost.
>   Developers of email gateways should consider these issues, and try to
>   preseve as much information as possible, including what appears in
>   email trace headers and Auto-Submitted.
>
>
> Please comment quickly if you have a problem with any of this.  
> Otherwise, the new draft will go through with these changes.

This looks good to me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4F7P4F048807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 08:07:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB4F7Pka048806; Thu, 4 Dec 2008 08:07:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4F7Esj048786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 4 Dec 2008 08:07:25 -0700 (MST) (envelope-from [e-mail])
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB4F5uMZ002088 for <[e-mail]>; Thu, 4 Dec 2008 08:05:56 -0700
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB4F72fM094766 for <[e-mail]>; Thu, 4 Dec 2008 08:07:03 -0700
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB4F72I5026110 for <[e-mail]>; Thu, 4 Dec 2008 08:07:02 -0700
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB4F6wsL025711 for <[e-mail]>; Thu, 4 Dec 2008 08:06:59 -0700
Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1228403219.2946; Thu, 04 Dec 2008 10:06:59 -0400
Date: Thu, 04 Dec 2008 10:06:57 -0500
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: draft-ietf-sieve-notify-mailto-10.txt
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've just posted a final version of draft-ietf-sieve-notify-mailto.  It resolves 
all the last-call and IESG issues, including Cullen's DISCUSS position, which he 
should be clearing when he reviews this version.

There are some editorial changes to fix some nits and some old references.
The substantive changes are these:

Changed in "2.7.1.  The Auto-Submitted header field":

   The auto-notified Auto-Submitted field MUST include one or both of
   the following parameters:

This makes at least one of the "owner-*" parameters required, so that we can be 
sure that an accidental recipient of notification messages will have a way to 
contact the sending domain and get the problem fixed.


Added to "5.  Security Considerations":

   Email addresses specified as recipients of notifications might not be
   owned by the entity that owns the Sieve script.  As a result, a
   notification recipient could wind up as the target of unwanted
   notifications, either through intent (using scripts to mount a mail-
   bomb attack) or by accident (an address was mistyped or has been
   reassigned).  The situation is arguably no worse than any other in
   which a recipient gets unwanted email, and some of the same
   mechanisms can be used in this case.  But those deploying this
   extension have to be aware of the potential extra problems here,
   where scripts might be created through means that do not adequately
   validate email addresses, and such scripts might then be forgotten
   and left to run indefinitely.

   In particular, note that the Auto-Submitted header field is required
   to include a value that a recipient can use when contacting the
   source domain of the notification message (see Section 2.7.1).  That
   value will allow the domain to track down the script's owner and have
   the script corrected or disabled.  Domains that enable this extension
   MUST be prepared to respond to such complaints, in order to limit the
   damage caused by a faulty script.

   Problems can also show up if notification messages are sent to a
   gateway into another service, such as SMS.  Information from the
   email message is often lost in the gateway translation, and in this
   case critical information needed to avoid loops, to contact the
   script owner, and to resolve other problems might be lost.
   Developers of email gateways should consider these issues, and try to
   preseve as much information as possible, including what appears in
   email trace headers and Auto-Submitted.


Please comment quickly if you have a problem with any of this.  Otherwise, the 
new draft will go through with these changes.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4ExwWt048243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 07:59:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB4ExwTS048242; Thu, 4 Dec 2008 07:59:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB4ExwQm048235 for <[e-mail]>; Thu, 4 Dec 2008 07:59:58 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id BCB7D3A6B15; Thu,  4 Dec 2008 07:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-notify-mailto-10.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  4 Dec 2008 07:00:01 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Notification Mechanism: mailto
	Author(s)       : B. Leiba, M. Haardt
	Filename        : draft-ietf-sieve-notify-mailto-10.txt
	Pages           : 17
	Date            : 2008-12-04

This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-notify-mailto-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2HpIcr098651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 10:51:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2HpI8h098650; Tue, 2 Dec 2008 10:51:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2Hp7gY098639 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <[e-mail]>; Tue, 2 Dec 2008 10:51:17 -0700 (MST) (envelope-from [e-mail])
X-IronPort-AV: E=Sophos;i="4.33,702,1220227200";  d="scan'208";a="54962980"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2008 17:51:06 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mB2Hp6ds020444; Tue, 2 Dec 2008 09:51:06 -0800
Received: from [10.0.1.186] (sjc-vpn3-7.cisco.com [10.21.64.7]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mB2Hp67b021183; Tue, 2 Dec 2008 17:51:06 GMT
Cc: "Arnt Gulbrandsen" <[e-mail]>, <[e-mail]>, "Michael Haardt" <[e-mail]>
Message-Id: <[e-mail]>
From: Cullen Jennings <[e-mail]>
To: "Ned Freed" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Date: Tue, 2 Dec 2008 09:52:41 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1724; t=1228240266; x=1229104266; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Cullen=20Jennings=20<[e-mail]> |Subject:=20Re=3A=20[Fwd=3A=20DISCUSS=3A=20draft-ietf-sieve -notify-mailto] |Sender:=20; bh=uEMF7uRXzF//QI9oqNuLVauRdeWoUVKD5511XdBW4Lg=; b=ujmLXf5BXlL0eChFy14Fz8kPbIbo4hKFnMRDZQtYNx30zOPPEcT0x3+J5c 9GI4Mv9T08V+Rb6wNPPWLOTtyUcA8sb34ykVwNtH5mhkkOIYP+80+j4Xm9iO Yah0JiRP6K;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Dec 2, 2008, at 8:57 , Ned Freed wrote:

>
> > Michael Haardt writes:
> > > The problem does exist already, but so far answering solved it,
> > > because the messages were sent by mistake and people don't like
> > > violating their privacy by mistake.
>
> > Yeah... do we have a reasonable probability that someone  
> responsible can
> > be reached by answering the notification, though?
>
> That's exactly the problem. The case where notify mailto:, redirect,  
> or
> whatever is used by an individual user in their Sieve script  
> attached to their
> primary email account doesn't concern me. The case that's a problem  
> is where it
> is some automated service of some sort, some kind of  folder- 
> attached script
> created as part of some LEMONADE setup, an autoforwarder setup, etc.  
> Most of
> these thngs can and usually do have addresses associated with then for
> reporting problems, but they tend to be monitored sporadically if at  
> all. And
> there can be some, like a folder script, where the person  
> responsible may not
> be able to easily figure out where the problem is to correct it.
>
> > We do for mailto and I think we do for XMPP, but Cullen mentioned  
> SMS,
> > and I'm not at all sure about SMS.
>
> IMO notify sms: is out of scope. But a lot of SMS goes out using email
> as an intermediary. That case is arguably in scope, although I suspect
> that the gateway effects will be  impossible to overcome.
>
>                                 Ned
>

When I said SMS, I was actually thinking the example in document where  
an email is sent to a SMS gateway. From the end users perspective,  
they got an SMS and want to know how to stop it.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2H4iNL096210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 10:04:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2H4iEK096209; Tue, 2 Dec 2008 10:04:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2H4Xuv096201 for <[e-mail]>; Tue, 2 Dec 2008 10:04:44 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 2 Dec 2008 09:04:31 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 02 Dec 2008 09:04:28 -0800 (PST)
Date: Tue, 02 Dec 2008 08:57:15 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
In-reply-to: "Your message dated Tue, 02 Dec 2008 11:48:28 +0100" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Michael Haardt <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Michael Haardt writes:
> > The problem does exist already, but so far answering solved it,
> > because the messages were sent by mistake and people don't like
> > violating their privacy by mistake.

> Yeah... do we have a reasonable probability that someone responsible can
> be reached by answering the notification, though?

That's exactly the problem. The case where notify mailto:, redirect, or
whatever is used by an individual user in their Sieve script attached to their
primary email account doesn't concern me. The case that's a problem is where it
is some automated service of some sort, some kind of  folder-attached script
created as part of some LEMONADE setup, an autoforwarder setup, etc. Most of
these thngs can and usually do have addresses associated with then for
reporting problems, but they tend to be monitored sporadically if at all. And
there can be some, like a folder script, where the person responsible may not
be able to easily figure out where the problem is to correct it.

> We do for mailto and I think we do for XMPP, but Cullen mentioned SMS,
> and I'm not at all sure about SMS.

IMO notify sms: is out of scope. But a lot of SMS goes out using email
as an intermediary. That case is arguably in scope, although I suspect
that the gateway effects will be  impossible to overcome.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2EcZM2088691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 07:38:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2EcZK9088690; Tue, 2 Dec 2008 07:38:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2EcN6e088671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 2 Dec 2008 07:38:34 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id mB2EcMp7037013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Tue, 2 Dec 2008 14:38:23 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: WGLC on draft-melnikov-sieve-imapext-metadata-04.tx
Date: Tue, 2 Dec 2008 06:38:21 -0800
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've reviewed metadata-06 and have no concerns.  -- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2BdUrJ077458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 04:39:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2BdUge077457; Tue, 2 Dec 2008 04:39:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2BdTPv077450 for <[e-mail]>; Tue, 2 Dec 2008 04:39:29 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id CCFA34AC22; Tue,  2 Dec 2008 12:39:27 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1228217967-51002-1/6/8 (5 recipients); Tue, 2 Dec 2008 12:39:27 +0100
Message-Id: <[e-mail]>
Date: Tue, 2 Dec 2008 12:39:36 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Cc: Michael Haardt <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> We do for mailto and I think we do for XMPP, but Cullen mentioned 
>> SMS, and I'm not at all sure about SMS.
>
> SMS is out of scope for this document.

Good point.

I'm inclined to simply push back, then: notify-mailto includes 
Auto-Submitted with owner-email, that's good enough for mailto.

(Btw, I like the MUST for originator identification in notify-12.)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2BZZFo077363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 04:35:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2BZZ4O077362; Tue, 2 Dec 2008 04:35:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2BZYYl077341 for <[e-mail]>; Tue, 2 Dec 2008 04:35:35 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 2 Dec 2008 11:35:33 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 02 Dec 2008 11:34:58 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]]
Content-Type: multipart/mixed; boundary="------------050904060007080007000904"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------050904060007080007000904
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This message didn't get to the archive, so I am forwarding it.


--------------050904060007080007000904
Content-Type: message/rfc822;
 name="Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.3v2) with LMTP; Mon, 01 Dec 2008 23:09:41 +0000 (GMT)
Received: from mauve.mrochek.com ([66.59.230.40]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Mon, 1 Dec 2008 23:09:40 +0000
X-SPF-Result: PASS rufus.isode.com: domain of mrochek.com designates 66.59.230.40 as permitted sender
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
 (PMDF V6.1-1 #35243) id <[e-mail]> for
 [e-mail]; Mon, 1 Dec 2008 15:09:36 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <[e-mail]>; Mon,
 01 Dec 2008 15:09:34 -0800 (PST)
Date: Mon, 01 Dec 2008 14:34:13 -0800 (PST)
From: [e-mail], [e-mail], [e-mail]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
In-reply-to: "Your message dated Mon, 01 Dec 2008 21:19:41 +0000"
 <[e-mail]>
Sender: Ned Freed <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT

> It seems like the draft should include a way for a recipricant of these
> notifies to tell the server to stop sending them. If someone accidentally fat
> fingers a phone number for a SMS notify in a sieve script, how will the poor
> users getting all the SMS ever stop them?

I'm afraid this time I have to agree with Cullen - such a mechanism is indeed
needed and would be very useful.

Kristin Hubner, Chris Newman and I tossed around various approaches and this is
what we came up with.

(1) Include a cancellation token and cancellation address as a parameter on
    the auto-submitted header field.

(2) If the recipient gets the message in error, send a message containing the
    cancellation parameter and a reason for cancellation to the cancellation
    address.

(3) Upon receipt of the cancellation request, the receiving system validates
    the cancellation token (exactly how this is done would be
    implemenation-specific). The message is silently dropped if the
    validation fails.

(4) If validation succeeds the system records a tuple of the sieve owner,
    the destination address who doesn't want to get any more of these
    messages, the reason, and the current time. A response is also sent to the
    requestor saying the cancellation is effect.

(5) The system periodically scans or otherwise prunes its cancellation list,
    removing cancellation requests that have timed out. The timeout period
    is implementation specific but we'll need to decide on a minimum, which
    probably should be something like a week.

(6) An implementation may optionally include a timeout value as part of the
    cancellation token. If a valid cancellation requests comes in for a
    timed out cancellation token a response saying it wasn't honored should
    be sent.

Notify mailto processing then needs to be changed to check the cancellation
list. An error occurs if the sieve owner and notification destination match an
entry on the list. The error should include the reason given by the recipient
for not wanting the notification any more. As always, a sieve error converts
the script into a keep and notifies the sieve owner in an
implementation-specific way.

We think this a reasonable technical solution, although of course this is far
from a precise specification.

The issue here is that this isn't a problem specific to notify mailto: and
coming up with a specific solution for this one case is inappropriate. Just as
one exmaple, such a mechanism could be used to deal with errant MTA-level
autoforwards and Sieve redirects. It is therefore inappropriate to put this in
the notify mailto document. It needs to be defined more generally, and I for
one would be happy to work on defining this as a more general mechanism.

We note in passing that implementation of this capability is actually quite
similar to implementation of Sieve vacation's duplication supression. In our
implementation at least we believe the same underlying facility can be used for
both.

We therefore think that the way to handle this is to define such a mechanism in
a completely new specification, one which can potentially be
referenced/included by any future facility that sends messages automatically. 
And given how many existing facilities can cause this problem, notify mailto:
isn't going to create much more of  a problem. So we believe the right thing to
do is get started on this work right away but not hold up notify mailto: for
it.

			Ned, Kristin, and Chris

--------------050904060007080007000904--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2BUf2v077179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 04:30:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2BUfKb077178; Tue, 2 Dec 2008 04:30:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2BUTUE077169 for <[e-mail]>; Tue, 2 Dec 2008 04:30:40 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 2 Dec 2008 11:30:28 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 02 Dec 2008 11:29:52 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail], Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> Michael Haardt writes:
>
>> The problem does exist already, but so far answering solved it, 
>> because the messages were sent by mistake and people don't like 
>> violating their privacy by mistake.
>
> Yeah... do we have a reasonable probability that someone responsible 
> can be reached by answering the notification, though?
>
> We do for mailto and I think we do for XMPP, but Cullen mentioned SMS, 
> and I'm not at all sure about SMS.

SMS is out of scope for this document. (And if there is a mail-to-SMS 
gateway, it is responsibility of such gateway to provide correct 
functionality)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2AmWhg075160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 03:48:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2AmWvB075159; Tue, 2 Dec 2008 03:48:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2AmK8A075148 for <[e-mail]>; Tue, 2 Dec 2008 03:48:31 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 05FE54AC22; Tue,  2 Dec 2008 11:48:19 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1228214899-51002-1/6/7 (3 recipients); Tue, 2 Dec 2008 11:48:19 +0100
Message-Id: <[e-mail]>
Date: Tue, 2 Dec 2008 11:48:28 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Cc: Michael Haardt <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt writes:
> The problem does exist already, but so far answering solved it, 
> because the messages were sent by mistake and people don't like 
> violating their privacy by mistake.

Yeah... do we have a reasonable probability that someone responsible can 
be reached by answering the notification, though?

We do for mailto and I think we do for XMPP, but Cullen mentioned SMS, 
and I'm not at all sure about SMS.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB27p4xL065455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 00:51:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB27p45L065454; Tue, 2 Dec 2008 00:51:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout3.freenet.de (mout3.freenet.de [195.4.92.93]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB27oqdY065442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 2 Dec 2008 00:51:03 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout3.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #65) id 1L7Q1w-0003jh-QA; Tue, 02 Dec 2008 08:50:48 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:41801) by 10.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #68) id 1L7Q1w-0002Wn-Io; Tue, 02 Dec 2008 08:50:48 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #72) id 1L7Q1s-0001kh-7f; Tue, 02 Dec 2008 08:50:44 +0100
Date: Tue, 02 Dec 2008 08:50:44 +0100
To: [e-mail], [e-mail], [e-mail]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Isn't this really a generic issue, not specific to sieve?

It is.  If anything at all, it applies to any mechanism that sends
messages or asks to send them, that is not just Sieve notifications,
but mail, SMS services etc. in general.

In discussions, we observed (Sieve) notifications have some properties
of redirects and this topic is no exception.

How can I protect myself from misredirected mails? I have had that
problem a few times now, because some people simply can't spell their
main address right, redirect to [e-mail] and the like.
One time I answered and told a member of a political part their internal
reports were rather boring to me.  No answer, but the mails stopped. ;)
I called one admin and told him his perl installation lacked a specific
module and his cron job might work better if he installed it.  He took
it with humour once he knew I did not break into his system, and fixed
the mail address for cron mails, too.

The problem does exist already, but so far answering solved it, because
the messages were sent by mistake and people don't like violating their
privacy by mistake.  The message origin is usually quite clear and we
need to ensure it stays that way, that's why draft-ietf-sieve-notify-12
(the notification framework) says in section 3.3:

   In order to minimize/prevent forgery of the author value,
   implementations SHOULD impose restrictions on what values can
   specified in a ":from" parameter.  For example, an implementation may
   restrict this value to be a member of a list of known author
   addresses or to belong to a particular domain.  It is suggested that
   values which don't satisfy such restrictions simply be ignored rather
   than causing the notify action to fail.

Spam, including SMS spam, is a different thing, because the sender tries
to hide.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB1MRJGe043681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2008 15:27:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB1MRJT1043680; Mon, 1 Dec 2008 15:27:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB1MR7G2043657 for <[e-mail]>; Mon, 1 Dec 2008 15:27:18 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 2B5084AC4B; Mon,  1 Dec 2008 23:27:06 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1228170422-51002-1/6/5 (2 recipients); Mon, 1 Dec 2008 23:27:02 +0100
Message-Id: <[e-mail]>
Date: Mon, 1 Dec 2008 23:27:10 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Cullen Jennings <[e-mail]>, [e-mail]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Isn't this really a generic issue, not specific to sieve?

We can discuss how to solve it here and now, but IMO such a solution 
should not be be published in a document titled "Sieve So and So".

My suggestion for solving it would be to include some sort of key or 
hash in the Auto-Submitted field which uniquely identifies the 
(script,user,statement) triple.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB1LKfdj041279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2008 14:20:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB1LKf8e041278; Mon, 1 Dec 2008 14:20:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB1LKTvD041265 for <[e-mail]>; Mon, 1 Dec 2008 14:20:40 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.149.140] (92.40.149.140.sub.mbb.three.co.uk [92.40.149.140])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 1 Dec 2008 21:20:27 +0000
Message-ID: <[e-mail]>
Date: Mon, 01 Dec 2008 21:19:41 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Content-Type: multipart/mixed; boundary="------------080503000401060007020600"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------080503000401060007020600
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



--------------080503000401060007020600
Content-Type: message/rfc822;
 name="DISCUSS: draft-ietf-sieve-notify-mailto"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="DISCUSS: draft-ietf-sieve-notify-mailto"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.3v2) with LMTP; Mon, 01 Dec 2008 21:18:59 +0000 (GMT)
Received: from merlot.tools.ietf.org ([194.146.105.14]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Mon, 1 Dec 2008 21:18:58 +0000
Received: from mail.ietf.org ([2001:1890:1112:1::20]:48973)
	by merlot.tools.ietf.org with esmtp (Exim 4.69)
	(envelope-from <[e-mail]>)
	id 1L7GAL-0000Rd-Jp; Mon, 01 Dec 2008 22:18:49 +0100
Received: by core3.amsl.com (Postfix, from userid 30)
	id 29A033A6BAD; Mon,  1 Dec 2008 13:18:46 -0800 (PST)
From: Cullen Jennings <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  1 Dec 2008 13:18:47 -0800 (PST)
X-SA-Exim-Connect-IP: 2001:1890:1112:1::20
X-SA-Exim-Rcpt-To: [e-mail], [e-mail]
X-SA-Exim-Mail-From: [e-mail]
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
	merlot.tools.ietf.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00,NO_RELAYS
	autolearn=no version=3.2.5
Subject: DISCUSS: draft-ietf-sieve-notify-mailto 
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org)

Discuss:
It seems like the draft should include a way for a recipricant of these notifies to tell the server to stop sending them. If someone accidentally fat fingers a phone number for a SMS notify in a sieve script, how will the poor users getting all the SMS ever stop them?



--------------080503000401060007020600--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB1BTx0Q092683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2008 04:30:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB1BTxUr092682; Mon, 1 Dec 2008 04:29:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB1BTxVH092674 for <[e-mail]>; Mon, 1 Dec 2008 04:29:59 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id BF1BC3A6A7A; Mon,  1 Dec 2008 03:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  1 Dec 2008 03:30:01 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-03.txt
	Pages           : 50
	Date            : 2008-12-01

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-managesieve-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--