Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling Clarifications
From: Robert Burrell Donkin <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], Ned Freed <[email-masked]>, MTA filtering mailing list <[email-masked]>
Date: Fri, 31 Jul 2009 10:07:06 +0100
List-Id: <ietf-mta-filters.imc.org>

On Fri, Jul 31, 2009 at 9:13 AM, Jeffrey Hutzelman<[email-masked]> wrote:
> --On Friday, July 31, 2009 09:09:23 AM +0100 Robert Burrell Donkin
> <[email-masked]> wrote:
>
>> yes - that's been made clear  (a summary of those discussions would
>> have been more useful than just a re-iteration)
>
> I'm sure there will be a summary in the WG minutes, when they're done.

i'm sure that there will

it would have been polite to inform the mailing list that changes - of
a fundamental nature - had been agreed at the meeting, and that any
discussions on - or analysis of - the recently posted draft 00 would
be wasted

- robert

Date: Fri, 31 Jul 2009 10:07:06 +0100
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], Ned Freed <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

On Fri, Jul 31, 2009 at 9:13 AM, Jeffrey Hutzelman<[email-masked]> wrote:
> --On Friday, July 31, 2009 09:09:23 AM +0100 Robert Burrell Donkin
> <[email-masked]> wrote:
>
>> yes - that's been made clear  (a summary of those discussions would
>> have been more useful than just a re-iteration)
>
> I'm sure there will be a summary in the WG minutes, when they're done.

i'm sure that there will

it would have been polite to inform the mailing list that changes - of
a fundamental nature - had been agreed at the meeting, and that any
discussions on - or analysis of - the recently posted draft 00 would
be wasted

- robert

Date: Fri, 31 Jul 2009 09:58:41 +0100
Subject: Re: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use  List
From: Robert Burrell Donkin <[email-masked]>
To: [email-masked]
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

On Thu, Jul 30, 2009 at 6:36 PM, Barry
Leiba<[email-masked]> wrote:
>> Require implementations to raise a compile time error when list
>> is used with an unsupported test.
>
> That's already what happens when there are such errors in scripts.
> Why should we say it explicitly here, and not everywhere else?

philosophically, i believe in full and complete specifications, with
any areas of variance clearly indicated

practically, as the draft 00 stands, i feel that an implementator
might reasonably elect to test the combination of test and match-type
at compile time, at run time or not verify the condition at all. my
strong preference would be to just issue a warning with an option for
raising a runtime error.

so, though my implementation preference would be excluded by this
proposal, at least the expected behaviour would be clearly specified

>>    Implementations MAY support other tests but MUST raise a compile
>>    time error when a script contains any standard test where support has
>>    not been explicitly specified.
>
> Not explicitly specified by whom?  How?

yes - i'm not happy with the wholley language either

probably better just to specify those tests which should not be supported

> How does this make scripts portable?

i'm a little confused by this

when a script contains an extension, it will only compile on engines
that support that extension. asking extensions to abide by the
description of list in this draft (if they support it) means that at
least that may be relied upon by the script writer.

> This seems to encourage private
> extensions, which has really become a thorn in the web.

an extremely controversial statement ATM (but i'm going to avoid
taking the bait)

happily, sieve is extensible so this philosophical question has
already been resolved in the original specification. i think that a
revision of RFC 5228 would be the right place to start for anyone who
disagrees with this fundamental design decision.

what needs to be decided by this working group is whether the group
thinks that list should work uniformly across all extensions

- robert

Date: Fri, 31 Jul 2009 04:13:44 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
cc: [email-masked], Ned Freed <[email-masked]>, MTA filtering mailing list <[email-masked]>, [email-masked]
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling 	Clarifications
Sender: [email-masked]

--On Friday, July 31, 2009 09:09:23 AM +0100 Robert Burrell Donkin 
<[email-masked]> wrote:

> yes - that's been made clear  (a summary of those discussions would
> have been more useful than just a re-iteration)

I'm sure there will be a summary in the WG minutes, when they're done.

Date: Fri, 31 Jul 2009 09:09:23 +0100
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], Ned Freed <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

On Fri, Jul 31, 2009 at 8:54 AM, Jeffrey Hutzelman<[email-masked]> wrote:
> --On Friday, July 31, 2009 07:58:35 AM +0100 Robert Burrell Donkin
> <[email-masked]> wrote:
>
>>
>> On Thu, Jul 30, 2009 at 6:39 PM, Barry
>> Leiba<[email-masked]> wrote:
>>>
>>> This whole issue may be moot, because we're likely significantly
>>> changing the way the name is specified, after discussion in Stockholm.
>>
>> i am disappointed to have missed some indication or warning posted
>> that the draft was undergoing extensive review and revision off list
>
> There was extensive discussion of this issue during the working group
> meeting this week.

yes - that's been made clear  (a summary of those discussions would
have been more useful than just a re-iteration)

- robert

Date: Fri, 31 Jul 2009 03:54:27 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>, [email-masked]
cc: Ned Freed <[email-masked]>, MTA filtering mailing list <[email-masked]>, [email-masked]
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling 	Clarifications
Sender: [email-masked]

--On Friday, July 31, 2009 07:58:35 AM +0100 Robert Burrell Donkin 
<[email-masked]> wrote:

>
> On Thu, Jul 30, 2009 at 6:39 PM, Barry
> Leiba<[email-masked]> wrote:
>> This whole issue may be moot, because we're likely significantly
>> changing the way the name is specified, after discussion in Stockholm.
>
> i am disappointed to have missed some indication or warning posted
> that the draft was undergoing extensive review and revision off list

There was extensive discussion of this issue during the working group 
meeting this week.

Date: Fri, 31 Jul 2009 07:58:35 +0100
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[email-masked]>
To: [email-masked]
Cc: Ned Freed <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

On Thu, Jul 30, 2009 at 6:39 PM, Barry
Leiba<[email-masked]> wrote:
> This whole issue may be moot, because we're likely significantly
> changing the way the name is specified, after discussion in Stockholm.

i am disappointed to have missed some indication or warning posted
that the draft was undergoing extensive review and revision off list

- robert

Reply-To: [email-masked]
Date: Thu, 30 Jul 2009 13:41:12 -0400
Subject: Re: [draft-melnikov-sieve-external-lists] 3. Security Considerations,  Paragraph 3
From: Barry Leiba <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Robert Burrell Donkin <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

This entire section has already been rewritten, but the version hasn't
been posted as an I-D yet.  Wait until the next version is out, and
re-review.

Barry

Reply-To: [email-masked]
Date: Thu, 30 Jul 2009 13:39:43 -0400
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Barry Leiba <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Robert Burrell Donkin <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

This whole issue may be moot, because we're likely significantly
changing the way the name is specified, after discussion in Stockholm.

Barry

Reply-To: [email-masked]
Date: Thu, 30 Jul 2009 13:36:23 -0400
Subject: Re: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use  List
From: Barry Leiba <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

> Require implementations to raise a compile time error when list
> is used with an unsupported test.

That's already what happens when there are such errors in scripts.
Why should we say it explicitly here, and not everywhere else?

>    Implementations MAY support other tests but MUST raise a compile
>    time error when a script contains any standard test where support has
>    not been explicitly specified.

Not explicitly specified by whom?  How?

How does this make scripts portable?  This seems to encourage private
extensions, which has really become a thorn in the web.

Barry

Date: Thu, 30 Jul 2009 08:47:44 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: [draft-melnikov-sieve-external-lists] 3. Security Considerations, Paragraph 3
To: Robert Burrell Donkin <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

>    "Protocols/APIs used to retrieve/verify external list membership MUST
>    provide at least the same level of confidentiality as protocols/APIs
>    used to retrieve Sieve scripts.  For example, if Sieve scripts are
>    retrieved using LDAP secured with Transport Layer Security (TLS)
>    encryption, then the protocol used to retrieve external list
>    membership must use a comparable mechanism for providing connection
>    confidentiality.  In particular, the protocol used to retrieve
>    external list membership must not be lacking encryption."

> Use Case One: Public FOAF

> how does banning access to public resources improve security?

> Use Case Two: Web Services

> how should an implementation judge whether a web service discovered
> over UDDI (say) is more or less confidential than script storage in
> LDAP (say)?

Complete agreement on all points. There are going to be all kinds of external
lists where the degree of confidentiality provided is an intrinsic
characteristic of the list itself and  isn't under the control of the Sieve
implementation. There are also going to be cases where the Sieve
implementation is accessing the list through an intermediary and has no
way of determining what security, if any, is being employed in accessing
the list. 

Specific examples of the latter would be a list provided by an LDAP proxy
server or a list provided by an LDAP server where the underlying attributes are
virtual and are resolved through some form of callout. Such setups are quite
common in practice.

The entire notion of there being a confidentiality requirement for
external lists independent of the list in question is completely silly.
Let's change this to say that both list content as well as the query stream
against the list MAY be confidential in nature and appopriate security
measures MUST be employed when they are.

				Ned

Date: Thu, 30 Jul 2009 08:05:54 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use List
To: Robert Burrell Donkin <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

This proposal seems OK to me.

				Ned

> Proposal - Clarify Expected Behaviour For Unsupported Tests
> =============================> Change
> ------
> Require implementations to raise a compile time error when list
> is used with an unsupported test.
> Rationale
> ---------
> Adopting a single clear rule on error handling increases interoperability.
> Requiring a compile time error seems cleaner than alternatives such as
> silently failing the test.

> Proposal - Allow Extension Tests To Use Link
> ======================
> Change
> ------
> Add explicit permission for implementations to support list for other
> tests.
> Rationale
> ---------
> Extensions which find "list" useful should be encouraged to use it
> as described.

> Use Case: Mailing List Local Test
> ---------------------------------
> if mailinglist :list "tag:example.org,2009-07-24:IEFT" {
>    fileinto "standards";
> }

> --------------------------------------------------------------------------
> [1] Proposal
> --------------------------------------------------------------------------

> 2.2.  :list match type

>    ABNF:

>       MATCH-TYPE  =/ ":list"
>            ; only valid for supported tests

>    The new ":list" match type changes the interpretation of the "key-
>    list" parameter to supported tests.  When the match type is ":list",
>    the key-list becomes a list of names of externally stored lists.
>    The external lists are queried, perhaps through a list-specific
>    mechanism, and the test evaluates to "true" if any of the specified
>    values matches any member of one or more of the lists.

>    Implementations MUST support "address", "envelope" and "header" tests.
>    Implementations MAY support other tests but MUST raise a compile
>    time error when a script contains any standard test where support has
>    not been explicitly specified.

> --------------------------------------------------------------------------
> [2] Original Text
> --------------------------------------------------------------------------

> 2.2.  :list match type for "address", "envelope", and "header" tests

>    ABNF:

>       MATCH-TYPE  =/ ":list"
>            ; only valid for "address", "envelope", and "header" tests

