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

From: "Robert Burrell Donkin" <[email-masked]>
Date: Thu, 4 Dec 2008 20:25:45 +0000

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 09 Dec 2008 15:36:46 +0000

Hi Robert,

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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Tue, 9 Dec 2008 17:56:21 +0000

On Tue, Dec 9, 2008 at 3:36 PM, Alexey Melnikov
<[email-masked]> wrote:
> 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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Dec 2008 11:01:27 +0000

> is there a (standard) copy of the schema available under a reasonable

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

- robert

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Dec 2008 11:41:44 +0000

> is there a (standard) copy of the schema available under a reasonable

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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Dec 2008 11:55:52 +0000

> is there a (standard) copy of the schema available under a reasonable

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

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Dec 2008 09:46:19 -0800 (PST)

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

> annotations and the substantive xml. could anyone explain this design

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

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Dec 2008 10:02:36 -0800 (PST)

> 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

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Dec 2008 10:06:20 -0800 (PST)

> 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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Dec 2008 20:35:28 +0000

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

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

> 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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Dec 2008 20:39:54 +0000

> 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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Dec 2008 21:04:59 +0000

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

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

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

> 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

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Dec 2008 10:20:53 -0800 (PST)

> 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

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

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Dec 2008 13:52:27 -0800 (PST)

> 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

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

> for two broad classes of GUI - generative and web service backed

That may be your opinion. i quite simply disagree.

> were these annotations based on any existing standard?

Nope.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Dec 2008 13:56:15 -0800 (PST)

> 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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Dec 2008 22:24:52 +0000

> here is interoperability, not compliance.

however, AFACT the charter of this group does include testing

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

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

> that's applied falls short of this.

yes

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

> supports it. Just what I need: More beta software in my life.)

:-)

> laywers. We don't need any more, so I'm taking no position on any of this

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

> consider such matters in any case.

does the IEFT require copyright assignment?

- robert

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sun, 14 Dec 2008 22:44:06 +0000

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

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

> That may be your opinion. i quite simply disagree.

what specifically are you disagreeing with?

>> were these annotations based on any existing standard?

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

- robert

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Dec 2008 13:59:42 -0800 (PST)

> recommendation. http://www.w3.org/TR/xml-infoset/ is the current

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.

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

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

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

> 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

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

> annotations in foreign vocabularies.

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

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 14 Dec 2008 20:04:46 -0800 (PST)

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

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

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

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

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

> rather than try to ensure that good implementations interoperate

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>

> 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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 15 Dec 2008 11:03:47 +0100

Ned Freed writes:
> 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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Mon, 15 Dec 2008 13:00:12 +0000

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

> more abstract approach, I'd be fine with that if there's a WG consensus to make

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.

> bound to be inconsistent in some way or other is much worse.

no, not restatement

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

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

> trying to get one of those done, but progress has been very slow.

providing that mail is interpreted sufficiently broadly, i agree

<snip>

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Dec 2008 13:25:18 +0000

Arnt Gulbrandsen wrote:

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 15 Dec 2008 14:59:10 +0100

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

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

---

From: Ned Freed <[email-masked]>
Date: Mon, 15 Dec 2008 09:18:48 -0800 (PST)

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 15 Dec 2008 13:35:03 -0500

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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Fri, 19 Dec 2008 18:54:25 +0000

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

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.

> makes no pretense of following the standard - and there are -  it's a real

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.

> 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

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

> 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

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.

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

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

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

> 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

---

From: "Robert Burrell Donkin" <[email-masked]>
Date: Sat, 20 Dec 2008 08:13:31 +0000

> that leads to, um, let's call them "discussions" between the implementor and

+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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Dec 2008 15:06:49 +0300

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

---

From: Ned Freed <[email-masked]>
Date: Sun, 28 Dec 2008 14:31:18 -0800 (PST)

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

> adopted, adding a normative description of the XML and making the

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.

> 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

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.

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

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Dec 2008 11:26:08 +0300

> to do it when the element structure is quite complex, but that's not the case
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 ;-).
> not going to pursue this.

Date: Mon, 29 Dec 2008 11:26:08 +0300
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>, Robert Burrell Donkin <[email-masked]>
CC: [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Sender: [email-masked]

> to do it when the element structure is quite complex, but that's not the case
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 ;-).
> not going to pursue this.

Date: Sun, 28 Dec 2008 14:31:18 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-freed-sieve-ihave-04.txt 
Date: Thu, 25 Dec 2008 09:45:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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

	Title           : Sieve Email Filtering: 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:     <[email-masked]>