>    The new ":list" match type changes the interpretation of the "key-
>    list" parameter to the "address"/"envelope"/"header" test.  When the
>    match type is ":list", the key-list becomes a list of names of
>    externally stored lists.  The external lists are queried, perhaps
>    through a list-specific mechanism, and the test evaluates to "true"
>    if any of the specified values matches any member of one or more of
>    the lists.

Date: Thu, 30 Jul 2009 07:51:37 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling Clarifications
To: Robert Burrell Donkin <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

> Proposal: Separate Section For Discussion of TAG
> ========================> Changes
> -------
> Split first paragraph into sections.
> Rationale
> ---------
> Clarity

> Proposal: Clarify Expected Error Handling Behaviour
> =========================> Changes
> -------
> Specify that unsupported URI schemas are compile time
> errors and that resolution failures are runtime errors.

While I agree it's a good idea to report errors at as early a phase as
possible, unless we're willing to specify that variable substitutions cannot be 
used in list names, this can at most be a SHOULD, not a MUST.

> Rationale
> ---------
> Practical implementations will not be able to support
> all feasible URI schemes, protocols, discovery mechanisms
> and resource semantics.

> Any URI schema which is not supported by the engine
> will never be resolved. In this case, it is clearer and
> cleaner to fail at compile time. Note that this case
> also includes malformed URIs.

> Resources may be dynamic. A resource whose semantics
> could not be understood at compile time may have been
> replaced by one that could be at runtime. Resource
> resolution may be dynamic: a resource which could not
> be resolved at compile time may be resolvable at
> runtime. Services may be dynamic. A service with
> suitable semantics may become available at runtime
> which was not at compile time. Conversely,
> resources, resource resolution and service discovery
> may fail at runtime after it succeeded at compile
> time.

> So, failures to resolve, locate or parse a resource
> referred to by the script should only be raised at
> runtime.

Agreed, however, it isn't clear to me that throwing an error is the right
thing to do when a given list resource is unavailable. Handling the
unavailability of a given resource is well within the purview of a properly
constructed portable script, I should think.

> Proposal: Require Implementations To Support [TAG-URI]
> ===========================
> Changes
> -------
> Require that all implementations support tag, plus any other
> URI schemes of their choice.
> Rationale
> ---------
> Insisting that implementations support at least one protocol
> sets a minimum level for script portability. Picking one
> particular web protocol such as LDAP, HTTP or FTP would impose
> a unnecessary burden on implementations and
> unnecessarily involve the specification in the semantics of
> engine-list server interactions.

> A credible alternative choice would be relative URIs.

It's unclear what "support" means in this context. In our implementtation list
URIs are parsed and then passed to what amounts to a callout. We can of course
make it so tag: is always a legal URL type when that check is done, but we
cannot force tag: to work.

> --------------------------------------------------------------------------
> [1] Proposal
> --------------------------------------------------------------------------

> 2.4.  Syntax of an externally stored list name

>    A name of an externally stored list is always an absolute URI [URI].
>    Implementations might find URLs such as [LDAP], [CardDAV], or
>    [TAG-URI] to be useful for naming external lists.

>    Implementations MUST raise a compile time error when a list name
>    cannot be parsed into a URI scheme supported by the implementation.

See above. This needs to be a SHOULD.

>    Resolution of the resource MAY involve resource location and service
>    discovery. Resources MAY change dynamically. Resolution of the
>    resource MUST be perform at script execution time. When the resource
>    cannot be located or the resource type is found to be unsupported
>    then the implementation MUST raise a runtime error.

If we're going to throw an error like this in a  test I think we need a way to
test and see if the resource is available.

>    Implementations MAY attempt to resolve the URI at compile time but
>    MUST NOT raise a compile time error on failure.

> 2.4.1 The Tag Scheme
>    The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
>    user friendlier identifiers.

>    Resolution of such identifiers is going to be implementation specific
>    and it can help in hiding the complexity of an implementation from
>    end users.  For example, an implementation can provide a web interface
>    for managing lists of users stored in LDAP.  Requiring users to know
>    generic LDAP URL syntax might not be very practical, due to its
>    complexity.  An implementation can instead use a fixed tag URI prefix
>    such as "tag:example.com,<date>:" (where <date> can be, for example,
>    a date generated once on installation of the web interface and left
>    untouched upon upgrades) and the prefix doesn't even need to be shown
>    to end users.

>    Implementations MUST support the [TAG-URI] URI scheme.

I think some elaboration on what "support" means would be good here.

> 2.4.2 Other URI Schemes

>    Implementations MAY support other URI schemes.

				Ned

Date: Thu, 30 Jul 2009 15:09:48 +0200
From: Cyrus Daboo <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Working Group Last Call for draft-freed-sieve-notary-05
Sender: [email-masked]

Hi folks,
We are starting a two week last call on draft-freed-sieve-notary-05. We've 
had a last call on this document before but some new "deliverby" features 
have been added since then, so we need adequate review of those from the WG 
before we can hand this off to the IESG.

So the last call starts today and will complete on August 13th.

Please send comments to the list.

-- 
Cyrus Daboo

Date: Thu, 30 Jul 2009 13:52:57 +0100
Subject: [draft-melnikov-sieve-external-lists] 3. Security Considerations,  Paragraph 2
From: Robert Burrell Donkin <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

<blockquote cite='http://www.ietf.org/id/draft-ietf-sieve-external-lists-00.txt'>
   A failure to retrieve data due to the server storing the external
   list membership being down or otherwise inaccessible may alter the
   result of Sieve processing.  So implementations SHOULD treat a
   temporary failure to retrieve or verify external list membership in
   the same manner as a temporary failure to retrieve a Sieve script.
   For example, if the Sieve script is stored in the Lightweight
   Directory Access Protocol (LDAP) and the script can't be retrieved
   when a message is processed, then the agent performing Sieve
   processing can, for example, assume that the script doesn't exist or
   delay message delivery until the script can be retrieved
   successfully.  External list memberships should be treated as if they
   are a part of the script itself, so a temporary failure to retrieve
   them should be handled in the same way as a temporary failure to
   retrieve the Sieve script itself.
</blockquote>

how does this error handling behaviour improve security?

what are the advantages of this new error handling language to that
already established in RFC 5228?

- robert

Date: Thu, 30 Jul 2009 13:44:39 +0100
Subject: [draft-melnikov-sieve-external-lists] 3. Security Considerations,  Paragraph 3
From: Robert Burrell Donkin <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

   "Protocols/APIs used to retrieve/verify external list membership MUST
   provide at least the same level of confidentiality as protocols/APIs
   used to retrieve Sieve scripts.  For example, if Sieve scripts are
   retrieved using LDAP secured with Transport Layer Security (TLS)
   encryption, then the protocol used to retrieve external list
   membership must use a comparable mechanism for providing connection
   confidentiality.  In particular, the protocol used to retrieve
   external list membership must not be lacking encryption."

Use Case One: Public FOAF

how does banning access to public resources improve security?

Use Case Two: Web Services

how should an implementation judge whether a web service discovered
over UDDI (say) is more or less confidential than script storage in
LDAP (say)?

- robert

Date: Thu, 30 Jul 2009 13:24:55 +0100
Subject: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use  List
From: Robert Burrell Donkin <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

Proposal - Clarify Expected Behaviour For Unsupported Tests
=============================Change
------
Require implementations to raise a compile time error when list
is used with an unsupported test.
Rationale
---------
Adopting a single clear rule on error handling increases interoperability.
Requiring a compile time error seems cleaner than alternatives such as
silently failing the test.

Proposal - Allow Extension Tests To Use Link
======================
Change
------
Add explicit permission for implementations to support list for other
tests.
Rationale
---------
Extensions which find "list" useful should be encouraged to use it
as described.

Use Case: Mailing List Local Test
---------------------------------
if mailinglist :list "tag:example.org,2009-07-24:IEFT" {
   fileinto "standards";
}

--------------------------------------------------------------------------
[1] Proposal
--------------------------------------------------------------------------

2.2.  :list match type

   ABNF:

      MATCH-TYPE  =/ ":list"
           ; only valid for supported tests

   The new ":list" match type changes the interpretation of the "key-
   list" parameter to supported tests.  When the match type is ":list",
   the key-list becomes a list of names of externally stored lists.
   The external lists are queried, perhaps through a list-specific
   mechanism, and the test evaluates to "true" if any of the specified
   values matches any member of one or more of the lists.

   Implementations MUST support "address", "envelope" and "header" tests.
   Implementations MAY support other tests but MUST raise a compile
   time error when a script contains any standard test where support has
   not been explicitly specified.

--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------

2.2.  :list match type for "address", "envelope", and "header" tests

   ABNF:

      MATCH-TYPE  =/ ":list"
           ; only valid for "address", "envelope", and "header" tests

   The new ":list" match type changes the interpretation of the "key-
   list" parameter to the "address"/"envelope"/"header" test.  When the
   match type is ":list", the key-list becomes a list of names of
   externally stored lists.  The external lists are queried, perhaps
   through a list-specific mechanism, and the test evaluates to "true"
   if any of the specified values matches any member of one or more of
   the lists.

Date: Thu, 30 Jul 2009 13:18:52 +0100
Subject: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

Proposal: Separate Section For Discussion of TAG
========================Changes
-------
Split first paragraph into sections.
Rationale
---------
Clarity

Proposal: Clarify Expected Error Handling Behaviour
=========================Changes
-------
Specify that unsupported URI schemas are compile time
errors and that resolution failures are runtime errors.
Rationale
---------
Practical implementations will not be able to support
all feasible URI schemes, protocols, discovery mechanisms
and resource semantics.

Any URI schema which is not supported by the engine
will never be resolved. In this case, it is clearer and
cleaner to fail at compile time. Note that this case
also includes malformed URIs.

Resources may be dynamic. A resource whose semantics
could not be understood at compile time may have been
replaced by one that could be at runtime. Resource
resolution may be dynamic: a resource which could not
be resolved at compile time may be resolvable at
runtime. Services may be dynamic. A service with
suitable semantics may become available at runtime
which was not at compile time. Conversely,
resources, resource resolution and service discovery
may fail at runtime after it succeeded at compile
time.

So, failures to resolve, locate or parse a resource
referred to by the script should only be raised at
runtime.

Proposal: Require Implementations To Support [TAG-URI]
===========================
Changes
-------
Require that all implementations support tag, plus any other
URI schemes of their choice.
Rationale
---------
Insisting that implementations support at least one protocol
sets a minimum level for script portability. Picking one
particular web protocol such as LDAP, HTTP or FTP would impose
a unnecessary burden on implementations and
unnecessarily involve the specification in the semantics of
engine-list server interactions.

A credible alternative choice would be relative URIs.

--------------------------------------------------------------------------
[1] Proposal
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.

   Implementations MUST raise a compile time error when a list name
   cannot be parsed into a URI scheme supported by the implementation.

   Resolution of the resource MAY involve resource location and service
   discovery. Resources MAY change dynamically. Resolution of the
   resource MUST be perform at script execution time. When the resource
   cannot be located or the resource type is found to be unsupported
   then the implementation MUST raise a runtime error.

   Implementations MAY attempt to resolve the URI at compile time but
   MUST NOT raise a compile time error on failure.

2.4.1 The Tag Scheme
   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.

   Resolution of such identifiers is going to be implementation specific
   and it can help in hiding the complexity of an implementation from
   end users.  For example, an implementation can provide a web interface
   for managing lists of users stored in LDAP.  Requiring users to know
   generic LDAP URL syntax might not be very practical, due to its
   complexity.  An implementation can instead use a fixed tag URI prefix
   such as "tag:example.com,<date>:" (where <date> can be, for example,
   a date generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.

   Implementations MUST support the [TAG-URI] URI scheme.

2.4.2 Other URI Schemes

   Implementations MAY support other URI schemes.

--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.
   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.  Resolution of such identifiers is going
   to be implementation specific and it can help in hiding the
   complexity of an implementation from end users.  For example, an
   implementation can provide a web interface for managing lists of
   users stored in LDAP.  Requiring users to know generic LDAP URL
   syntax might not be very practical, due to its complexity.  An
   implementation can instead use a fixed tag URI prefix such as "tag:
   example.com,<date>:" (where <date> can be, for example, a date
   generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.

Date: Thu, 30 Jul 2009 11:32:08 +0100
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Robert Burrell Donkin <[email-masked]>
To: [email-masked]
Cc: Aaron Stone <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

On Tue, Jul 28, 2009 at 8:39 AM, Barry
Leiba<[email-masked]> wrote:

<snip>

>  I'll also point out that in most cases (us geeks
> notwithstanding), the script will be generated under the covers.  So
> the user might, indeed, just type "MyList", and the icky-looking URI
> would be filled in for her.

how might such a generator discover how to map "MyList" to
"tag:MyList" (say) in an interoperable fashion?

- robert

Date: Thu, 30 Jul 2009 11:24:00 +0100
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Robert Burrell Donkin <[email-masked]>
To: [email-masked]
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

On Sat, Jul 25, 2009 at 7:23 PM, Barry
Leiba<[email-masked]> wrote:
>> Use relative URIs to represent resources managed transparently by the
>> Sieve Engine.
>
> This was my thought as well, when Alexey first brought the idea up.
> Originally, the idea was that the list name was just a string,
> understood by the Sieve processor.  It quickly became clear that that
> was problematic, and we should go with URIs.  Some thought they should
> always be absolute, and I thought relative ones should be allowed.  We
> batted that around for some while, and settled on absolute.
>
> Apart from the reason you mention -- that it can be confusing -- the
> main argument against using relative URIs is the difficulty in clearly
> (and interoperably) defining what the relative ones mean.  Saying that
> the Sieve processor understands what they mean ignores the real
> problem with making sure the user (and/or the client) also understands
> it.
>
> I think we should stay with absolute URIs.

the location and interpretation of resources with arbitrary semantics
across arbitrary protocols is - i think - too difficult a problem to
be tackle by this draft. therefore, we should be satisfied now just by
specifying what we can and leaving these difficult interoperability
problems to other expert groups.

- robert

Date: Thu, 30 Jul 2009 11:13:31 +0100
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Robert Burrell Donkin <[email-masked]>
To: [email-masked]
Cc: Aaron Stone <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

On Tue, Jul 28, 2009 at 8:39 AM, Barry
Leiba<[email-masked]> wrote:
>> [As IC:]

<snip>

>> I do like the idea of just writing ':list "MyList"' and not needed much
>> else. It does seem a bit overkill to be typing my own email address into
>> the Sieve script for the very same account.
>
> I like the idea also, but I see the problems in interpreting it,

what difficulties do you see?

> especially as one tries to move scripts form one implementation to
> another.

could you explain when - given a server instance capable of supporting
at least two sieve implementations and with access to resources mapped
by a relative URL - moving a script from one implementation to another
should create special difficulties?

- robert

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-include-03.txt 
Date: Wed, 29 Jul 2009 16:00:01 -0700 (PDT)
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: Include Extension
	Author(s)       : C. Daboo, A. Stone
	Filename        : draft-ietf-sieve-include-03.txt
	Pages           : 14
	Date            : 2009-07-29

The Sieve Email Filtering "include" extension permits users to
include one Sieve script inside another.  This can make managing
large scripts or multiple sets of scripts much easier, and allows a
site and its users to build up libraries of scripts.  Users are able
to include their own personal scripts or site-wide scripts.

Change History (to be removed prior to publication as an RFC)

Changes from ietf-02 to ietf-03:

a.  Setting a variable then calling global on it is an error

 (something like 'use strict').

b.  Specify that the 'global' keyword is only available when

 'variables' has also been required.

c.  Uploading a script that includes a nonexistent script is not an

 error at upload time.

Changes from ietf-01 to ietf-02:

a.  Require that script names must be constant strings, not subject

 to variable expansion.

b.  Try the phrase immediate script instead of current script.

c.  Clarify that "global 'varname'" and "global.varname" refer to the

 same variable.

d.  Drop the requirement the global keywords come after require and

 before anything else.

Changes from ietf-00 to ietf-01:

a.  Replaced import/export with global.

b.  Added :once modifier to include.

c.  Added global namespace to see if it holds water.

Changes from daboo-06 to ietf-00:
a.  None

Changes from -05 to -06:

a.  Aaron Stone joins as author.

b.  Removed | characters from the script examples.

c.  Updated draft references to published RFCs.

Changes from -04 to -05:

a.  Fixed examples.

b.  Relaxed requirement that imported/exported variables be set

 before being used.

Changes from -03 to -04:

a.  Fixed missing 2119 definitions.

b.  Defined interaction with variables through use of import and

 export commands.

Changes from -02 to -03:

a.  Refreshing expired draft (updated for nits).

b.  Syntax -> Usage.

c.  Updated to 3028bis reference.

Changes from -01 to -02:

a.  Minor formatting changes only - refreshing expired draft.

Changes from -00 to -01:

a.  Added IPR boiler plate.

b.  Re-ordered sections at start to conform to RFC style.

c.  Moved recursion comment into General Considerations section.

d.  Switched to using optional parameter to indicate personal vs

 global.
e.  Explicitly state that an error occurs when a missing script is

 included.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-include-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-include-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-external-lists-00.txt 
Date: Tue, 28 Jul 2009 07:00:02 -0700 (PDT)
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 Extension: Externally Stored Lists
	Author(s)       : A. Melnikov
	Filename        : draft-ietf-sieve-external-lists-00.txt
	Pages           : 7
	Date            : 2009-07-05

Sieve scripting language can be used for implementing of
whitelisting, blacklisting and personal distribution lists.
Currently this requires that all members of such lists be hardcoded
in the script itself.  Whenever a member of such list is added or
deleted, the script needs to be updated and possibly uploaded to a
mail server.

This document defines a Sieve extension for accessing externally
stored mailing lists, i.e. list whose members are stored externally
to the script, for example in LDAP (RFC 4510), ACAP (RFC 2244) or a
relational database.

ToDo

o  Need a way to advertise supported URI schemas in ManageSieve and

ihave.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-external-lists-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-external-lists-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Reply-To: [email-masked]
Date: Tue, 28 Jul 2009 03:39:00 -0400
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Barry Leiba <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Robert Burrell Donkin <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

> [As IC:]

"IC"?

> Personally, I'm concerned about potential ugliness of the identifiers if a
> UI thinks it's hidden, but that's kind of an omnipresent issue around here.

Sorry; I can't make sense of that.  Try rephrasing?

> I do like the idea of just writing ':list "MyList"' and not needed much
> else. It does seem a bit overkill to be typing my own email address into
> the Sieve script for the very same account.

I like the idea also, but I see the problems in interpreting it,
especially as one tries to move scripts form one implementation to
another.  I'll also point out that in most cases (us geeks
notwithstanding), the script will be generated under the covers.  So
the user might, indeed, just type "MyList", and the icky-looking URI
would be filled in for her.

Barry

Date: Mon, 27 Jul 2009 17:01:26 -0700
From: Aaron Stone <[email-masked]>
To: <[email-masked]>, Robert Burrell Donkin <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To =?UTF-8?Q?	Section 2.4?In-Reply-To: <[email-masked]>
Sender: [email-masked]

On Mon, 27 Jul 2009 16:07:36 -0700, Aaron Stone <[email-masked]>
wrote:
> On Sat, 25 Jul 2009 14:23:29 -0400, Barry Leiba
> <[email-masked]> wrote:
>>> Use relative URIs to represent resources managed transparently by the
>>> Sieve Engine.
>> 
>> This was my thought as well, when Alexey first brought the idea up.
>> Originally, the idea was that the list name was just a string,
>> understood by the Sieve processor.  It quickly became clear that that
>> was problematic, and we should go with URIs.  Some thought they should
>> always be absolute, and I thought relative ones should be allowed.  We
>> batted that around for some while, and settled on absolute.
>> 
>> Apart from the reason you mention -- that it can be confusing -- the
>> main argument against using relative URIs is the difficulty in clearly
>> (and interoperably) defining what the relative ones mean.  Saying that
>> the Sieve processor understands what they mean ignores the real
>> problem with making sure the user (and/or the client) also understands
>> it.
>> 
>> I think we should stay with absolute URIs.
> 
> [As IC:]
> 
> With the tag: URI scheme, you do get the effect of a server-specific URI,
> and with a clear indication that that's what you're looking at (since it
> begins literally with "tag:"). Does that address the concerns here?

[Still an IC:]

Sorry, I didn't read the original comment and text. Of course this is
exactly what's at issue.

Personally, I'm concerned about potential ugliness of the identifiers if a
UI thinks it's hidden, but that's kind of an omnipresent issue around here.

I do like the idea of just writing ':list "MyList"' and not needed much
else. It does seem a bit overkill to be typing my own email address into
the Sieve script for the very same account.

Aaron

Date: Mon, 27 Jul 2009 16:07:36 -0700
From: Aaron Stone <[email-masked]>
To: <[email-masked]>
Cc: Robert Burrell Donkin <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To =?UTF-8?Q?	Section 2.4?In-Reply-To: <[email-masked]>
Sender: [email-masked]

On Sat, 25 Jul 2009 14:23:29 -0400, Barry Leiba
<[email-masked]> wrote:
>> Use relative URIs to represent resources managed transparently by the
>> Sieve Engine.
> 
> This was my thought as well, when Alexey first brought the idea up.
> Originally, the idea was that the list name was just a string,
> understood by the Sieve processor.  It quickly became clear that that
> was problematic, and we should go with URIs.  Some thought they should
> always be absolute, and I thought relative ones should be allowed.  We
> batted that around for some while, and settled on absolute.
> 
> Apart from the reason you mention -- that it can be confusing -- the
> main argument against using relative URIs is the difficulty in clearly
> (and interoperably) defining what the relative ones mean.  Saying that
> the Sieve processor understands what they mean ignores the real
> problem with making sure the user (and/or the client) also understands
> it.
> 
> I think we should stay with absolute URIs.