--NextPart--

Date: Thu, 25 Dec 2008 16:53:17 +0300
From: Alexey Melnikov <[email-masked]>
To: SIEVE <[email-masked]>
Subject: WGLC on draft-ietf-sieve-notify-sip-message-00.txt
Sender: [email-masked]

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

Date: Thu, 25 Dec 2008 15:06:49 +0300
From: Alexey Melnikov <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
CC: Ned Freed <[email-masked]>, [email-masked]
Subject: How to get implementors involved  (was Re: draft-freed-sieve-in-xml status?)
Sender: [email-masked]

Date: Sat, 20 Dec 2008 08:13:31 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Arnt Gulbrandsen" <[email-masked]>, [email-masked], "Alexey Melnikov" <[email-masked]>
Sender: [email-masked]

+1

- robert

Date: Fri, 19 Dec 2008 18:54:25 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Alexey Melnikov" <[email-masked]>, [email-masked]
Sender: [email-masked]

intention != execution

- robert

Date: Wed, 17 Dec 2008 13:05:27 +0100
From: Magnus Westerlund <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: ABNF or example error in RFC 5228
Sender: [email-masked]

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

Subject: Re: ABNF or example error in RFC 5228
Date: Wed, 17 Dec 2008 11:30:01 +0000
From: Dave Cridland <[email-masked]>
To: Magnus Westerlund <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Subject: Re: ABNF or example error in RFC 5228
Date: Wed, 17 Dec 2008 11:18:26 +0000
From: Dave Cridland <[email-masked]>
To: Magnus Westerlund <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Wed, 17 Dec 2008 11:58:42 +0100
To: [email-masked], [email-masked]
Subject: Re: ABNF or example error in RFC 5228
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Michael

Date: Wed, 17 Dec 2008 10:56:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Magnus Westerlund <[email-masked]>
CC: [email-masked]
Subject: Re: ABNF or example error in RFC 5228
Sender: [email-masked]

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"]
>   ["[email-masked]", "[email-masked]"]' is true if either a To
>   header or Cc header of the input message contains either of the email
>   addresses "[email-masked]" or "[email-masked]".
>
>   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.
>  
>

Date: Wed, 17 Dec 2008 11:33:38 +0100
From: Magnus Westerlund <[email-masked]>
To: [email-masked]
Subject: ABNF or example error in RFC 5228
Sender: [email-masked]

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"]
   ["[email-masked]", "[email-masked]"]' is true if either a To
   header or Cc header of the input message contains either of the email
   addresses "[email-masked]" or "[email-masked]".

   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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-sieve-managesieve (A Protocol for  Remotely Managing Sieve Scripts) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Tue, 16 Dec 2008 08:52:11 -0800 (PST)
Sender: [email-masked]

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
[email-masked] mailing lists by 2008-12-30. Exceptionally, 
comments may be sent to [email-masked] 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-managesieve-05.txt 
Date: Tue, 16 Dec 2008 07:15:02 -0800 (PST)
Sender: [email-masked]

--NextPart

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

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

--NextPart--

Date: Tue, 16 Dec 2008 13:01:10 +0000
From: Alexey Melnikov <[email-masked]>
To: sieve mailing list <[email-masked]>
Subject: Re: Protocol Action: 'Sieve Notification Mechanism: mailto' to Proposed Standard
Sender: [email-masked]

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!

Date: Tue, 16 Dec 2008 09:26:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Lisa Dusseault <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: Re: ManageSIEVE review: conflating two functions
Sender: [email-masked]

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.

Date: Tue, 16 Dec 2008 09:21:42 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ManageSIEVE review: conflating two functions
Cc: Lisa Dusseault <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 15 Dec 2008 23:00:44 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Lisa Dusseault <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: ManageSIEVE review: conflating two functions
Sender: [email-masked]

--On Monday, December 15, 2008 11:44:19 AM -0800 Lisa Dusseault 
<[email-masked]> 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-managesieve-04.txt 
Date: Mon, 15 Dec 2008 16:00:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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

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

--NextPart--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, sieve mailing list <[email-masked]>, sieve chair <[email-masked]>
Subject: Protocol Action: 'Sieve Notification Mechanism: mailto'  to Proposed Standard 
Date: Mon, 15 Dec 2008 15:31:29 -0800 (PST)
Sender: [email-masked]

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.

Date: Mon, 15 Dec 2008 21:51:27 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, [email-masked]
Subject: Re: ManageSIEVE review: conflating two functions
Sender: [email-masked]

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