[As IC:]

With the tag: URI scheme, you do get the effect of a server-specific URI,
and with a clear indication that that's what you're looking at (since it
begins literally with "tag:"). Does that address the concerns here?

Aaron

Date: Mon, 27 Jul 2009 18:19:25 +0200
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Slides for meeting uploaded
Sender: [email-masked]

Hi folks,
I have uploaded a set of slides to the IETF meeting materials site for 
Wednesday's meeting. Please review and let me know of any corrections or 
additions.

<http://www3.ietf.org/proceedings/75/slides/sieve-0.pdf>

-- 
Cyrus Daboo

Reply-To: [email-masked]
Date: Sat, 25 Jul 2009 14:25:41 -0400
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Changes To Section  2.3
From: Barry Leiba <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

I don't strongly object to the change Robert suggests, below, but I
think it's useful to explain the situation, to explain why there might
be issues here.  I'd rather not eliminate the paragraph that gives
that explanation.  I'm happier, if we want to use Robert's text, to
leave at least some of the eliminated paragraph in as an informative
note.

Barry

On Fri, Jul 24, 2009 at 5:04 AM, Robert Burrell
Donkin<[email-masked]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Changes
> - -------
> Revise and consolidate existing paragraphs 3 and 4 into a shorter functional
> description.
>
> Rationale
> - ---------
> Paragraphs 3 and 4 in 2.3 specify complex, hard to test requirements for
> little clear gain. Regarding the redirection as a black box makes the
> specification
> more concise and allows more space for novel approaches.
>
> - --------------------------------------------------------------------------
> [1] Proposed Text
> - --------------------------------------------------------------------------
>
> 2.3.  :list tagged argument to the "redirect" action
>
>   Usage:  redirect :list
>
>   The "redirect" action with the ":list" argument is used to send the
>   message to one or more email addresses stored in the externally
>   stored list 'ext-list-name'.  This variant of the redirect command
>   can be used to implement a personal distribution list.
>
>   The Sieve engine and list server SHOULD collaborate to achieve a
>   redirection consistent with the semantics described in [Sieve]. If
>   they are unable to do so then the situation MUST result in a
>   runtime error.
>
>   See Section 2.4 for the detailed description of syntax used for
>   naming externally stored lists.
>
> - --------------------------------------------------------------------------
> [2] Original Text
> - --------------------------------------------------------------------------
> 2.3.  :list tagged argument to the "redirect" action
>
>   Usage:  redirect :list
>
>   The "redirect" action with the ":list" argument is used to send the
>   message to one or more email addresses stored in the externally
>   stored list 'ext-list-name'.  This variant of the redirect command
>   can be used to implement a personal distribution list.
>
>   Use of this feature requires that the list resolve to a list of email
>   addresses, and that the Sieve engine be able to enumerate those
>   addresses. [[anchor5: Alexey would like the option of allowing the
>   list handler to enumerate the addresses and do the redirect there.
>   Barry thinks that's contrary to Sieve, which expects to queue the
>   redirect action for processing at a later stage, and that it would be
>   a bad idea to have the redirect happen in the list handler.  The WG
>   needs to resolve this issue.]]  In cases where, for example, a list
>   contains hashed email address values or an email address pattern
>   ("[email-masked]", "[email-masked]"), it will not be possible to
>   redirect to that list.
>
>   If the Sieve engine [[anchor6: or list handler?]] is permanently
>   unable to enumerate the list or the list does not resolve to email
>   addresses, the situation MUST result in a runtime error in the Sieve
>   script.
>
>   See Section 2.4 for the detailed description of syntax used for
>   naming externally stored lists.
>

Reply-To: [email-masked]
Date: Sat, 25 Jul 2009 14:23:29 -0400
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Barry Leiba <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

> Use relative URIs to represent resources managed transparently by the
> Sieve Engine.

This was my thought as well, when Alexey first brought the idea up.
Originally, the idea was that the list name was just a string,
understood by the Sieve processor.  It quickly became clear that that
was problematic, and we should go with URIs.  Some thought they should
always be absolute, and I thought relative ones should be allowed.  We
batted that around for some while, and settled on absolute.

Apart from the reason you mention -- that it can be confusing -- the
main argument against using relative URIs is the difficulty in clearly
(and interoperably) defining what the relative ones mean.  Saying that
the Sieve processor understands what they mean ignores the real
problem with making sure the user (and/or the client) also understands
it.

I think we should stay with absolute URIs.

Barry

Date: Fri, 24 Jul 2009 15:11:28 +0100
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Robert Burrell Donkin <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Cc: =?windows-1251?B?xOjr/+0gz+Dr4PPn7uI=?= <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

(apologies for messing up the reply-to foo first time 8-)

On Fri, Jul 24, 2009 at 1:55 PM, Ned Freed<[email-masked]> wrote:
>
>> 2009/7/20 Ned Freed <[email-masked]>:
>> >
>> >
>> >> Hello,
>> >
>> >> > Would we need to have :list-is, :list-matches, :list-contains, or can we
>> >> > get away with just :list, which would check for the exact match?
>> >
>> >> As far as I understood Ned, it is the list who decides on the exact
>> >> match type : it is not up to the script to prescribe the matching. So
>> >> "just :list".
>> >
>> >> Any use cases where :list-is, :list-contains ... make sense and "just
>> >> :list" would be insufficient?
>> >
>> > Sure, you can have lists that support more than one kind of matching,
>> > although
>> > I expect such cases to be the exception rather than the rule. In such cases
>> > I
>> > would propose that the type of matching be embedded in the list name
>> > somehow.
>> >
>> > This then gets to the idea of using URLs for list names. A tag: URL is of
>> > course completely capable of handling additional embedded material. Other
>> > URL schemes, not so much. In fact I'm not entirely sure how this is supposed
>> > to
>> > work with LDAP URLs with reasonable efficiency.
>> >
>> > Consider the fairly typical case of whitelisting based on a personal address
>> > book in LDAP. Assuming everyone is OK with users being able to construct
>> > and perform their own LDAP searches and have no problem knowing and hard
>> > coding
>> > the base DN of their entries (both very big ifs), this would call for
>> > something
>> > like:
>> >
>> >  if address :list "from"
>> >     "ldap:///cn=me,o=pab?mail?sub?(objectclass=regularentry)" {
>> >     ... whitelist ...
>> >  }
>> >
>> > The problem with this is we're again back to enumeration - that URL produces
>> > a (potentially very large) list of addresses, which would have to be
>> > compared
>> > one by one to the address(es) extracted from the "from" field.
>> >
>> > But consider the URL:
>> >
>> >  ldap:///cn=me,o=pab?mail?sub?(&(objectclass=regularentry)(mail=a@b))
>> >
>> > This flips the problem around - now the address you're looking for is
>> > specified
>> > in the URL itself. Now it's up to the LDAP server to find the match, and the
>> > simple fact it returned a response is enough to conclude the address is on
>> > the
>> > list.
>> >
>> > This is much more efficient, especially if the LDAP server has proper
>> > indexing.
>> > But now the URL is something that has to be constructed by knowing what
>> > you're
>> > searching for.
>> >
>> > I will also note that LDAP URLs can embed very complex matching criteria of
>> > their own.
>> >
>> > Now, I guess I have no problem with using tag: URLs that end up getting
>> > converted to the more efficient LDAP URLs seen here. But I really have to
>> > question whether anyone is actually going to allow, as the specification
>> > implies, the direct use of LDAP URLs or other URLs with similar
>> > characteristics.
>
>> +1
>
>> the Sieve engine will face problems of semantics, resolution and
>> authentication with direct URLs
>
> The last item is an important point. Anyone who allows, say LDAP URls, is going
> to have a fun time analyzing those URls to make sure they don't do  anything
> naughty.

+1

i spent some time this morning thinking about the HTTP case - and it's
very interesting :-)

i have some comments related to this but i need some more thinking
time before i post them to the list (i've pushed them to github[1]
just in case anyone wants to see where they're going ATM)

- robert

[1] http://github.com/RobertBurrellDonkin/ietf-mta-filters/tree/master
follow links to ExternallyStoredLists/00

Date: Fri, 24 Jul 2009 05:55:10 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
To: Robert Burrell Donkin <[email-masked]>
Cc: Ned Freed <[email-masked]>, =?windows-1251?B?xOjr/+0gz+Dr4PPn7uI=?= <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

> 2009/7/20 Ned Freed <[email-masked]>:
> >
> >
> >> Hello,
> >
> >> > Would we need to have :list-is, :list-matches, :list-contains, or can we
> >> > get away with just :list, which would check for the exact match?
> >
> >> As far as I understood Ned, it is the list who decides on the exact
> >> match type : it is not up to the script to prescribe the matching. So
> >> "just :list".
> >
> >> Any use cases where :list-is, :list-contains ... make sense and "just
> >> :list" would be insufficient?
> >
> > Sure, you can have lists that support more than one kind of matching,
> > although
> > I expect such cases to be the exception rather than the rule. In such cases
> > I
> > would propose that the type of matching be embedded in the list name
> > somehow.
> >
> > This then gets to the idea of using URLs for list names. A tag: URL is of
> > course completely capable of handling additional embedded material. Other
> > URL schemes, not so much. In fact I'm not entirely sure how this is supposed
> > to
> > work with LDAP URLs with reasonable efficiency.
> >
> > Consider the fairly typical case of whitelisting based on a personal address
> > book in LDAP. Assuming everyone is OK with users being able to construct
> > and perform their own LDAP searches and have no problem knowing and hard
> > coding
> > the base DN of their entries (both very big ifs), this would call for
> > something
> > like:
> >
> >  if address :list "from"
> >     "ldap:///cn=me,o=pab?mail?sub?(objectclass=regularentry)" {
> >     ... whitelist ...
> >  }
> >
> > The problem with this is we're again back to enumeration - that URL produces
> > a (potentially very large) list of addresses, which would have to be
> > compared
> > one by one to the address(es) extracted from the "from" field.
> >
> > But consider the URL:
> >
> >  ldap:///cn=me,o=pab?mail?sub?(&(objectclass=regularentry)(mail=a@b))
> >
> > This flips the problem around - now the address you're looking for is
> > specified
> > in the URL itself. Now it's up to the LDAP server to find the match, and the
> > simple fact it returned a response is enough to conclude the address is on
> > the
> > list.
> >
> > This is much more efficient, especially if the LDAP server has proper
> > indexing.
> > But now the URL is something that has to be constructed by knowing what
> > you're
> > searching for.
> >
> > I will also note that LDAP URLs can embed very complex matching criteria of
> > their own.
> >
> > Now, I guess I have no problem with using tag: URLs that end up getting
> > converted to the more efficient LDAP URLs seen here. But I really have to
> > question whether anyone is actually going to allow, as the specification
> > implies, the direct use of LDAP URLs or other URLs with similar
> > characteristics.

> +1

> the Sieve engine will face problems of semantics, resolution and
> authentication with direct URLs

The last item is an important point. Anyone who allows, say LDAP URls, is going
to have a fun time analyzing those URls to make sure they don't do  anything
naughty.

				Ned

Date: Fri, 24 Jul 2009 12:38:51 +0100
Subject: [draft-melnikov-sieve-external-lists] Proposed Addition To Section  2.4
From: Robert Burrell Donkin <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

Proposal
====
Use relative URIs to represent resources managed transparently by the
Sieve Engine.

Rationale
====A little syntactic sugar to simplify scripts.

For example, the following forms might be functionally equivalent:

  redirect :list "tag:example.com,2009-05-28:mylist"
  redirect :list "MyList"

but the relative URI form is more concise.

Disadvantages
======* It is not obvious that the list name is an URI. Some users may therefore
  be surprised to learn that URI naming rules apply.

Sample Use Cases
========
Shared Blacklist Maintained By The System Administrator
-------------------------------------------------------
 if address :list "/blacklist" {
   discard;
 }

Shared Distribution List Maintained By The System Administrator
---------------------------------------------------------------
 redirect :list "/staff"

Private Whitelist Maintained By The System For The User
-------------------------------------------------------
 if header :list "from" "MyFriends" {
   keep;
 }

--------------------------------------------------------------------------
[1] Proposed Insertion
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list MUST be an URI [URI].

2.4.1 Relative URIs

   A relative URI MAY be interpreted by a Sieve engine as a reference to
   a list service resource managed by the implementation. An
   implementation which does not support relative URIs SHOULD raise an
   error at compile time when a list name is a relative URI.

2.4.2 Absolute URIs

   An absolute URI indicates an external list processing resource.
   Implementations might find URLs such as [LDAP], [CardDAV], or
[etc, continuing as per original]

--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.

   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.  Resolution of such identifiers is going
   to be implementation specific and it can help in hiding the
   complexity of an implementation from end users.  For example, an
   implementation can provide a web interface for managing lists of
   users stored in LDAP.  Requiring users to know generic LDAP URL
   syntax might not be very practical, due to its complexity.  An
   implementation can instead use a fixed tag URI prefix such as "tag:
   example.com,<date>:" (where <date> can be, for example, a date
   generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.

Date: Fri, 24 Jul 2009 10:04:25 +0100
Subject: [draft-melnikov-sieve-external-lists] Proposed Changes To Section 2.3
From: Robert Burrell Donkin <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

Changes
- -------
Revise and consolidate existing paragraphs 3 and 4 into a shorter functional
description.

Rationale
- ---------
Paragraphs 3 and 4 in 2.3 specify complex, hard to test requirements for
little clear gain. Regarding the redirection as a black box makes the
specification
more concise and allows more space for novel approaches.

- --------------------------------------------------------------------------
[1] Proposed Text
- --------------------------------------------------------------------------

2.3.  :list tagged argument to the "redirect" action

   Usage:  redirect :list

   The "redirect" action with the ":list" argument is used to send the
   message to one or more email addresses stored in the externally
   stored list 'ext-list-name'.  This variant of the redirect command
   can be used to implement a personal distribution list.

   The Sieve engine and list server SHOULD collaborate to achieve a
   redirection consistent with the semantics described in [Sieve]. If
   they are unable to do so then the situation MUST result in a
   runtime error.

   See Section 2.4 for the detailed description of syntax used for
   naming externally stored lists.

- --------------------------------------------------------------------------
[2] Original Text
- --------------------------------------------------------------------------
2.3.  :list tagged argument to the "redirect" action

   Usage:  redirect :list

   The "redirect" action with the ":list" argument is used to send the
   message to one or more email addresses stored in the externally
   stored list 'ext-list-name'.  This variant of the redirect command
   can be used to implement a personal distribution list.

   Use of this feature requires that the list resolve to a list of email
   addresses, and that the Sieve engine be able to enumerate those
   addresses. [[anchor5: Alexey would like the option of allowing the
   list handler to enumerate the addresses and do the redirect there.
   Barry thinks that's contrary to Sieve, which expects to queue the
   redirect action for processing at a later stage, and that it would be
   a bad idea to have the redirect happen in the list handler.  The WG
   needs to resolve this issue.]]  In cases where, for example, a list
   contains hashed email address values or an email address pattern
   ("[email-masked]", "[email-masked]"), it will not be possible to
   redirect to that list.

   If the Sieve engine [[anchor6: or list handler?]] is permanently
   unable to enumerate the list or the list does not resolve to email
   addresses, the situation MUST result in a runtime error in the Sieve
   script.

   See Section 2.4 for the detailed description of syntax used for
   naming externally stored lists.

Date: Thu, 23 Jul 2009 22:48:50 +0100
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Robert Burrell Donkin <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: =?windows-1251?B?xOjr/+0gz+Dr4PPn7uI=?= <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

2009/7/20 Ned Freed <[email-masked]>:
>
>
>> Hello,
>
>> > Would we need to have :list-is, :list-matches, :list-contains, or can we
>> > get away with just :list, which would check for the exact match?
>
>> As far as I understood Ned, it is the list who decides on the exact
>> match type : it is not up to the script to prescribe the matching. So
>> "just :list".
>
>> Any use cases where :list-is, :list-contains ... make sense and "just
>> :list" would be insufficient?
>
> Sure, you can have lists that support more than one kind of matching,
> although
> I expect such cases to be the exception rather than the rule. In such cases
> I
> would propose that the type of matching be embedded in the list name
> somehow.
>
> This then gets to the idea of using URLs for list names. A tag: URL is of
> course completely capable of handling additional embedded material. Other
> URL schemes, not so much. In fact I'm not entirely sure how this is supposed
> to
> work with LDAP URLs with reasonable efficiency.
>
> Consider the fairly typical case of whitelisting based on a personal address
> book in LDAP. Assuming everyone is OK with users being able to construct
> and perform their own LDAP searches and have no problem knowing and hard
> coding
> the base DN of their entries (both very big ifs), this would call for
> something
> like:
>
>  if address :list "from"
>     "ldap:///cn=me,o=pab?mail?sub?(objectclass=regularentry)" {
>     ... whitelist ...
>  }
>
> The problem with this is we're again back to enumeration - that URL produces
> a (potentially very large) list of addresses, which would have to be
> compared
> one by one to the address(es) extracted from the "from" field.
>
> But consider the URL:
>
>  ldap:///cn=me,o=pab?mail?sub?(&(objectclass=regularentry)(mail=a@b))
>
> This flips the problem around - now the address you're looking for is
> specified
> in the URL itself. Now it's up to the LDAP server to find the match, and the
> simple fact it returned a response is enough to conclude the address is on
> the
> list.
>
> This is much more efficient, especially if the LDAP server has proper
> indexing.
> But now the URL is something that has to be constructed by knowing what
> you're
> searching for.
>
> I will also note that LDAP URLs can embed very complex matching criteria of
> their own.
>
> Now, I guess I have no problem with using tag: URLs that end up getting
> converted to the more efficient LDAP URLs seen here. But I really have to
> question whether anyone is actually going to allow, as the specification
> implies, the direct use of LDAP URLs or other URLs with similar
> characteristics.

+1

the Sieve engine will face problems of semantics, resolution and
authentication with direct URLs

- robert

Date: Thu, 23 Jul 2009 22:18:33 +0100
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Robert Burrell Donkin <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Barry Leiba <[email-masked]>, Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

On Wed, Jul 22, 2009 at 3:49 PM, Ned Freed<[email-masked]> wrote:
>
>
>> >> But the same issues affect section 2.3.  If the list can't be
>> >> enumerated, you can't redirect to it.
>> >>
>> > :list is not a match type in this case, again it is a black box.
>> ...
>> > So I would like to correct your statement. There is no need whatsoever to be
>> > able to enumerate list membership in Sieve in order to redirect.
>> > The only requirement is that whoever does mailing list expansion needs to be
>> > able to do that. Such entity doesn't have to be the Sieve engine.
>
>> Two things:
>> 1. When I say that the list must be enumerable, I don't necessarily
>> mean "by the Sieve engine."  It's possible for the list not to be
>> enumerable at all, even by the list handler.  Examples are where the
>> list stores hashes of email addresses (to preserve privacy, perhaps)
>> and where the list stores mailbox patterns (all members of department
>> Z have email addresses that start with "dz", so the list of department
>> Z members is querieable ("Is X a member?"), but not enumerable).
>
> Exactly so. And by the same token, a list you can redirect to may not
> necessarily be queryable in any other way.

+1

>> 2. Ah, so you're suggesting that the Sieve engine, which knows how to
>> do a redirect, should pass this on to the list handler, which now also
>> has to know how to do a redirect.  I'm not sure that's a good idea,
>> but I could perhaps be convinced.  I'm curious about what Ned thinks
>> here.
>
> Handling redirect :list by throwing the problem over the fence to a list
> processors is an interesting approach. We actallly use a variant of it - the
> sieve machinery performs variouos actions on the messeage but then invokes our
> more general list expansion machinery to get the necessary address list.

i wonder whether the specification would be cleaner and clearer if it
allowed the sieve and list engines to collaborate in executing the
redirection in the most convenient fashion

- robert

From: [email-masked]
To: Ned Freed <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked], MTA filtering mailing list <[email-masked]>
Date: Thu, 23 Jul 2009 22:06:07 +0100 (GMT)
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
-------firegpg076eqfxhz3sktyyzh6e3tpg
Content-Type: text/plain; format=flowed; charset=UTF-8
Content-Transfer-Encoding: base64

IHdheS4NCg0KKzENCg0KLSByb2JlcnQ-------firegpg076eqfxhz3sktyyzh6e3tpg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-------firegpg076eqfxhz3sktyyzh6e3tpg--

Date: Wed, 22 Jul 2009 22:50:49 +0200
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

Barry Leiba wrote:
 [...]

>Should this next version be renamed to
>"draft-ietf-sieve-external-lists-00"?  In other words, should the WG
>adopt it?  I think it should.
>  
>
Yes. This document is in our charter and my understanding is that the WG 
already made a decision to accept it.

Date: Wed, 22 Jul 2009 22:18:06 +0200
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked], MTA filtering mailing list <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

Ned Freed wrote:
 [...]