Date: Mon, 15 Dec 2008 21:49:50 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, [email-masked]
Subject: Re: ManageSIEVE review: conflating two functions
Sender: [email-masked]

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

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: ManageSIEVE review: conflating two functions
Date: Mon, 15 Dec 2008 12:02:47 -0800
Sender: [email-masked]

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

From: Lisa Dusseault <[email-masked]>
To: [email-masked]
Subject: ManageSIEVE review: conflating two functions
Date: Mon, 15 Dec 2008 11:44:19 -0800
Sender: [email-masked]

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

Date: Mon, 15 Dec 2008 13:35:03 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Ned Freed <[email-masked]>, Robert Burrell Donkin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Sender: [email-masked]

Date: Mon, 15 Dec 2008 09:18:48 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Robert Burrell Donkin <[email-masked]>, Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>
Sender: [email-masked]

				Ned

Date: Mon, 15 Dec 2008 17:26:21 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: Re: draft-freed-sieve-in-xml status?]
Sender: [email-masked]

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

Date: Mon, 15 Dec 2008 16:57:05 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?

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

Date: Mon, 15 Dec 2008 14:59:10 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Sender: [email-masked]

Arnt

Date: Mon, 15 Dec 2008 13:25:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Sender: [email-masked]

> current drafts passes IESG.

Date: Mon, 15 Dec 2008 13:00:12 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [email-masked]
Sender: [email-masked]

no, not restatement

again, i beg to differ

<snip>

- robert

Date: Mon, 15 Dec 2008 11:03:47 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Cc: Robert Burrell Donkin <[email-masked]>, Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>
Sender: [email-masked]

Arnt

Date: Sun, 14 Dec 2008 20:04:46 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

<snip>

				Ned

Date: Sun, 14 Dec 2008 13:59:42 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

Date: Sun, 14 Dec 2008 22:44:06 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [email-masked]
Sender: [email-masked]

huh?

- robert

Date: Sun, 14 Dec 2008 22:24:52 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: "Alexey Melnikov" <[email-masked]>, [email-masked]
Sender: [email-masked]

<snip>

yes

:-)

- robert

Date: Sun, 14 Dec 2008 13:56:15 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

Date: Sun, 14 Dec 2008 13:52:27 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

I think this is a wash.

Nope.

				Ned

Date: Sun, 14 Dec 2008 10:20:53 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

Date: Sun, 14 Dec 2008 21:04:59 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [email-masked]
Sender: [email-masked]

- robert

Date: Sun, 14 Dec 2008 20:39:54 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [email-masked]
Sender: [email-masked]

- robert

Date: Sun, 14 Dec 2008 20:35:28 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [email-masked]
Sender: [email-masked]

- robert

Date: Sun, 14 Dec 2008 10:06:20 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

				Ned

Date: Sun, 14 Dec 2008 10:02:36 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I don't know.

Yes, see above.

				Ned

Date: Sun, 14 Dec 2008 09:46:19 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
To: Robert Burrell Donkin <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

				Ned

Date: Sun, 14 Dec 2008 11:55:52 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Sender: [email-masked]

- robert

Date: Sun, 14 Dec 2008 11:41:44 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Sender: [email-masked]

- robert

Date: Sun, 14 Dec 2008 11:01:27 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Sender: [email-masked]

- robert

Date: Thu, 11 Dec 2008 11:53:09 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: A little sieve help
To: Patrick Baldwin <[email-masked]>
Cc: Aaron Stone <[email-masked]>, [email-masked]
Sender: [email-masked]

> 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-sip-message-00.txt 
Date: Thu, 11 Dec 2008 14:45:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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

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

--NextPart--

Date: Thu, 11 Dec 2008 13:50:20 -0500
From: Patrick Baldwin <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: [email-masked]
Subject: Re: A little sieve help
Sender: [email-masked]

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 

Subject: Re: A little sieve help
From: Aaron Stone <[email-masked]>
To: Patrick Baldwin <[email-masked]>
Cc: [email-masked]
Date: Wed, 10 Dec 2008 17:53:30 -0800
Sender: [email-masked]

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

Date: Wed, 10 Dec 2008 17:31:36 -0500
From: Patrick Baldwin <[email-masked]>
To: [email-masked]
Subject: A little sieve help
Sender: [email-masked]

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 

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Wed, 10 Dec 2008 10:30:21 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: sieveurl-list-scripts += [owner "/"]
Sender: [email-masked]

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