>> We should discuss this in Stockholm (and on the mailing list). I wasn't
>> thinking about being able to use the header test without being able to
>> reference the same list in redirect.
>
> Well, I can sort of see an argument that you might expect to be able to
> reference any list that you used in an _address_ test in redirect, but
> header? Who says the lists we'll be checking headers against are of
> addresses or anything that correlates to addresses?
>
> And in fact there are even lists of addresses (hashed lists are the 
> obvious
> example) where you won't be able to reference them in redirect.
>
> The opposite is going to be true as well. There are plenty of use 
> cases for a
> list you want people to be able to redirect to but not test the 
> content of in
> any way.

I was originally thinking about email only lists, but you and Barry 
convinced me that other types of lists are also useful.

So yes, I will update the draft.

Reply-To: [email-masked]
Date: Wed, 22 Jul 2009 12:18:32 -0400
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Barry Leiba <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

--001636417b7df3d8ee046f4db864
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Attached is my proposed -03 version (attached as "-03-pre01"), which
has NOT been posted as an I-D at this point.  I've sent Alexey my
edits, and the edit token is back with him.

I've made a bunch of changes, so forget DIFFs and please read the
whole thing (it's short) and comment.

Should this next version be renamed to
"draft-ietf-sieve-external-lists-00"?  In other words, should the WG
adopt it?  I think it should.

Barry

--001636417b7df3d8ee046f4db864
Content-Type: text/plain; charset=US-ASCII; 
	name="draft-melnikov-sieve-external-lists-03-pre01.txt"
Content-Disposition: attachment; 
	filename="draft-melnikov-sieve-external-lists-03-pre01.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fxg9ctf40

--001636417b7df3d8ee046f4db864--

Date: Wed, 22 Jul 2009 07:49:17 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
To: Barry Leiba <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

> >> But the same issues affect section 2.3.  If the list can't be
> >> enumerated, you can't redirect to it.
> >>
> > :list is not a match type in this case, again it is a black box.
> ...
> > So I would like to correct your statement. There is no need whatsoever to be
> > able to enumerate list membership in Sieve in order to redirect.
> > The only requirement is that whoever does mailing list expansion needs to be
> > able to do that. Such entity doesn't have to be the Sieve engine.

> Two things:
> 1. When I say that the list must be enumerable, I don't necessarily
> mean "by the Sieve engine."  It's possible for the list not to be
> enumerable at all, even by the list handler.  Examples are where the
> list stores hashes of email addresses (to preserve privacy, perhaps)
> and where the list stores mailbox patterns (all members of department
> Z have email addresses that start with "dz", so the list of department
> Z members is querieable ("Is X a member?"), but not enumerable).

Exactly so. And by the same token, a list you can redirect to may not
necessarily be queryable in any other way.

> 2. Ah, so you're suggesting that the Sieve engine, which knows how to
> do a redirect, should pass this on to the list handler, which now also
> has to know how to do a redirect.  I'm not sure that's a good idea,
> but I could perhaps be convinced.  I'm curious about what Ned thinks
> here.

Handling redirect :list by throwing the problem over the fence to a list
processors is an interesting approach. We actallly use a variant of it - the
sieve machinery performs variouos actions on the messeage but then invokes our
more general list expansion machinery to get the necessary address list.

				Ned

Date: Wed, 22 Jul 2009 07:24:52 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

> Barry Leiba wrote:

> >In my previous message I said that I had other issues with the
> >document.  Here they are:
> >
> >Making :list a match type sorts out my issues with section 2.2, so that's fine.
> >
> >But the same issues affect section 2.3.  If the list can't be
> >enumerated, you can't redirect to it.
> >
> :list is not a match type in this case, again it is a black box.

> >Section 2.3 needs to make it
> >clear that whether an external list can do this or not depends upon
> >the list, and it needs to say what happens if it can't (ignore, or
> >throw runtime error seem to be the two sensible choices, and I think I
> >prefer the latter).
> >
> >
> We should discuss this in Stockholm (and on the mailing list). I wasn't
> thinking about being able to use the header test without being able to
> reference the same list in redirect.

Well, I can sort of see an argument that you might expect to be able to
reference any list that you used in an _address_ test in redirect, but
header? Who says the lists we'll be checking headers against are of
addresses or anything that correlates to addresses?

And in fact there are even lists of addresses (hashed lists are the obvious
example) where you won't be able to reference them in redirect.

The opposite is going to be true as well. There are plenty of use cases for a
list you want people to be able to redirect to but not test the content of in
any way.

				Ned

Reply-To: [email-masked]
Date: Wed, 22 Jul 2009 09:46:22 -0400
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Barry Leiba <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

>> But the same issues affect section 2.3.  If the list can't be
>> enumerated, you can't redirect to it.
>>
> :list is not a match type in this case, again it is a black box.
...
> So I would like to correct your statement. There is no need whatsoever to be
> able to enumerate list membership in Sieve in order to redirect.
> The only requirement is that whoever does mailing list expansion needs to be
> able to do that. Such entity doesn't have to be the Sieve engine.

Two things:
1. When I say that the list must be enumerable, I don't necessarily
mean "by the Sieve engine."  It's possible for the list not to be
enumerable at all, even by the list handler.  Examples are where the
list stores hashes of email addresses (to preserve privacy, perhaps)
and where the list stores mailbox patterns (all members of department
Z have email addresses that start with "dz", so the list of department
Z members is querieable ("Is X a member?"), but not enumerable).

2. Ah, so you're suggesting that the Sieve engine, which knows how to
do a redirect, should pass this on to the list handler, which now also
has to know how to do a redirect.  I'm not sure that's a good idea,
but I could perhaps be convinced.  I'm curious about what Ned thinks
here.

>> Section 2.3 needs to make it
>> clear that whether an external list can do this or not depends upon
>> the list, and it needs to say what happens if it can't (ignore, or
>> throw runtime error seem to be the two sensible choices, and I think I
>> prefer the latter).
>
> We should discuss this in Stockholm (and on the mailing list). I wasn't
> thinking about being able to use the header test without being able to
> reference the same list in redirect.

There's also the case where the list is not a list of email addresses.
 In that case, it can certainly be used for section 2.2, but not for
2.3.  2.3 still has to say what to do.  Repeating, I think it's a
"SHOULD [or maybe MUST] cause a runtime error" if the list can't be
used for redirect because of the type of list it is (which includes
the discussion above).

>> I'd rather decouple them, and just say that the Sieve processor MUST use
>> "appropriate security" to interact with the list,
>
> I think "appropriate security" is quite ambiguous.

I don't think it's ambiguous, but, not, it's not well specified.  I
expected to put more words in to be clearer, but the point is that
it's ultimately the responsibility of the implementation to know
what's appropriate.  There's a difference between making an LDAP
request in a closed LAN that's only used for trusted servers (neither
encryption nor authentication may be needed), a firewalled LAN for a
particular company (it might be OK to skip encryption, depending upon
policy), or the open Internet (encryption and authentication probably
required), and whether the list being accessed is private or public
(no encryption or authentication needed for public data, even on the
Internet).

We can't dictate any of that in the spec... we can only give examples
and advice, and leave the final choice of what's "appropriate" to the
implementation.

>> The normative text in the "mail bombs" consideration should move to
>> section 2.3, though I think it's still a good idea to mention the
>> issue here as well.
>
> I am not sure this is needed. Similar text in the base Sieve spec is in the
> Security Considerations section.

OK.  I don't have a very strong opinion here.  I think it's harmless
and possible helpful to put the normative bits earlier in the
document.  But it's OK with me if consensus is that it doesn't matter.

Barry

Date: Wed, 22 Jul 2009 11:42:42 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

Alexey Melnikov wrote:

> Barry Leiba wrote:
>
>> In my previous message I said that I had other issues with the
>> document.  Here they are:
>>
>> Making :list a match type sorts out my issues with section 2.2, so 
>> that's fine.
>>
>> But the same issues affect section 2.3.  If the list can't be
>> enumerated, you can't redirect to it.
>
> :list is not a match type in this case, again it is a black box.

So I would like to correct your statement. There is no need whatsoever 
to be able to enumerate list membership in Sieve in order to redirect.
The only requirement is that whoever does mailing list expansion needs 
to be able to do that. Such entity doesn't have to be the Sieve engine.

>> Section 2.3 needs to make it
>> clear that whether an external list can do this or not depends upon
>> the list, and it needs to say what happens if it can't (ignore, or
>> throw runtime error seem to be the two sensible choices, and I think I
>> prefer the latter).
>
> We should discuss this in Stockholm (and on the mailing list). I 
> wasn't thinking about being able to use the header test without being 
> able to reference the same list in redirect.

Date: Wed, 22 Jul 2009 11:38:06 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

Barry Leiba wrote:

>In my previous message I said that I had other issues with the
>document.  Here they are:
>
>Making :list a match type sorts out my issues with section 2.2, so that's fine.
>
>But the same issues affect section 2.3.  If the list can't be
>enumerated, you can't redirect to it.
>
:list is not a match type in this case, again it is a black box.

>Section 2.3 needs to make it
>clear that whether an external list can do this or not depends upon
>the list, and it needs to say what happens if it can't (ignore, or
>throw runtime error seem to be the two sensible choices, and I think I
>prefer the latter).
>  
>
We should discuss this in Stockholm (and on the mailing list). I wasn't 
thinking about being able to use the header test without being able to 
reference the same list in redirect.

>Section 2.4 says that the syntax of the list name is a URI, but it
>doesn't talk about the semantics.  Along with the change to 2.2,
>section 2.4 needs to change to (1) note that some URI types make sense
>and some don't (Alexey already has this on his to-do list,
>
Right.

>and (2)
>explain that the URI has to resolve to something that can be used as a
>list in the manner specified in 2.2 and 2.3... and talk a little about
>what that means.  Specifically, it has to be something that can be
>given a string and can determine whether that string "is a member"...
>and that it MAY also be something that can return its members as a
>list or through an iterator.
>  
>
Ok.

>Section 3, Security Considerations, needs some work, I think.  First,
>I don't like that there's some normative language there that doesn't
>appear elsewhere.  I prefer to have the normative parts of Security
>Considerations be elsewhere in the document, in the parts that one
>expects to be normative.
>
>Second...
>   Protocols/APIs used to retrieve/verify external list membership MUST
>   provide at least the same level of confidentiality as protocols/APIs
>   used to retrieve Sieve scripts.  For example, if Sieve scripts are
>   retrieved using LDAP secured with Transport Layer Security (TLS)
>   encryption, then the protocol used to retrieve external list
>   membership must use a comparable mechanism for providing connection
>   confidentiality.  In particular, the protocol used to retrieve
>   external list membership must not be lacking encryption.
>
>I don't think this is right.  The connection between the Sieve
>processor and the Sieve script store might be very different to the
>connection it has with the external list.
>
Agreed.

>It's likely that it might
>not be necessary to use TLS to retrieve Sieve scripts, but IS
>necessary to use it to interact with the list, or vice-versa.
>
Right.

>I'd rather decouple them, and just say that the Sieve processor MUST use
>"appropriate security" to interact with the list,
>
I think "appropriate security" is quite ambiguous.

>and that that may mean using TLS, proper authentication, and whatnot -- but that it also
>might not... say, in a closed system where the Sieve processor acting
>on behalf of a user has direct access to the user's address book,
>without fear of interception.
>  
>
The intent was to cover this case.
I think an internal API which doesn't use a TCP protocol underneath (for 
example) and can't be intercepted, then it is considered as secure.

But obviously your reading of this text doesn't agree with my intent, so 
I will think about rewording.

>The normative text in the "mail bombs" consideration should move to
>section 2.3, though I think it's still a good idea to mention the
>issue here as well.
>  
>
I am not sure this is needed. Similar text in the base Sieve spec is in 
the Security Considerations section.

Reply-To: [email-masked]
Date: Wed, 22 Jul 2009 01:55:09 -0400
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Barry Leiba <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Sender: [email-masked]

In my previous message I said that I had other issues with the
document.  Here they are:

Making :list a match type sorts out my issues with section 2.2, so that's fine.

But the same issues affect section 2.3.  If the list can't be
enumerated, you can't redirect to it.  Section 2.3 needs to make it
clear that whether an external list can do this or not depends upon
the list, and it needs to say what happens if it can't (ignore, or
throw runtime error seem to be the two sensible choices, and I think I
prefer the latter).

Section 2.4 says that the syntax of the list name is a URI, but it
doesn't talk about the semantics.  Along with the change to 2.2,
section 2.4 needs to change to (1) note that some URI types make sense
and some don't (Alexey already has this on his to-do list, and (2)
explain that the URI has to resolve to something that can be used as a
list in the manner specified in 2.2 and 2.3... and talk a little about
what that means.  Specifically, it has to be something that can be
given a string and can determine whether that string "is a member"...
and that it MAY also be something that can return its members as a
list or through an iterator.

Section 3, Security Considerations, needs some work, I think.  First,
I don't like that there's some normative language there that doesn't
appear elsewhere.  I prefer to have the normative parts of Security
Considerations be elsewhere in the document, in the parts that one
expects to be normative.

Second...
   Protocols/APIs used to retrieve/verify external list membership MUST
   provide at least the same level of confidentiality as protocols/APIs
   used to retrieve Sieve scripts.  For example, if Sieve scripts are
   retrieved using LDAP secured with Transport Layer Security (TLS)
   encryption, then the protocol used to retrieve external list
   membership must use a comparable mechanism for providing connection
   confidentiality.  In particular, the protocol used to retrieve
   external list membership must not be lacking encryption.

I don't think this is right.  The connection between the Sieve
processor and the Sieve script store might be very different to the
connection it has with the external list.  It's likely that it might
not be necessary to use TLS to retrieve Sieve scripts, but IS
necessary to use it to interact with the list, or vice-versa.  I'd
rather decouple them, and just say that the Sieve processor MUST use
"appropriate security" to interact with the list, and that that may
mean using TLS, proper authentication, and whatnot -- but that it also
might not... say, in a closed system where the Sieve processor acting
on behalf of a user has direct access to the user's address book,
without fear of interception.

The normative text in the "mail bombs" consideration should move to
section 2.3, though I think it's still a good idea to mention the
issue here as well.

Barry

Reply-To: [email-masked]
Date: Tue, 21 Jul 2009 17:19:57 -0400
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Barry Leiba <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: =?windows-1251?B?xOjr/+0gz+Dr4PPn7uI=?= <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> Ned has answered this nicely. I was thinking about substring matches (kind
> of simplified :matches), but this can be thought of as an implementation
> details. I.e. we can consider an external list to be black box.

I agree with Ned completely, and Alexey sums it up perfectly: an
external list is a black box.  It was the lack of that semantic that
made me resistant to external lists before.  If :list is a match type,
that major issue goes away for me (though I still have others, but I
think they can be resolved).

Barry

Date: Mon, 20 Jul 2009 10:41:50 +0100
From: Alexey Melnikov <[email-masked]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
CC: Ned Freed <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

Ð”Ð¸Ð»ÑÐ½ ÐŸÐ°Ð»Ð°ÑƒÐ·Ð¾Ð² wrote:

> Hello,
>
>> Would we need to have :list-is, :list-matches, :list-contains, or can 
>> we get away with just :list, which would check for the exact match?
>
> As far as I understood Ned, it is the list who decides on the exact 
> match type : it is not up to the script to prescribe the matching. So 
> "just :list".
>
> Any use cases where :list-is, :list-contains ... make sense and "just 
> :list" would be insufficient?

Ned has answered this nicely. I was thinking about substring matches 
(kind of simplified :matches), but this can be thought of as an 
implementation details. I.e. we can consider an external list to be 
black box.

Date: Sun, 19 Jul 2009 18:12:25 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> Hello,

> > Would we need to have :list-is, :list-matches, :list-contains, or can we
> > get away with just :list, which would check for the exact match?

> As far as I understood Ned, it is the list who decides on the exact
> match type : it is not up to the script to prescribe the matching. So
> "just :list".

> Any use cases where :list-is, :list-contains ... make sense and "just
> :list" would be insufficient?

Sure, you can have lists that support more than one kind of matching, although
I expect such cases to be the exception rather than the rule. In such cases I
would propose that the type of matching be embedded in the list name somehow.

This then gets to the idea of using URLs for list names. A tag: URL is of
course completely capable of handling additional embedded material. Other
URL schemes, not so much. In fact I'm not entirely sure how this is supposed to
work with LDAP URLs with reasonable efficiency.

Consider the fairly typical case of whitelisting based on a personal address
book in LDAP. Assuming everyone is OK with users being able to construct
and perform their own LDAP searches and have no problem knowing and hard coding
the base DN of their entries (both very big ifs), this would call for something
like:

   if address :list "from"
      "ldap:///cn=me,o=pab?mail?sub?(objectclass=regularentry)" {
      ... whitelist ...
   }

The problem with this is we're again back to enumeration - that URL produces
a (potentially very large) list of addresses, which would have to be compared
one by one to the address(es) extracted from the "from" field.

But consider the URL:

  ldap:///cn=me,o=pab?mail?sub?(&(objectclass=regularentry)(mail=a@b))

This flips the problem around - now the address you're looking for is specified
in the URL itself. Now it's up to the LDAP server to find the match, and the
simple fact it returned a response is enough to conclude the address is on the
list.

This is much more efficient, especially if the LDAP server has proper indexing.
But now the URL is something that has to be constructed by knowing what you're
searching for.

I will also note that LDAP URLs can embed very complex matching criteria of
their own.

Now, I guess I have no problem with using tag: URLs that end up getting
converted to the more efficient LDAP URLs seen here. But I really have to
question whether anyone is actually going to allow, as the specification
implies, the direct use of LDAP URLs or other URLs with similar
characteristics.

				Ned

Date: Sun, 19 Jul 2009 13:13:56 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
To: Alexey Melnikov <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> Would we need to have :list-is, :list-matches, :list-contains, or can we
> get away with just :list, which would check for the exact match?

Making the match type part of the list argument is just moving the information
around and not changing the underlying semantics. Having any specification at
aall of the match type other than "it's matching a list" is exactly what we
don't want and which cannot be supported. 

Perhaps some specific examples will make this clear. Suppose I have a list of
whitelisted addresses, but because of privacy concerns this list contains the 
SHA-1 hash of each address. The only match type such a list would support is
:is. And it's an inherent characteristic of the list that that's the only
match type.

Now suppose I  have a list of half a million or so strings I don't want to see
as part of a subject line. I've used some algorithm or other to turn this into
a data structure that will tell me if any of those substrings appear in a
single  pass over the subject. The implied match type for such a list is
:contains.

Now consider a list consisting of IP addresses and net masks. I want to check
and see if a given IP address matches anything on the list. (Assuming the list
content is properly normalized, this can be done for IPv4 with no more than 32
exact match comparisons, 128 for IPv6. Of course other, more sophisticated
approaches are also possible.) This list has an effective match type that
corresponds to nothing we currently have in sieve, yet it is a perfectly
reasonable sort of list to want to match against.

Now think for a moment what's involved with having a list that support :matches
or worse, :regex. You now have a list of patterns that have to be checked one
by one, and checking each one is pretty expensive. In other words,
enumerability is a requirement for such a list, and depending on how things are
stored, the match type may still be implied by the underlying storage
mechanism.

Again, there is no doubt that, for the subset of lists that are enumerable,
having the match type be separate makes sense and provides the most
flexibility. But many of the lists we're going to want to check aren't
enumerable, either because the underlying technology doesn't support it or
because enumeration is simply too expensive. And I really have to wonder
if allowing all the combinations when most of them are going to produce
a runtime error is the right way to design this.

And if we decide not to make :list a MATCH-TYPE, the text is going to have to
state that any particular combination of MATCH-TYPE and :list may produce a
runtime error for some subset of the available set of lists. This may even
extend to the default :is MATCH-TYPE, creating a situation where a MATCH-TYPE
has to be specified.

				Ned

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Sun, 19 Jul 2009 21:41:45 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: Ned Freed <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

Hello,

> Would we need to have :list-is, :list-matches, :list-contains, or can we 
> get away with just :list, which would check for the exact match?

As far as I understood Ned, it is the list who decides on the exact 
match type : it is not up to the script to prescribe the matching. So 
"just :list".

Any use cases where :list-is, :list-contains ... make sense and "just 
:list" would be insufficient?

Ð¡ÑŠÑ Ð·Ð´Ñ€Ð°Ð²Ðµ,
	Ð´Ð¸Ð»ÑÐ½

Date: Sun, 19 Jul 2009 20:25:35 +0100
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

Ned Freed wrote:
 [...]

> There are basically two ways to address one. One is to say "some 
> combinations
> of :list and variaus MATCH-TYPES" are going to fail in some cases".
> Alternately, we can simply say "the MATCH-TYPE is implied by the list 
> itself,
> and :list is therefore best thought of as a MATCH-TYPE".
>
> I strongly prefer the latter. The former has least astonishment violation
> written all over it. It also fails to allow for lists whose underlying 
> match
> criteria do not align with existing Sieve match types, and there are a 
> LOT of
> those; prefix match, suffix match, IP address pattern matches, etc. 
> And before
> anyone suggests defining new match types for these, allow me to point 
> out that
> in some cases the ynderlying match types allowed from some sources are 
> open
> ended and extensible.

Would we need to have :list-is, :list-matches, :list-contains, or can we 
get away with just :list, which would check for the exact match?

Date: Sun, 19 Jul 2009 11:46:53 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
To: Alexey Melnikov <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> I've changed the subject and moving my reply to the Sieve mailing list,
> where I think it belongs.

Agreed.