Date: Tue, 09 Dec 2008 18:16:11 +0000
From: Alexey Melnikov <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>, IETF Sieve WG <[email-masked]>
Subject: Re: managesieve: formats; :global; read-only; checkscript
Sender: [email-masked]

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

Date: Tue, 9 Dec 2008 17:56:21 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Subject: Re: draft-freed-sieve-in-xml status?
Cc: [email-masked]
Sender: [email-masked]

thanks

- robert

Date: Tue, 09 Dec 2008 15:36:46 +0000
From: Alexey Melnikov <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
CC: [email-masked]
Subject: Re: draft-freed-sieve-in-xml status?
Sender: [email-masked]

Hi Robert,

Date: Tue, 09 Dec 2008 15:20:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

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

Date: Tue, 09 Dec 2008 12:49:25 +0100
To: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Cc: [email-masked]
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 09 Dec 2008 11:20:50 +0000
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

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.

Date: Sat, 06 Dec 2008 17:14:48 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 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

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-sieve-mime-loop (Sieve Email Filtering:  MIME part Tests, Iteration, Extraction, Replacement and  Enclosure) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Fri,  5 Dec 2008 16:44:15 -0800 (PST)
Sender: [email-masked]

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
[email-masked] mailing lists by 2008-12-19. Exceptionally, 
comments may be sent to [email-masked] 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

Date: Fri, 05 Dec 2008 21:37:25 +0100
To: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 5 Dec 2008 20:48:51 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

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

Date: Fri, 05 Dec 2008 13:19:56 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
cc: Michael Haardt <[email-masked]>
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

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

Date: Fri, 05 Dec 2008 18:39:48 +0100
To: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Cc: [email-masked]
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 05 Dec 2008 11:20:07 -0500
From: Barry Leiba <[email-masked]>
To: Michael Haardt <[email-masked]>
cc: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

> 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

Date: Fri, 05 Dec 2008 17:10:01 +0100
To: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Cc: [email-masked]
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 05 Dec 2008 10:36:08 -0500
From: Barry Leiba <[email-masked]>
To: Michael Haardt <[email-masked]>
cc: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

> 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

Date: Fri, 05 Dec 2008 16:31:54 +0100
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> 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

Date: Thu, 4 Dec 2008 20:25:45 +0000
From: "Robert Burrell Donkin" <[email-masked]>
To: [email-masked]
Subject: draft-freed-sieve-in-xml status?
Sender: [email-masked]

- robert

Date: Thu, 4 Dec 2008 17:53:36 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

Fine stuff.

Arnt

Date: Thu, 04 Dec 2008 16:36:55 +0000
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

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.

Date: Thu, 04 Dec 2008 10:06:57 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: draft-ietf-sieve-notify-mailto-10.txt
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-mailto-10.txt 
Date: Thu,  4 Dec 2008 07:00:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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

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

--NextPart--

Cc: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>, "Michael Haardt" <[email-masked]>
From: Cullen Jennings <[email-masked]>
To: "Ned Freed" <[email-masked]>
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Date: Tue, 2 Dec 2008 09:52:41 -0800
Sender: [email-masked]

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.

Date: Tue, 02 Dec 2008 08:57:15 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Michael Haardt <[email-masked]>, [email-masked]
Sender: [email-masked]

> 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

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Re: WGLC on draft-melnikov-sieve-imapext-metadata-04.tx
Date: Tue, 2 Dec 2008 06:38:21 -0800
Sender: [email-masked]

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

Date: Tue, 2 Dec 2008 12:39:36 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Cc: Michael Haardt <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 02 Dec 2008 11:34:58 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]]
Sender: [email-masked]

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

Date: Mon, 01 Dec 2008 14:34:13 -0800 (PST)
From: [email-masked], [email-masked], [email-masked]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Sender: Ned Freed <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]

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

Date: Tue, 02 Dec 2008 11:29:52 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Sender: [email-masked]

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)

Date: Tue, 2 Dec 2008 11:48:28 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Cc: Michael Haardt <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Tue, 02 Dec 2008 08:50:44 +0100
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 1 Dec 2008 23:27:10 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Cullen Jennings <[email-masked]>, [email-masked]
Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Sender: [email-masked]

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

Date: Mon, 01 Dec 2008 21:19:41 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
Sender: [email-masked]

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

From: Cullen Jennings <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon,  1 Dec 2008 13:18:47 -0800 (PST)
Subject: DISCUSS: draft-ietf-sieve-notify-mailto 

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-managesieve-03.txt 
Date: Mon,  1 Dec 2008 03:30:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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

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

--NextPart--