> >> There is also a Sieve extension for making use of whitelists/blacklists
> >> during mail delivery. See draft-melnikov-sieve-external-lists-02.txt.
> >> It can work with CARDDAV, LDAP and other things.
> >
> > Interestingly, this extension in its current form is not compatible with
> > at least one of the proposals that was made here. The issue is one I've
> > raised before - the fact that :list is separate argument and not a
> > match type.
> >
> > Where there is clearly some utility in being able to say stuff along the
> > lines of:
> >
> >    header :contains :list "subject" "tag:dirty-word-list"
> >
> > The problem is that in order for this to work the list has to be
> > enumerable.

> This wasn't the intent. I was certainly aware of the need not to
> retrieve the whole membership list.

> But you are saying that my syntax wouldn't work in this case.

It's not a question of syntax, but semantics. When a list isn't enumerable it
typically only supports some specific sort of matching that's intrinsic to the
list. In most case it's a :is match in sieve parlance, but not always.

So what you end up with are lists where some subset of
:is/:contains/:regex/:matches cannot be used. And which combinations are
and are nt allowed is going to vary from list to list.

There are basically two ways to address one. One is to say "some combinations
of :list and variaus MATCH-TYPES" are going to fail in some cases".
Alternately, we can simply say "the MATCH-TYPE is implied by the list itself,
and :list is therefore best thought of as a MATCH-TYPE".

I strongly prefer the latter. The former has least astonishment violation
written all over it. It also fails to allow for lists whose underlying match
criteria do not align with existing Sieve match types, and there are a LOT of
those; prefix match, suffix match, IP address pattern matches, etc. And before
anyone suggests defining new match types for these, allow me to point out that
in some cases the ynderlying match types allowed from some sources are open
ended and extensible.

> > Not all lists are enumerable, and even some that are are so large even
> > though oyu can enumerate them in theory you can't afford to do so in
> > practice.

> > One use case where this matters is when the list is a set of hashed
> > values. The
> > way you find if something is "on the list" is to hash it and see if
> > that value
> > appears. And even if the input string is short enough that you can
> > enumerate
> > all the unique substrings, how about :matches and :regex? Good luck with
> > those.

> > Hashed lists have in fact been proposed in the present discussion as a
> > means of
> > avoiding giving your address whitelist to the mail server. I happen
> > not to
> > think this is a useful thing to do for a variety of reasons, mostly
> > having to
> > do with address canonicalization (or lack thereof), but there are other
> > use cases where hashed lists make more sense.
> >
> > So, although it reduces functionality, I believe :list should be a
> > match type
> > and the underlying comparison type that's done should be a property of
> > the list
> > itself.

> Hmm. You are probably right, :list as a modifier is a bit of a hack.
> How would the new match type work with tests other than
> header/address/envelope?

Well, for example, something like

    string :list "target-string" "list-name"

would check to see if the list named "list-name" has "target-string" as
a member using whatever membership criteria the list is set up for.

				Ned

Date: Sun, 19 Jul 2009 19:38:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Comments on draft-melnikov-sieve-external-lists-02.txt
Sender: [email-masked]

Hi Ned,
I've changed the subject and moving my reply to the Sieve mailing list, 
where I think it belongs.

Ned Freed wrote:
 [...]

>> There is also a Sieve extension for making use of whitelists/blacklists
>> during mail delivery. See draft-melnikov-sieve-external-lists-02.txt.
>> It can work with CARDDAV, LDAP and other things.
>
> Interestingly, this extension in its current form is not compatible with
> at least one of the proposals that was made here. The issue is one I've
> raised before - the fact that :list is separate argument and not a 
> match type.
>
> Where there is clearly some utility in being able to say stuff along the
> lines of:
>
>    header :contains :list "subject" "tag:dirty-word-list"
>
> The problem is that in order for this to work the list has to be 
> enumerable.

This wasn't the intent. I was certainly aware of the need not to 
retrieve the whole membership list.
But you are saying that my syntax wouldn't work in this case.

> Not all lists are enumerable, and even some that are are so large even 
> though oyu can enumerate them in theory you can't afford to do so in 
> practice.
>
> One use case where this matters is when the list is a set of hashed 
> values. The
> way you find if something is "on the list" is to hash it and see if 
> that value
> appears. And even if the input string is short enough that you can 
> enumerate
> all the unique substrings, how about :matches and :regex? Good luck with
> those.
>
> Hashed lists have in fact been proposed in the present discussion as a 
> means of
> avoiding giving your address whitelist to the mail server. I happen 
> not to
> think this is a useful thing to do for a variety of reasons, mostly 
> having to
> do with address canonicalization (or lack thereof), but there are other
> use cases where hashed lists make more sense.
>
> So, although it reduces functionality, I believe :list should be a 
> match type
> and the underlying comparison type that's done should be a property of 
> the list
> itself.

Hmm. You are probably right, :list as a modifier is a bit of a hack.
How would the new match type work with tests other than 
header/address/envelope?

Date: Wed, 15 Jul 2009 11:14:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed agenda
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi folks,
> Below is a proposed agenda for the Stockholm meeting. If you have any 
> additions or changes please let me know asap.
>
> Also note that we have a 2 1/2 hour slot this time so I have been 
> generous in assigning time to each item. I would really like to see 
> issues with "active" drafts (include, imap/sieve, external-lists) all 
> dealt with at the meeting.

This looks fine to me.

> RegEx Discussion                                        (20 mins)

Is there an official draft now?

Date: Wed, 15 Jul 2009 00:07:28 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Proposed agenda
Sender: [email-masked]

Hi folks,
Below is a proposed agenda for the Stockholm meeting. If you have any 
additions or changes please let me know asap.

Also note that we have a 2 1/2 hour slot this time so I have been generous 
in assigning time to each item. I would really like to see issues with 
"active" drafts (include, imap/sieve, external-lists) all dealt with at the 
meeting.

Agenda

Document status review                                  (10 mins)
WG Status review                                        (10 mins)

Notary (draft-freed-sieve-notary-05)                    ( 5 mins)
Notify SIP (draft-ietf-sieve-notify-sip-message-01)     ( 5 mins)

Include (draft-sieve-include-02)                        (20 mins)
IMAP/SIEVE (draft-ietf-lemonade-imap-sieve-06)          (30 mins)
External lists (draft-melnikov-sieve-external-lists-02) (30 mins)
RegEx Discussion                                        (20 mins)

Auto-reply (draft-george-sieve-autoreply-00)            ( 5 mins)

EAI Issues                                              ( 5 mins)
Benefits of SIEVE                                       (10 mins)

================================
Total:                                                  150 mins

-- 
Cyrus Daboo

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-mime-loop-09.txt 
Date: Mon, 13 Jul 2009 09:15:01 -0700 (PDT)
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: MIME part Tests, Iteration, Extraction, Replacement and Enclosure
	Author(s)       : T. Hansen, C. Daboo
	Filename        : draft-ietf-sieve-mime-loop-09.txt
	Pages           : 22
	Date            : 2009-07-13

This document defines extensions to the Sieve email filtering
language to permit analysis and manipulation of the MIME body parts
of an email message.

Note

This document is being discussed on the MTA-FILTERS mailing list,
[email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-09.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-mime-loop-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Reply-To: [email-masked]
Date: Mon, 13 Jul 2009 11:16:54 -0400
Subject: Fwd: New Version Notification for draft-ietf-lemonade-imap-sieve-06
From: Barry Leiba <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

I've posted a new imap-sieve draft, which makes some updates and
includes as notes (search for "[[") Ned's issues with it.  I've also
moved the discussion here, in preparation for moving this document to
the sieve working group and away from lemonade -- we should talk about that
in Stockholm.  I'm asking the sieve chairs for a slot on the agenda in
Stockholm to talk about this draft, which we really should work on and
wrap up.

To that last end, I also ask that folks review what's there and make
comments, especially about (but not limited to) the "[[" notes.  If we
can sort out what to do with those (and explicit text is welcome), we
can make some progress.

I've set the reply-to on this message to go to the sieve mailing list,
at <[email-masked]>.

Barry

---------- Forwarded message ----------
From: IETF I-D Submission Tool <[email-masked]>
Date: Sat, Jul 11, 2009 at 11:33 AM
Subject: New Version Notification for draft-ietf-lemonade-imap-sieve-06
To: [email-masked]

A new version of I-D, draft-ietf-lemonade-imap-sieve-06.txt has been
successfuly submitted by Barry Leiba and posted to the IETF
repository.

Filename:        draft-ietf-lemonade-imap-sieve
Revision:        06
Title:           Support for Sieve in Internet Message Access Protocol (IMAP4)
Creation_date:   2009-07-11
WG ID:           lemonade
Number_of_pages: 24

Abstract:
Sieve defines an email filtering language that can, in principle,
plug into any point in the processing of an email message.  As
defined in the base specification, it plugs into mail delivery.  This
document defines how Sieve can plug into points in the IMAP protocol
where messages are created or changed, adding the option of user-
defined or installation-defined filtering (or, with Sieve extensions,
features such as notifications).Note

This document defines extensions to IMAP and Sieve.  For now, it is
the work of the Lemonade Working Group (Enhancements to Internet
email to support diverse service environments), but it will be moved
to the Sieve working group at some point.

1.  Discussion of this document should be taken to the Sieve mailing

 list at mailto:[email-masked]

2.  Subscription requests can be sent to

 mailto:[email-masked]?body=subscribe (send an

 email message with the word "subscribe" in the body).

3.  A WWW archive of back messages is available at

 http://www.ietf.org/mail-archive/web/sieve/index.html

4.  Older messages, which were posted to the lemonade mailing list,

 are archived at

 http://www.ietf.org/mail-archive/web/lemonade/index.html

The IETF Secretariat.

Date: Sun, 05 Jul 2009 12:01:41 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D Action:draft-melnikov-sieve-external-lists-02.txt]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060207070701090905090504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

FYI.

--------------060207070701090905090504
Content-Type: message/rfc822;
 name="I-D Action:draft-melnikov-sieve-external-lists-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-melnikov-sieve-external-lists-02.txt"

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-melnikov-sieve-external-lists-02.txt 
Date: Sun,  5 Jul 2009 04:00:01 -0700 (PDT)
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Sieve Extension: Externally Stored Lists
	Author(s)       : A. Melnikov
	Filename        : draft-melnikov-sieve-external-lists-02.txt
	Pages           : 7
	Date            : 2009-07-05

Sieve scripting language can be used for implementing of
whitelisting, blacklisting and personal distribution lists.
Currently this requires that all members of such lists be hardcoded
in the script itself.  Whenever a member of such list is added or
deleted, the script needs to be updated and possibly uploaded to a
mail server.

This document defines a Sieve extension for accessing externally
stored mailing lists, i.e. list whose members are stored externally
to the script, for example in LDAP (RFC 4510), ACAP (RFC 2244) or a
relational database.

ToDo

o  Need a way to advertise supported URI schemas in ManageSieve and

ihave.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-sieve-external-lists-02.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-melnikov-sieve-external-lists-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------060207070701090905090504--