Subject: Standard to selectively disable rules in sieve script?

From: Patrick Ben Koetter <[email-masked]>
Date: Wed, 26 Mar 2008 22:45:19 +0100

I've been reading the RFCs and couldn't find an answer to the following
question:

Is there a standard syntax/notation to disable a single rule/command within a
sieve script that contains more than one rule/command?

I couldn't find anything in the RFCs, but what I found is that everybody seems
to use comments to disable a rule. So far so good...

The bad thing seems to be that even though everybody agrees to use comments
nobody seems to agree on one way to do it - one way all implementations
understand.

My research indicates that interoperability among sieve script clients is lost
when it comes to disabling rules.

A script edited by avelsieve - this is pure fiction, I didn't test this, but
it serves to proove my point - (probably) won't work for KMail, because KMail
is unable to recognize rules that have been disabled by avelsieve and vice
versa.

If I am correct, then - in my eyes - this is a major drawback in making Sieve
useful and popular.

Am I missing something?

Thanks,

p@rick

-- 
state of mind
Agentur für Kommunikation, Design und Softwareentwicklung

Patrick Koetter            Tel: 089 45227227
Echinger Strasse 3         Fax: 089 45227226
85386 Eching               Web: http://www.state-of-mind.de

Amtsgericht München        Partnerschaftsregister PR 563

---

From: Aaron Stone <[email-masked]>
Date: Wed, 26 Mar 2008 15:58:27 -0700

Most of the Sieve clients don't actually parse the Sieve rulesets,  
unfortunately. They tend to do what Avelsieve does, which is to leave  
itself a comment in a particular format (for Avelsieve, it's a  
serialized PHP array) so that it knows what the next block of code does.

This does indeed limit interoperability of clients.

If the clients did all parse the Sieve itself, and could edit each  
other's rules using their respective gui's, then actually I think we  
would need some agreement on how to mark a rule inactive (so that it  
could be left in the script and turned back on by another client  
without having to re-create it). It's a good point, though I don't  
have a good answer myself.

Aaron

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 27 Mar 2008 00:52:01 +0100

> have a good answer myself.

agreed.  reconstructing the semantics of the rules is a challenge, e.g,
consider a UI where there's a simple rule for matching mailing lists.
this would probably be a macro with lots of heuristics, checking List-Id
but also Sender and stuff like that.  when loaded into a different
client it should of course handle this, but it may present the rule as a
sequence of tests rather than a single macro.  IMHO, it's not realistic
to standardise these things, since we will never catch all the
use-cases.

for the case of temporarily disabling a rule,  I think the most obvious
method is a simple

   if false { }

around the block.  that construct can hardly be used for anything else.
using comments is bad, since comments should be truly freeform and
without meaning.

-- 
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 26 Mar 2008 21:28:45 -0400

Hi Kjetil,

> using comments is bad, since comments should be truly freeform and

If this is something that clients want to do interoperably, we should 
probably ask Ned to add a "disable=(yes|no)" attribute to the XML <control> 
elements in draft-freed-sieve-in-xml, so that there is an explicit and easy 
way to do this in XML without having to resort to the if false {} construct.

-- 
Cyrus Daboo

---

From: Tony Hansen <[email-masked]>
Date: Wed, 26 Mar 2008 22:11:02 -0400

There still needs to be something to translate that "disable=yes" into, 
and I think the "if false {}" construct is as reasonable a thing as any.

	Tony

Cyrus Daboo wrote:
> probably ask Ned to add a "disable=(yes|no)" attribute to the XML 
> <control> elements in draft-freed-sieve-in-xml, so that there is an 
> explicit and easy way to do this in XML without having to resort to the 
> if false {} construct.
>

---

From: Patrick Ben Koetter <[email-masked]>
Date: Thu, 27 Mar 2008 10:03:11 +0100

* Nigel Swinson <[email-masked]>:
> Agreed, and this is actually what I chose to do with our implementation.  It
> has the added advantage of still doing compilation/syntax checking on the
> disabled rule, whereas if it was just commented out it'll all be ignored...

It seems that there's an agreement on temporarily disabling a rule.
People should use:

        if false { }

I am fairly new to this list and not accustomed with its procedures. What
would I have to do to propose this agreement to become a standard?

Thanks,

p@rick

---

From: Alexandros Vellis <[email-masked]>
Date: Thu, 27 Mar 2008 21:48:01 +0200

Tony Hansen <[email-masked]> wrote: 
> There still needs to be something to translate that "disable=yes"
> into, and I think the "if false {}" construct is as reasonable a
> thing as any.

Agreed.

To the original poster:

It's a challenge to represent a script in a user interface. The
designer of the UI would have to think of many clever ways to represent
things like many conditions with complicated and/or logic in an
if-block, nested if-blocks, else blocks, intermediate actions etc..
That is, in order to make it usable to many people who are accustomed
to the filters interfaces of Outlook or Thunderbird.

While the "simplified" UIs that currently exist for Sieve work for some
people, it would be much more acceptable to have proper Sieve parsing
in as many applications as possible. Whether that happens because of
clients that use XML tools and servers that serve an XML representation
of Sieve, or because of clients that parse scripts by using Sieve
parsers[1], that's irrelevant -- for the users anyway.

Avel :)

[1] http://sieve.info/libraries

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 31 Mar 2008 23:41:29 +0100

Hi Patrick,

>would I have to do to propose this agreement to become a standard?  
You need to write a short IETF draft on this and then get it published 
as an RFC.
Contact me off-list if you need to know more details.

Date: Mon, 31 Mar 2008 12:24:43 -0400
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Charter update
Sender: [email-masked]

Hi folks,
We have heard back from most people and at this point the Chairs are happy 
that there is enough interest for us to re-charter and take on the new 
proposed work.

Couple of points:

- Both draft-freed-sieve-date-index-08.txt and 
draft-freed-sieve-environment-03.txt are now progressing through IESG. 
Therefore we propose dropping those from the new charter.

- A suggestion was made to add a work item to address EAI/IDN issues. It 
was felt better for us to address this rather than have EAI take the work 
on, but we would like to here from others on what they think about this.

The new charter below reflects the changes discussed above. Next we will 
come up with some milestones and then hand off to the AD.

---
The SIEVE email filtering language is specified in RFC 5228, together with 
a number of extensions.

The SIEVE working group is being re-chartered to:

(1) Finish work on existing in-progress Working Group documents:

	(a) Body (draft-ietf-sieve-body-07.txt)
	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

(2) Finalize and publish the following SIEVE extensions as proposed 
standards:

	(a) iHave (draft-freed-sieve-ihave-01.txt)
	(b) Notary (draft-freed-sieve-notary-01.txt)
	(c) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
	(d) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
	(e) ManageSIEVE (draft-martin-managesieve-08.txt)
	(f) RegEx (draft-ietf-sieve-regex-00.txt)
	(g) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
	(h) Include/multi-script (draft-daboo-sieve-include-05.txt)
	(i) Address data (draft-melnikov-sieve-external-lists-01)

Additional drafts may be added to this list, but only via a charter
revision. There must also be demonstrable willingness in the SIEVE
development community to actually implement a given extension before
it can be added to this charter.

(3) Work on a specification to describe how EAI/IDN issues should be 
handled in SIEVE.

(4) Work on a "Benefits of SIEVE" guide for client and server vendors that:
	(a) Describes the SIEVE protocol and its suite of extensions.
	(b) Explains the benefits of server-side filtering in practical terms.
	(c) Shows how client-side filtering can be migrated to SIEVE.

(5) Produce one or more informational RFCs containing a set of test scripts 
and test email messages that are to be filtered by the scripts, and the 
expected results of that filtering. This will serve as the basis of a 
interoperability test suite to help determine the suitability of moving the 
base specification and selected extensions to Draft status.

-- 
Cyrus Daboo

Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Fri, 28 Mar 2008 14:16:44 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-freed-sieve-environment-04
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> On Tue, 2008-03-25 at 09:52 -0700, Ned Freed wrote:
> > > On Sun, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> > > > Also a good point. I have added:
> > > >
> > > >   The remote-host environment item defined in this specification is usually
> > > >   determined by performing a PTR DNS lookup on the client IP address. This
> > > >   information may come from an untrusted source. For example, the test:
> [...]
> > > sorry, I don't understand what this means.  is the existence of a PTR
> > > record sufficient?
> >
> > Who knows? The mechanism used to obtian the remote-host isn't (and should not
> > be) specified. As such, a PTR could be sufficient. Or it may not be - some
> > systems do a backwards-forwards check. And there can even be cases when a PTR
> > record isn't needed - DNS names aren't the only game in town, you know.

> ok.  I think it could be made a little clearer, though.  how about:

>         How to determine the remote-host environment item defined in
>         this specification is left up to the implementation, e.g, if TLS
>         is in use, the remote system's name can be extracted from the
>         client certificate if the signer is trusted.  Probably more
>         commonly it will be determined by performing a PTR DNS lookup on
>         the client IP address.  This information may come from an
>         untrusted source.  For example, the test:

I really don't want to get into the whole TLS cert thing in this document.

> another alternative, with no specific details about alternatives:

>         An implementation can use any technique to determine the
>         remote-host environment item defined in this specification, and
>         the trustworthiness of the result will vary.  One common method
>         will be to perform a PTR DNS lookup on the client IP address.
>         This information may come from an untrusted source.  For
>         example, the test:

This, OTOH, is fine. I'll include it in the next revision.

				Ned

Date: Thu, 27 Mar 2008 21:48:01 +0200
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Subject: Re: Standard to selectively disable rules in sieve script?
Organization: National and Kapodistrian University of Athens
Sender: [email-masked]

Agreed.

To the original poster:

Avel :)

Date: Thu, 27 Mar 2008 10:03:11 +0100
From: Patrick Ben Koetter <[email-masked]>
To: [email-masked]
Subject: Re: Standard to selectively disable rules in sieve script?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

        if false { }

Thanks,

p@rick

-- 
state of mind
Agentur f�r Kommunikation, Design und Softwareentwicklung

Amtsgericht M�nchen        Partnerschaftsregister PR 563

Date: Wed, 26 Mar 2008 22:11:02 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Standard to selectively disable rules in sieve script?
Sender: [email-masked]

	Tony

> explicit and easy way to do this in XML without having to resort to the 

Date: Wed, 26 Mar 2008 21:28:45 -0400
From: Cyrus Daboo <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>, Aaron Stone <[email-masked]>
cc: Patrick Ben Koetter <[email-masked]>, [email-masked]
Subject: Re: Standard to selectively disable rules in sieve script?
Sender: [email-masked]

Hi Kjetil,

-- 
Cyrus Daboo

Subject: Re: [Fwd: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
From: Kjetil Torgrim Homme <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Date: Thu, 27 Mar 2008 01:11:53 +0100
Sender: [email-masked]

[Hannes Tschofenig <[email-masked]>]:
>    o  The "Received:" fields from the triggering message MAY be retained
>       in the notification message, as these may help detect and prevent
>       mail loops.  The "Auto-Submitted" header field MUST be placed
>       above these (see Section 2.7.1).  URI headers with hname
>       "received" are considered unsafe, and will be ignored.
> 
> Why is this a MAY and not a MUST? 

normal bounces do not copy Received fields, either.  RFC 3464 is silent
on this issue, but the example messages do not contain "extraneous"
Received fields.  of course DSNs have null envelope-from, which is a
better safeguard.

as long as the implementation adds Auto-Submitted and make sure not to
respond to Auto-Submitted messages, the risk of a loop is very small,
even if other autoresponders have never heard of that header.  they will
need to actively remove that header field to cause a loop, and if an
implementation is that broken, who knows what it'll do to Received?

the notification is a freshly generated message, so to me it is "lying"
about the message's origins to include Received fields which are really
about another message.

-- 
Kjetil T.

Subject: Re: Standard to selectively disable rules in sieve script?
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Patrick Ben Koetter <[email-masked]>, [email-masked]
Date: Thu, 27 Mar 2008 00:52:01 +0100
Sender: [email-masked]

   if false { }

-- 
Kjetil T.

Subject: Re: Comments on draft-freed-sieve-environment-04
From: Kjetil Torgrim Homme <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Date: Thu, 27 Mar 2008 00:32:21 +0100
Sender: [email-masked]

On Tue, 2008-03-25 at 09:52 -0700, Ned Freed wrote:
> > On Sun, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> > > Also a good point. I have added:
> > >
> > >   The remote-host environment item defined in this specification is usually
> > >   determined by performing a PTR DNS lookup on the client IP address. This
> > >   information may come from an untrusted source. For example, the test:
[...]
> > sorry, I don't understand what this means.  is the existence of a PTR
> > record sufficient?
> 
> Who knows? The mechanism used to obtian the remote-host isn't (and should not
> be) specified. As such, a PTR could be sufficient. Or it may not be - some
> systems do a backwards-forwards check. And there can even be cases when a PTR
> record isn't needed - DNS names aren't the only game in town, you know.

ok.  I think it could be made a little clearer, though.  how about:

        How to determine the remote-host environment item defined in
        this specification is left up to the implementation, e.g, if TLS
        is in use, the remote system's name can be extracted from the
        client certificate if the signer is trusted.  Probably more
        commonly it will be determined by performing a PTR DNS lookup on
        the client IP address.  This information may come from an
        untrusted source.  For example, the test:

another alternative, with no specific details about alternatives:

        An implementation can use any technique to determine the
        remote-host environment item defined in this specification, and
        the trustworthiness of the result will vary.  One common method
        will be to perform a PTR DNS lookup on the client IP address.
        This information may come from an untrusted source.  For
        example, the test:

what do you think?
-- 
Kjetil T.

Cc: [email-masked]
From: Aaron Stone <[email-masked]>
To: Patrick Ben Koetter <[email-masked]>
Subject: Re: Standard to selectively disable rules in sieve script?
Date: Wed, 26 Mar 2008 15:58:27 -0700
Sender: [email-masked]

Most of the Sieve clients don't actually parse the Sieve rulesets, =20
unfortunately. They tend to do what Avelsieve does, which is to leave =20=

itself a comment in a particular format (for Avelsieve, it's a =20
serialized PHP array) so that it knows what the next block of code does.

If the clients did all parse the Sieve itself, and could edit each =20
other's rules using their respective gui's, then actually I think we =20
would need some agreement on how to mark a rule inactive (so that it =20
could be left in the script and turned back on by another client =20
without having to re-create it). It's a good point, though I don't =20
have a good answer myself.

Aaron

On Mar 26, 2008, at 2:45 PM, Patrick Ben Koetter wrote:
>
> I've been reading the RFCs and couldn't find an answer to the =20
> following
> question:
>
> Is there a standard syntax/notation to disable a single rule/command =20=

> within a
> I couldn't find anything in the RFCs, but what I found is that =20
> everybody seems
> The bad thing seems to be that even though everybody agrees to use =20
> comments
> nobody seems to agree on one way to do it - one way all =20
> implementations
> understand.
>
> My research indicates that interoperability among sieve script =20
> clients is lost
> A script edited by avelsieve - this is pure fiction, I didn't test =20
> this, but
> it serves to proove my point - (probably) won't work for KMail, =20
> because KMail
> is unable to recognize rules that have been disabled by avelsieve =20
> and vice
> versa.
>
> If I am correct, then - in my eyes - this is a major drawback in =20
> making Sieve
> useful and popular.
>
> Am I missing something?
>
> Thanks,
>
> p@rick
>
> --=20
> state of mind
> Agentur f=FCr Kommunikation, Design und Softwareentwicklung
>
> Amtsgericht M=FCnchen        Partnerschaftsregister PR 563
>

Date: Wed, 26 Mar 2008 23:15:26 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Alexey Melnikov writes:
>> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs 
>> need to be changed to MUSTs. See my forwarded reply.
>
> I don't mind making these MUST.

I guess I really mean "I don't mind, but I don't really see the point 
and SHOULD seems strong enough". Quoting 2119:

    ... there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Arnt

Date: Wed, 26 Mar 2008 22:45:19 +0100
From: Patrick Ben Koetter <[email-masked]>
To: [email-masked]
Subject: Standard to selectively disable rules in sieve script?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Am I missing something?

Thanks,

p@rick

-- 
state of mind
Agentur f�r Kommunikation, Design und Softwareentwicklung

Amtsgericht M�nchen        Partnerschaftsregister PR 563

Date: Wed, 26 Mar 2008 18:31:54 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs 
> need to be changed to MUSTs. See my forwarded reply.

I don't mind making these MUST.

Except that I do just a little, but I'd wiggle even in case of MUST. 
Details below.

>>>   o  The "Subject:" field of the notification message MUST
...

If I were to implement notify-mailto, my code might use different RFC 
2047 encoding. If the original subject is invalid in some way I 
wouldn't respond in kind.

>> The part that reads:
>>
>>      If ":from" is not specified or is not valid, the envelope sender 
>>      of the notification message SHOULD be set either to the 
>>      envelope "to" field from the triggering message, as used by 
>>      Sieve, or to a fixed email address (so it "comes from the 
>>      notification system"), at the discretion of the implementation.
>>
>> already list all possible alternatives, so I don't think it is a 
>> SHOULD either.

Those aren't all possible alternatives, so although I don't mind MUST I 
rather like keeping SHOULD. (One other alternative is a system address 
with a single-use subaddress.)

Arnt

Date: Wed, 26 Mar 2008 13:32:19 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Barry Leiba <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: secdir review of draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

--On Wednesday, March 26, 2008 01:13:33 PM -0400 Barry Leiba 
<[email-masked]> wrote:

> In particular, I don't agree with Alexey's thought that if WE can't think
> of an alternative value for a field, our advice should be MUST.  I much
> prefer the other approach: if there's not a compelling reason for MUST,
> make it SHOULD and let the implementation determine whether there's a
> good reason not to comply with that (remember the meaning of SHOULD).

I agree with Barry here.  This is exactly what SHOULD is for.

-- Jeff

Date: Wed, 26 Mar 2008 13:13:33 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: secdir review of draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs need 
> to be changed to MUSTs. See my forwarded reply.

Alexey didn't forward my response to Hannes's review, so here's the 
relevant part of it:

--------------------------------------------------------
On the SHOULD vs MUST list, Alexey has actually had the same questions. 
  It's a clarification I've recently put in, because the text had said 
"is" (as in, "If the mailto URI contains a "body" header, the value of 
that header is used as the body of the notification message.")

I considered it this way:  In cases where it seemed that it really 
matters -- that some sense of interoperability of notifications is 
affected -- I used MUST. Otherwise, I used SHOULD or MAY.  In other 
words, I tried to avoid using MUST, where MUST wasn't necessary.

Alexey commented to me that it seemed to him that if there was no other 
reasonable choice, we ought to have MUST.  On the other hand, it seems 
to me that if there's not a *reason* for MUST, we ought to leave the 
choice to the implementor (or to whoever configures the system, or 
whatever), rather than being needlessly specific about something that 
really doesn't matter.
--------------------------------------------------------

I'm willing to change to MUST (obviously, I will if that's the WG 
consensus), but my strong sense is that it's wrong to prescribe 
behaviour that doesn't matter.  For Sieve notifications, it seems to me 
that "interoperability" means that one can move a script to another 
Sieve implementation and get reasonably consistent results in the 
notifications, such that the user would have a substantially similar 
experience.  My sense, there, is that what matters most is the subject 
of the message, so that's the only MUST (apart from Auto-Submitted, 
which has a functional purpose).  The other part that's probably 
important is the body, but there are various reasons for an 
implementation to want to control the body -- security configuration, 
notification infrastructure, whatever.  So that's a SHOULD.

In particular, I don't agree with Alexey's thought that if WE can't 
think of an alternative value for a field, our advice should be MUST.  I 
much prefer the other approach: if there's not a compelling reason for 
MUST, make it SHOULD and let the implementation determine whether 
there's a good reason not to comply with that (remember the meaning of 
SHOULD).

I normally don't like SHOULD in protocols.  This is a case where I think 
SHOULD is entirely appropriate.

Barry

Date: Wed, 26 Mar 2008 16:02:48 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

Folks, Cyrus and I as chairs need more feedback on whether SHOULDs need 
to be changed to MUSTs. See my forwarded reply.

Alexey Melnikov wrote:

> Subject:
> Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt
> From:
> Alexey Melnikov <[email-masked]>
> Date:
> Wed, 26 Mar 2008 13:04:19 +0000
> To:
> Hannes Tschofenig <[email-masked]>
>
> To:
> Hannes Tschofenig <[email-masked]>
> CC:
> [email-masked], [email-masked], Cyrus Daboo 
> <[email-masked]>, Lisa Dusseault <[email-masked]>
>
>
> Hi Hannes,
> Below are my opinions as a Sieve WG participant and not as the Sieve 
> WG chair:
>
> Hannes Tschofenig wrote:
> [...]
>
>>   o  The "To:" header field and the envelope recipient(s) of the
>>      notification message SHOULD be set to the address(es) specified in
>>      the URI (including any URI headers where the hname is "to").
>>
>> This could be a MUST as well. Otherwise you might want to say to what 
>> it is set in other cases.  
>>
> Indeed.
>
>>   o  The "Subject:" field of the notification message MUST contain the
>>      value defined by the :message notify tag, as described in
>>      [Notify].  If there is no :message tag and there is a "subject"
>>      header on the URI, then that value SHOULD be used.  If that is
>>      also absent, the subject SHOULD be retained from the triggering
>>      message.  Note that Sieve [Variables] can be used to advantage
>>      here, as shown in the example in Section 3.
>>
>>
>> Shouldn't the last SHOULD be a MUST? There do not seem to be too many 
>> other useful choices.
>
> Agreed. The only other choice I can think of is an implementation 
> defined string. I am not sure it is a good choice, but if it is, it 
> should be explicitly listed.
>
> Actually I think that both SHOULDs should be MUSTs.
> I am just imagining a support person trying to argue with a customer 
> about why a particular notification email had wrong subject, when the 
> "subject" URI header was specified.
>
>>   o  The "From:" header field of the notification message SHOULD be set
>>      to the value of the ":from" parameter to the notify action, if one
>>      is specified, has email address syntax and is valid according to
>>      the implementation specific security checks (see Section 3.3 of
>>      [Notify]).  If ":from" is not specified or is not valid, the
>>      "From:" header field of the notification message SHOULD be set
>>      either to the envelope "to" field from the triggering message, as
>>      used by Sieve, or to a fixed email address (so it "comes from the
>>      notification system"), at the discretion of the implementation.
>>      This may not be overridden by a "from" URI header, and any such
>>      URI header MUST be ignored.
>>
>>   o  If the envelope sender of the triggering message is empty, the
>>      envelope sender of the notification message MUST be empty as well,
>>      to avoid message loops.  Otherwise, the envelope sender of the
>>      notification message SHOULD be set to the value of the ":from"
>>      parameter to the notify action, if one is specified, has email
>>      address syntax and is valid according to the implementation
>>      specific security checks (see Section 3.3 of [Notify]).  If
>>      ":from" is not specified or is not valid, the envelope sender of
>>      the notification message SHOULD be set either to the envelope "to"
>>      field from the triggering message, as used by Sieve, or to a fixed
>>      email address (so it "comes from the notification system"), at the
>>      discretion of the implementation.  This may not be overridden by a
>>      "from" URI header, and any such URI header MUST be ignored.
>>
>>
>> For these two paragraphs the same question applies; why a SHOULD 
>> instead of a MUST
>>
> I also think the SHOULDs should be MUSTs here.
>
> I think  "address ... is valid according to the implementation 
> specific security checks" already provides enough leeway to 
> implementations if they want not to use a particular :from value.
>
> The part that reads:
>
>      If ":from" is not specified or is not valid, the envelope sender of
>      the notification message SHOULD be set either to the envelope "to"
>      field from the triggering message, as used by Sieve, or to a fixed
>      email address (so it "comes from the notification system"), at the
>      discretion of the implementation.
>
> already list all possible alternatives, so I don't think it is a 
> SHOULD either.
>

Date: Wed, 26 Mar 2008 13:07:38 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

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

--------------090204080804030901070008
Content-Type: message/rfc822;
 name="Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt"

Date: Wed, 26 Mar 2008 13:04:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: [email-masked], [email-masked], Cyrus Daboo <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt

Hi Hannes,
Below are my opinions as a Sieve WG participant and not as the Sieve WG 
chair:

Hannes Tschofenig wrote:
 [...]

>   o  The "To:" header field and the envelope recipient(s) of the
>      notification message SHOULD be set to the address(es) specified in
>      the URI (including any URI headers where the hname is "to").
>
>This could be a MUST as well. Otherwise you might want to say to what it is set in other cases. 
>  
>
Indeed.

>   o  The "Subject:" field of the notification message MUST contain the
>      value defined by the :message notify tag, as described in
>      [Notify].  If there is no :message tag and there is a "subject"
>      header on the URI, then that value SHOULD be used.  If that is
>      also absent, the subject SHOULD be retained from the triggering
>      message.  Note that Sieve [Variables] can be used to advantage
>      here, as shown in the example in Section 3.
>
>
>Shouldn't the last SHOULD be a MUST? There do not seem to be too many other useful choices. 
>
Agreed. The only other choice I can think of is an implementation 
defined string. I am not sure it is a good choice, but if it is, it 
should be explicitly listed.

Actually I think that both SHOULDs should be MUSTs.
I am just imagining a support person trying to argue with a customer 
about why a particular notification email had wrong subject, when the 
"subject" URI header was specified.

>   o  The "From:" header field of the notification message SHOULD be set
>      to the value of the ":from" parameter to the notify action, if one
>      is specified, has email address syntax and is valid according to
>      the implementation specific security checks (see Section 3.3 of
>      [Notify]).  If ":from" is not specified or is not valid, the
>      "From:" header field of the notification message SHOULD be set
>      either to the envelope "to" field from the triggering message, as
>      used by Sieve, or to a fixed email address (so it "comes from the
>      notification system"), at the discretion of the implementation.
>      This may not be overridden by a "from" URI header, and any such
>      URI header MUST be ignored.
>
>   o  If the envelope sender of the triggering message is empty, the
>      envelope sender of the notification message MUST be empty as well,
>      to avoid message loops.  Otherwise, the envelope sender of the
>      notification message SHOULD be set to the value of the ":from"
>      parameter to the notify action, if one is specified, has email
>      address syntax and is valid according to the implementation
>      specific security checks (see Section 3.3 of [Notify]).  If
>      ":from" is not specified or is not valid, the envelope sender of
>      the notification message SHOULD be set either to the envelope "to"
>      field from the triggering message, as used by Sieve, or to a fixed
>      email address (so it "comes from the notification system"), at the
>      discretion of the implementation.  This may not be overridden by a
>      "from" URI header, and any such URI header MUST be ignored.
>
>
>For these two paragraphs the same question applies; why a SHOULD instead of a MUST
>
I also think the SHOULDs should be MUSTs here.

I think  "address ... is valid according to the implementation specific 
security checks" already provides enough leeway to implementations if 
they want not to use a particular :from value.

The part that reads:

      If ":from" is not specified or is not valid, the envelope sender of
      the notification message SHOULD be set either to the envelope "to"
      field from the triggering message, as used by Sieve, or to a fixed
      email address (so it "comes from the notification system"), at the
      discretion of the implementation.

already list all possible alternatives, so I don't think it is a SHOULD 
either.

--------------090204080804030901070008--

Date: Wed, 26 Mar 2008 15:07:43 +0200 (EET)
Subject: Re: Proposed charter change
From: "Alexandros Vellis" <[email-masked]>
To: "SIEVE" <[email-masked]>
Importance: Normal
Sender: [email-masked]

The following, as an implementor of UI for creation of scripts. Most of
the features I "intend to support" will depend on the features that first
become available in servers. :)

> (1) Finish work on existing in-progress Working Group documents:
>
> 	(a) Body (draft-ietf-sieve-body-07.txt)
supported

> 	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
support an old notify version, will update to all new notification drafts
in the future

> 	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
Intend to support in the future

> 	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
Intend to support in the future

> 	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)
partially supported, intend to complete implementation

>
> (2) Finalize and publish the following SIEVE extensions as proposed
> standards:
>
> 	(a) Date/Index (draft-freed-sieve-date-index-08.txt)
Intend to support in the future

> 	(b) iHave (draft-freed-sieve-ihave-01.txt)
No plans

> 	(c) Environment (draft-freed-sieve-environment-03.txt)
No plans

> 	(d) Notary (draft-freed-sieve-notary-01.txt)
No plans

> 	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
Intend to support in the future. One of the most interesting drafts for
me. Allowing people to use XML tools to manipulate Sieve scripts would,
IMHO, help advance the development and popularity of UI tools for editing
Sieve.

> 	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
Intend to support in the future

> 	(g) ManageSIEVE (draft-martin-managesieve-08.txt)
Intend to update to new revision

> 	(h) RegEx (draft-ietf-sieve-regex-00.txt)
supported

> 	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
Intend to support in the future

> 	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
Intend to support in the future

> 	(k) Address data (draft-melnikov-sieve-external-lists-01)
Intend to support in the future :-)

-- 
Alexandros Vellis

Date: Wed, 26 Mar 2008 13:07:17 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

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

--------------050106050600080504060709
Content-Type: message/rfc822;
 name="[secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="[secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt"

Date: Tue, 25 Mar 2008 22:58:49 +0200
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These comments 
were written primarily for the benefit of the security area directors.  Document 
editors and WG chairs should treat these comments just like any other last call 
comments.

draft-ietf-sieve-notify-mailto-07.txt is an extension to draft-ietf-sieve-notify-12
to allow notifications to be sent by electronic mail.

Although I have not follwed the SIEVE work this document is fairly easy to read. 
The security consideration section is short but points to draft-ietf-sieve-notify-12.txt
and SIEVE. Fine to me! 

I was only wondering a bit about the placements of SHOULDs instead of MUSTs. 

A few examples below: 

   o  If the mailto URI contains a "body" header, the value of that
      header SHOULD be used as the body of the notification message.  If
      there is no "body" header, it is up to the implementation whether
      to leave the body empty or to use an excerpt of the original
      message.

Why isn't the first SHOULD a MUST? 

   o  The "Received:" fields from the triggering message MAY be retained
      in the notification message, as these may help detect and prevent
      mail loops.  The "Auto-Submitted" header field MUST be placed
      above these (see Section 2.7.1).  URI headers with hname
      "received" are considered unsafe, and will be ignored.

Why is this a MAY and not a MUST? 

   o  The "To:" header field and the envelope recipient(s) of the
      notification message SHOULD be set to the address(es) specified in
      the URI (including any URI headers where the hname is "to").

This could be a MUST as well. Otherwise you might want to say to what it is set in other cases. 

   o  The "Subject:" field of the notification message MUST contain the
      value defined by the :message notify tag, as described in
      [Notify].  If there is no :message tag and there is a "subject"
      header on the URI, then that value SHOULD be used.  If that is
      also absent, the subject SHOULD be retained from the triggering
      message.  Note that Sieve [Variables] can be used to advantage
      here, as shown in the example in Section 3.

Shouldn't the last SHOULD be a MUST? There do not seem to be too many other useful choices. 

   o  The "From:" header field of the notification message SHOULD be set
      to the value of the ":from" parameter to the notify action, if one
      is specified, has email address syntax and is valid according to
      the implementation specific security checks (see Section 3.3 of
      [Notify]).  If ":from" is not specified or is not valid, the
      "From:" header field of the notification message SHOULD be set
      either to the envelope "to" field from the triggering message, as
      used by Sieve, or to a fixed email address (so it "comes from the
      notification system"), at the discretion of the implementation.
      This may not be overridden by a "from" URI header, and any such
      URI header MUST be ignored.

   o  If the envelope sender of the triggering message is empty, the
      envelope sender of the notification message MUST be empty as well,
      to avoid message loops.  Otherwise, the envelope sender of the
      notification message SHOULD be set to the value of the ":from"
      parameter to the notify action, if one is specified, has email
      address syntax and is valid according to the implementation
      specific security checks (see Section 3.3 of [Notify]).  If
      ":from" is not specified or is not valid, the envelope sender of
      the notification message SHOULD be set either to the envelope "to"
      field from the triggering message, as used by Sieve, or to a fixed
      email address (so it "comes from the notification system"), at the
      discretion of the implementation.  This may not be overridden by a
      "from" URI header, and any such URI header MUST be ignored.

For these two paragraphs the same question applies; why a SHOULD instead of a MUST

Ciao
Hannes

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

--------------050106050600080504060709--

Date: Tue, 25 Mar 2008 14:38:02 -0400
From: Barry Leiba <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: Proposed charter change
Sender: [email-masked]

> Please review this and comment.

I think the proposed recharter is fine.

> We would like to see a "show of hands" from implementers on each of the 
> new extensions being proposed so that we can judge the interest in each.

I'm currently out of the loop of implementing.  While I'd like to change 
that, it's not likely with my current set of projects.  I don't know 
what plans, if any, the product divisions here have for Sieve.

> (3) Work on a "Benefits of SIEVE" guide for client and server vendors that:
>     (a) Describes the SIEVE protocol and its suite of extensions.
>     (b) Explains the benefits of server-side filtering in practical terms.
>     (c) Shows how client-side filtering can be migrated to SIEVE.

I'll happily co-author this, and perhaps take a stab at a first draft. 
One or two co-authors would be nice.

Barry

Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Tue, 25 Mar 2008 09:52:49 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-freed-sieve-environment-04
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> On Sun, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> > Also a good point. I have added:
> >
> >   The remote-host environment item defined in this specification is usually
> >   determined by performing a PTR DNS lookup on the client IP address. This
> >   information may come from an untrusted source. For example, the test:
> >
> >     if environment :matches "remote-host" "*.mydomain.com" { ... }
> >
> >   is not a good way to test whether the message came from 'outside' becaus
> >   anyone who can create a PTR record can create one that refers to whatever
> >   domain they choose.
> [...]
> >
> > I think a simpler way to handle this is to say that the name will
> > be blank if it cannot be resolved into a host name. How about:
> >
> >  "remote-host"
> >            => Host name of remote SMTP/LMTP/Submission client, if
> >               applicable and available. The empty string will be returned
> >               if for some reason this information cannot be obtained for
> >               the current client.

> sorry, I don't understand what this means.  is the existence of a PTR
> record sufficient?

Who knows? The mechanism used to obtian the remote-host isn't (and should not
be) specified. As such, a PTR could be sufficient. Or it may not be - some
systems do a backwards-forwards check. And there can even be cases when a PTR
record isn't needed - DNS names aren't the only game in town, you know.

> it seems so, given the above added caveat.  if so --
> how is a script able to detect a forgery?

It can't. That's the point.

				Ned

Subject: Re: Comments on draft-freed-sieve-environment-04
From: Kjetil Torgrim Homme <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Date: Tue, 25 Mar 2008 16:35:16 +0100
Sender: [email-masked]

On Sun, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> Also a good point. I have added:
> 
>   The remote-host environment item defined in this specification is usually
>   determined by performing a PTR DNS lookup on the client IP address. This
>   information may come from an untrusted source. For example, the test:
> 
>     if environment :matches "remote-host" "*.mydomain.com" { ... }
> 
>   is not a good way to test whether the message came from 'outside' becaus
>   anyone who can create a PTR record can create one that refers to whatever
>   domain they choose.
[...]
> 
> I think a simpler way to handle this is to say that the name will
> be blank if it cannot be resolved into a host name. How about:
> 
>  "remote-host"
>            => Host name of remote SMTP/LMTP/Submission client, if
>               applicable and available. The empty string will be returned
>               if for some reason this information cannot be obtained for
>               the current client.

sorry, I don't understand what this means.  is the existence of a PTR
record sufficient?  it seems so, given the above added caveat.  if so --
how is a script able to detect a forgery?

-- 
med venleg helsing,
Kjetil T.

Date: Mon, 24 Mar 2008 21:42:09 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Re: Recent changes to draft-ietf-sieve-notify-mailto
Sender: [email-masked]

Alexey Melnikov wrote:

> Barry kindly summarized his changes in -07. I though that they should 
> be mentioned on the mailing list.
>
> Barry Leiba wrote:
>
>> I've just submitted an -07 draft, as agreed in Philadelphia, and 
>> that's the version that should be reviewed for Last Call.  There are 
>> three main changes:
>>
>> 1. In section 2.7, I changed a number of instances of "is" to "MUST 
>> be" or "SHOULD be", as in 'The "From:" header field of the 
>> notification message is set to [...].'
>
Speaking as an individual WG participant: I disagree with some new 
SHOULDs (I think they must be MUSTs ;-)) and will post a separate 
message on this.

>> 2. In section 2.7, I qualified Auto-Submitted as a trace field, and 
>> specified that it MUST be placed above the Received fields that were 
>> copied from the triggering message.  Now that Auto-Submitted is 
>> referred to in two places, I created a new section, 2.7.1, that 
>> specifies it.
>>
>> 3. I added two OPTIONAL parameters to auto-submitted (owner-email and 
>> owner-token), and I changed the registry definition and the example 
>> accordingly.
>

Date: Mon, 24 Mar 2008 21:40:42 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Recent changes to draft-ietf-sieve-notify-mailto
Sender: [email-masked]

Barry kindly summarized his changes in -07. I though that they should be 
mentioned on the mailing list.

Barry Leiba wrote:

> I've just submitted an -07 draft, as agreed in Philadelphia, and 
> that's the version that should be reviewed for Last Call.  There are 
> three main changes:
>
> 1. In section 2.7, I changed a number of instances of "is" to "MUST 
> be" or "SHOULD be", as in 'The "From:" header field of the 
> notification message is set to [...].'
>
> 2. In section 2.7, I qualified Auto-Submitted as a trace field, and 
> specified that it MUST be placed above the Received fields that were 
> copied from the triggering message.  Now that Auto-Submitted is 
> referred to in two places, I created a new section, 2.7.1, that 
> specifies it.
>
> 3. I added two OPTIONAL parameters to auto-submitted (owner-email and 
> owner-token), and I changed the registry definition and the example 
> accordingly.

Date: Mon, 24 Mar 2008 21:10:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-freed-sieve-environment-04
Sender: [email-masked]

(Speaking as an individual contributor.)

Ned Freed wrote:

>> Perhaps there should be a prefix on the value that indicates the 
>> address family, or it should be formatted like the 'host'
>> part of URI?
>
>> Note that the obvious test of
>>      environment :matches "remote-ip" "*.*.*.*"
>
>> will match an IPv6 address literal if the implementation uses the
>>      x:x:x:x:x:x:d.d.d.d
>> form, such as with the IPv4 compat addresses, ala "::FFFF:1.2.3.4".
>
>> (Yes, this thought was triggered by the "IPv6-only" experiment during 
>> the
>> IETF technical plenary.)
>
> Well, I certainly hope that for any given address there's exactly one 
> way it
> will end up being represented. If that's not the case then there's a 
> major
> problem that goes far beyond this specific issue.
>
> There's also the issue of how any future sort of address should be 
> handled.
> Since RFC 2821 has already had to deal with this I think the best way 
> to handle
> it is by referring to the formats defined there. I currently have:
>
> "remote-ip"
>           => IP address of remote SMTP/LMTP/Submission client, if
>              applicable and available. IPv4, IPv6, and other types of
>              addresses are respectively represented in the formats
>              defined by the IPv4-address-literal, IPv6-address-literal,
>              and General-address-literal productions defined in
>              [RFC 2821] section 4.1.3.

As a side note, I think RFC 2821 IPv6 format sucks, because it doesn't 
match what socket functions return on various OSes. (RFC 2821 uses
"IPv6:" prefix). But it is too late to fix that. So, under the 
circumstances, your proposal is quite reasonable.

>> There probably should be a security consideration that explains that the
>> value of the "remote-host" item may be controlled by an untrusted 
>> source.
>> For example, the test
>>      environment :matches "remote-host" "*.mydomain.com"
>
>> is *not* a good way to test whether the message came from 'outside' 
>> unless
>> the implementation there's some sort of IP->host->IP consistency check
>> made.
>
> Also a good point. I have added:
>
>  The remote-host environment item defined in this specification is 
> usually
>  determined by performing a PTR DNS lookup on the client IP address. This
>  information may come from an untrusted source. For example, the test:
>
>    if environment :matches "remote-host" "*.mydomain.com" { ... }
>
>  is not a good way to test whether the message came from 'outside' becaus

typo: because

>  anyone who can create a PTR record can create one that refers to 
> whatever
>  domain they choose. 

The text looks good to me.

>> (The sendmail MTA faced the above issues some time ago for the 
>> pre-defined
>> variables it provides to its rulesets.  To quote the sendmail operations
>> guide, it defined variables as follows:
>>        ${client_addr}
>>             The  IP  address  of  the  SMTP   client.    IPv6
>>             addresses  are  tagged  with  "IPv6:"  before the
>>             address.  Defined in the SMTP server only.
>
>>        ${client_name}
>>             The host name of the SMTP client.   This  may  be
>>             the  client's  bracketed IP address in the form [
>>             nnn.nnn.nnn.nnn    ]    for    IPv4     and     [
>>             IPv6:nnnn:...:nnnn  ] for IPv6 if the client's IP
>>             address is not resolvable, or if it is resolvable
>>             but  the  IP  address  of  the  resolved hostname
>>             doesn't match the original IP  address.   Defined
>>             in    the    SMTP    server   only.    See   also
>>             ${client_resolve}.
>
> I think a simpler way to handle this is to say that the name will
> be blank if it cannot be resolved into a host name. How about:

I like that.

> "remote-host"
>           => Host name of remote SMTP/LMTP/Submission client, if
>              applicable and available. The empty string will be returned
>              if for some reason this information cannot be obtained for
>              the current client.

Date: Sun, 23 Mar 2008 20:54:09 -0600
From: Philip Guenther <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked]
Subject: Re: Comments on draft-freed-sieve-environment-04
Sender: [email-masked]

On Sun, 23 Mar 2008, Ned Freed wrote:
<elided>

Looks good now, thanks.

Philip Guenther

Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Sun, 23 Mar 2008 10:50:10 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-freed-sieve-environment-04
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

> If the SMTP session was over IPv6, what should the "remote-ip" environment
> item be set to?

I would think that in this case it would obviously be the IPv6 address.
However, I take your point that the format of such addresses needs to be
specified - the underlying standards for address formats having failed to
specify this with sufficient clarity or generality, it is now up to every
application protocol where such addresses appear to deal with it separately.
Sigh. Not the way it should be, but how it is.

  Perhaps there should be a prefix on the value that
> indicates the address family, or it should be formatted like the 'host'
> part of URI?

> Note that the obvious test of
>  	environment :matches "remote-ip" "*.*.*.*"

> will match an IPv6 address literal if the implementation uses the
>  	x:x:x:x:x:x:d.d.d.d
> form, such as with the IPv4 compat addresses, ala "::FFFF:1.2.3.4".

> (Yes, this thought was triggered by the "IPv6-only" experiment during the
> IETF technical plenary.)

Well, I certainly hope that for any given address there's exactly one way it
will end up being represented. If that's not the case then there's a major
problem that goes far beyond this specific issue.

There's also the issue of how any future sort of address should be handled.
Since RFC 2821 has already had to deal with this I think the best way to handle
it is by referring to the formats defined there. I currently have:

 "remote-ip"
           => IP address of remote SMTP/LMTP/Submission client, if
              applicable and available. IPv4, IPv6, and other types of
              addresses are respectively represented in the formats
              defined by the IPv4-address-literal, IPv6-address-literal,
              and General-address-literal productions defined in
              [RFC 2821] section 4.1.3.

> There probably should be a security consideration that explains that the
> value of the "remote-host" item may be controlled by an untrusted source.
> For example, the test
>  	environment :matches "remote-host" "*.mydomain.com"

> is *not* a good way to test whether the message came from 'outside' unless
> the implementation there's some sort of IP->host->IP consistency check
> made.

Also a good point. I have added:

  The remote-host environment item defined in this specification is usually
  determined by performing a PTR DNS lookup on the client IP address. This
  information may come from an untrusted source. For example, the test:

    if environment :matches "remote-host" "*.mydomain.com" { ... }

  is not a good way to test whether the message came from 'outside' becaus
  anyone who can create a PTR record can create one that refers to whatever
  domain they choose.

> (The sendmail MTA faced the above issues some time ago for the pre-defined
> variables it provides to its rulesets.  To quote the sendmail operations
> guide, it defined variables as follows:
>        ${client_addr}
>             The  IP  address  of  the  SMTP   client.    IPv6
>             addresses  are  tagged  with  "IPv6:"  before the
>             address.  Defined in the SMTP server only.

>        ${client_name}
>             The host name of the SMTP client.   This  may  be
>             the  client's  bracketed IP address in the form [
>             nnn.nnn.nnn.nnn    ]    for    IPv4     and     [
>             IPv6:nnnn:...:nnnn  ] for IPv6 if the client's IP
>             address is not resolvable, or if it is resolvable
>             but  the  IP  address  of  the  resolved hostname
>             doesn't match the original IP  address.   Defined
>             in    the    SMTP    server   only.    See   also
>             ${client_resolve}.

I think a simpler way to handle this is to say that the name will
be blank if it cannot be resolved into a host name. How about:

 "remote-host"
           => Host name of remote SMTP/LMTP/Submission client, if
              applicable and available. The empty string will be returned
              if for some reason this information cannot be obtained for
              the current client.

>        ${client_ptr}
>             The  result  of  the PTR lookup for the client IP
>             address.    Note:   this   is   the    same    as
>             ${client_name}  if  and only if ${client_resolve}
>             is OK.  Defined in the SMTP server only.

>        ${client_resolve}
>             Holds  the  result  of  the  resolve   call   for
>             ${client_name}.  Possible values are:

>                 OK        resolved successfully
>                 FAIL      permanent lookup failure
>                 FORGED    forward lookup doesn't match reverse lookup
>                 TEMP      temporary lookup failure

>             Defined   in  the  SMTP  server  only.   sendmail
>             performs a hostname lookup on the IP  address  of
>             the  connecting client.  Next the IP addresses of
>             that hostname are looked up.  If  the  client  IP
>             address  does  not  appear in that list, then the
>             hostname is maybe forged.  This is  reflected  as
>             the  value  FORGED  for  ${client_resolve} and it
>             also shows up in $_ as "(may be forged)".

> While client_ptr and client_resolve are probably overkill for the sieve
> environment extension, the tagging in client_addr and precise definition
> of when client_name contains a name and not an address literal seem like
> practical guidance in this area.)

I agree - see above for my proposed solution for this issue.

				Ned

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-11.txt 
Date: Fri, 21 Mar 2008 11: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: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-11.txt
	Pages		: 12
	Date		: 2008-3-21
	
This document defines two new actions for the "Sieve" email
   filtering language that add and delete email header fields.

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

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

--NextPart--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, sieve mailing list <[email-masked]>, sieve chair <[email-masked]>
Subject: Protocol Action: 'Sieve Email Filtering: Body  Extension' to Proposed Standard 
Date: Fri, 21 Mar 2008 06:37:00 -0700 (PDT)
Sender: [email-masked]

The IESG has approved the following document:

- 'Sieve Email Filtering: Body Extension '
   <draft-ietf-sieve-body-09.txt> as a Proposed Standard

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

The IESG contact persons are Lisa Dusseault and Chris Newman.

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

Technical Summary
 
The SIEVE body extension adds tests for the occurrence of one or more
strings in the body of an email message.

The draft has a detailed description of how interactions with other
SIEVE extensions/actions are handled.

The security considerations section covers several identified security
concerns.

Working Group Summary

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

Document Quality

A number of implementations of this extension have already been
developed and in some cases deployed. Most participants are eager to see
this specification published as an RFC.

Lisa Dusseault reviewed this spec for the IESG.

Document Shepherd: Cyrus Daboo <mailto:[email-masked]>

Date: Thu, 20 Mar 2008 16:54:11 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: action reject and smtp RCPT TO:
Sender: [email-masked]

Ned Freed said...
> AFAIK nobodhy is talking about not allowing this. The question is 
> whether or
> not we should specify all of the nuances involved in supporting this 
> mode of
> operation, and if we're going to whether or not this is the right place 
> to do
> it. I remain to be convinced of the need to specify this and I'm opposed to
> doing it in this document.

Where to do it is, I think, the key point.  And so I'll point out that 
Randy Gellens has a draft in lemonade, currently called "Notifications 
Architecture": 
http://tools.ietf.org/wg/lemonade/draft-ietf-lemonade-notifications/

The plan is to fold some Sieve-related stuff into it and perhaps rename 
it to "Notifications and Filter Architecture".  That might be a 
reasonable place to put this sort of discussion.

Barry

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-body-09.txt 
Date: Thu, 20 Mar 2008 09:30: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: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-09.txt
	Pages		: 13
	Date		: 2008-3-20
	
This document defines a new command for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

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

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

--NextPart--

Date: Thu, 20 Mar 2008 00:13:49 -0600
From: Philip Guenther <[email-masked]>
To: [email-masked]
cc: Lisa Dusseault <[email-masked]>
Subject: new body draft (-09) submitted
Sender: [email-masked]

I just submitted draft-ietf-sieve-body-09.txt with a handful of minor 
tweaks.  Could have done them as notes to the RFC editor, but as long as 
I'm feeling spritely, might as well just roll a new rev...

To quote the changelog in the draft:

11.1 Changes from draft-ietf-sieve-body-08.txt

    Add a "Capability Identifier" section to match existing RFCs.

    Make the normative and information references subsections of a
    "References" section to match existing RFCs.

    Tweak description field of the IANA registration.

    Change "wild card" to "wildcard".

A couple of those were in response to a review done by Christian Vogt back 
in January.  I had misfiled his comments and only found them again after 
the -08 revision was posted.  His major concern was that the 'no body' vs 
'empty body' distinction should not be made; I disagree and pushed back on 
that, citing parallelism with the 'header' and 'address' tests and the 
observation that the distinction can only affect tests that actually match 
the empty body.  While it's unlikely that a real user filter would care 
about this, a filter processing messages that were programmatically 
generated might.  <shurg>

Philip Guenther

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 19 Mar 2008 16:55:55 -0400
To: MTA filtering mailing list <[email-masked]>
Subject: Re: Final sanity check on draft-ietf-sieve-mime-loop-04.txt
Sender: [email-masked]

Hi,

nitpicking:

3.  Sieve Loops

5th(ish) paragraph contains:

   > If that
   > MIME part is a terminal MIME part (i.e. does not contain other MIME
   > parts) then the nested "for_every_loop" is simply ignored.

I believe this intends to say

   ... the nested "for_every_part" loop is imply ignored.

==========

4.1.  Test "header"

9th paragraph:

   > When used inside the context of a "for_every_part" iterator, and with
   > an ":anychild" tagged argument, the "header" test will examine the
   > current MIME part context and all it's nested MIME body parts,
   > returning true if any of them satisfies the test.

"it's" should be "its" -- picky, picky.

==========

9.2.  Example 2

In the example, the "enclose" action:

   >     enclose :subject "Warning" :text
   > WARNING! The enclosed message contains executable attachments.
   > These attachments types may contain a computer virus program
   > that can infect your computer and potentially damage your data.
   > 
   > Before clicking on these message attachments, you should verify
   > with the sender that this message was sent by them and not a
   > computer virus.
   > .

needs to end with a semicolon.

==========

less nitty:

I was about to go into some stuff about how I thought it would be better
to lay a fundamental foundation of MIME awareness on which this
extension could be layered; about how :mime not only seems superflous
but conflicts with :mime syntax and meaning in other extensions; about
how I'd rather see a generalized parameter extraction for headers that
had a parameter-list syntax (as opposed to :type and so forth).  But
then I realized I said a bunch of that last summer, but apparently
without any sympathy :)  That's the way it goes, but just for reference,
I still am of many of these opinions (and perhaps others ...):

   http://www.imc.org/ietf-mta-filters/mail-archive/msg03658.html

even though I see I fumble-fingered some bit(s) of it.

Yours,
mm

Date: Wed, 19 Mar 2008 08:56:02 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Cyrus Daboo <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: Proposed charter change
Sender: [email-masked]

Cyrus Daboo wrote:

> We would like to see a "show of hands" from implementers on each of the 
> new extensions being proposed so that we can judge the interest in each.

Here's what CMU currently has implemented and what I'm thinking about 
the rest.

>     (a) Body (draft-ietf-sieve-body-07.txt)

Done.  Will update if necessary.

>     (b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

Need to update to latest notify architecture and then fix mailto.

>     (c) Edit header (draft-ietf-sieve-editheader-10.txt)
>     (d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)

Not sure if we'd do either of these short term.

>     (e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

Will update to whatever is appropriate at the LMTP injection point.

>     (a) Date/Index (draft-freed-sieve-date-index-08.txt)

Will probably give this a good look.

>     (b) iHave (draft-freed-sieve-ihave-01.txt)

Already have a patch floating around.

>     (c) Environment (draft-freed-sieve-environment-03.txt)

Will probably give this a good look.

>     (d) Notary (draft-freed-sieve-notary-01.txt)
>     (e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
>     (f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)

Not sure if we'd do any of these short term.  XML would probably be at 
the top of the list.

>     (g) ManageSIEVE (draft-martin-managesieve-08.txt)

Done.

>     (h) RegEx (draft-ietf-sieve-regex-00.txt)

Done.  Will update accordingly.

>     (j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)

Not at the top of my list.

>     (k) Include/multi-script (draft-daboo-sieve-include-05.txt)

Done.

>     (k) Address data (draft-melnikov-sieve-external-lists-01)

Will have to think about this some more.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Wed, 19 Mar 2008 02:01:52 -0600
From: Philip Guenther <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked]
Subject: Comments on draft-freed-sieve-environment-04
Sender: [email-masked]

If the SMTP session was over IPv6, what should the "remote-ip" environment 
item be set to?  Perhaps there should be a prefix on the value that 
indicates the address family, or it should be formatted like the 'host' 
part of URI?

Note that the obvious test of
 	environment :matches "remote-ip" "*.*.*.*"

will match an IPv6 address literal if the implementation uses the
 	x:x:x:x:x:x:d.d.d.d
form, such as with the IPv4 compat addresses, ala "::FFFF:1.2.3.4".

(Yes, this thought was triggered by the "IPv6-only" experiment during the 
IETF technical plenary.)

There probably should be a security consideration that explains that the 
value of the "remote-host" item may be controlled by an untrusted source. 
For example, the test
 	environment :matches "remote-host" "*.mydomain.com"

is *not* a good way to test whether the message came from 'outside' unless 
the implementation there's some sort of IP->host->IP consistency check 
made.

(The sendmail MTA faced the above issues some time ago for the pre-defined 
variables it provides to its rulesets.  To quote the sendmail operations 
guide, it defined variables as follows:
       ${client_addr}
            The  IP  address  of  the  SMTP   client.    IPv6
            addresses  are  tagged  with  "IPv6:"  before the
            address.  Defined in the SMTP server only.

       ${client_name}
            The host name of the SMTP client.   This  may  be
            the  client's  bracketed IP address in the form [
            nnn.nnn.nnn.nnn    ]    for    IPv4     and     [
            IPv6:nnnn:...:nnnn  ] for IPv6 if the client's IP
            address is not resolvable, or if it is resolvable
            but  the  IP  address  of  the  resolved hostname
            doesn't match the original IP  address.   Defined
            in    the    SMTP    server   only.    See   also
            ${client_resolve}.

       ${client_ptr}
            The  result  of  the PTR lookup for the client IP
            address.    Note:   this   is   the    same    as
            ${client_name}  if  and only if ${client_resolve}
            is OK.  Defined in the SMTP server only.

       ${client_resolve}
            Holds  the  result  of  the  resolve   call   for
            ${client_name}.  Possible values are:

                OK        resolved successfully
                FAIL      permanent lookup failure
                FORGED    forward lookup doesn't match reverse lookup
                TEMP      temporary lookup failure

            Defined   in  the  SMTP  server  only.   sendmail
            performs a hostname lookup on the IP  address  of
            the  connecting client.  Next the IP addresses of
            that hostname are looked up.  If  the  client  IP
            address  does  not  appear in that list, then the
            hostname is maybe forged.  This is  reflected  as
            the  value  FORGED  for  ${client_resolve} and it
            also shows up in $_ as "(may be forged)".

While client_ptr and client_resolve are probably overkill for the sieve 
environment extension, the tagging in client_addr and precise definition 
of when client_name contains a name and not an address literal seem like 
practical guidance in this area.)

Philip Guenther

X-Spam-Score-scoring_explanation:
X-Spam-Score-spf_status:
X-Spam-Score-Spamcatcher1: c4cada40cab260410670f1f881840ccb
X-Spam-Score-Summary: 2,0,0,d02c0112dcf0853e,a0ea87fb493ec7f7,[email-masked],,RULES_HIT:2:355:379:481:539:540:541:542:543:567:599:601:945:946:968:973:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1535:1587:1593:1594:1605:1606:1730:1747:1766:1792:2073:2075:2078:2198:2199:2378:2393:2553:2559:2562:2693:2731:2828:2894:3027:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4117:4250:4425:4605:5007:6261:7522:7576:7903,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "MTA filtering mailing list" <[email-masked]>
Subject: Re: Final sanity check on draft-ietf-sieve-mime-loop-04.txt
Date: Tue, 18 Mar 2008 18:04:52 -0000
Sender: [email-masked]

>    I would like to ask all people who commented on the document earlier to
>    review if their comments were addressed. If there are no comments on
the
>    document before March 21st, I would recommend its publication.

4.1. Test "header"
-   The "header" test is extended with the addition of a new ":mime"
-   tagged argument and its associated options.
+   The "header" test is extended with the addition of new ":mime"
+   and ":anychild" tagged arguments and their associated options.

I guess this doesn't have to be the case, but I think it would make sense to
use header :anychild without a :mime argument in order to test header of
attached rfc2822 messages, or indeed to test the Content-Type headers of
child body parts as unparsed strings.  It seems clear if you use :anychild,
then you are asking for the mime structure to be evaluated.  I think this is
actually implied anyway when it goes on to say:

   When used inside the context of a "for_every_part" iterator, and with
   an ":anychild" tagged argument, the "header" test will examine the
   current MIME part context and all it's nested MIME body parts,
   returning true if any of them satisfies the test.

   :param  parses the header looking for MIME parameters in the header.
      The supplied string-list lists the names of any parameters to be
-      tested.  If any one named parameter value matches the test string
-      value, the test will return true.
+      tested.  If any one named parameter value matches any of the test
+      string values, the test will return true.

4.2. Test "address"

-   The "address" test is extended with the addition of a new ":mime"
-   tagged argument, which takes a number of other arguments.
+   The "address" test is extended with the addition of new ":mime"
+   and ":anychild" tagged arguments and their associated options.

4.3. Test "exists"

-   The "exists" test is extended with the addition of a new ":mime"
-   tagged argument, which takes one other argument.
+   The "exists" test is extended with the addition of new ":mime"
+   and ":anychild" tagged arguments.

5. Action Replace

Should we also preserve some trace fields?  I'd have thought typically
replace would be used to remove malicious content, in which case would it
not be helpful to at least have some way of knowing where the message came
from that produced the butchered message?  I'd suggest:

-  If the entire message is being replaced, a ":subject" parameter
+  If the entire message is being replaced, the optional ":subject"
parameter
   specifies a subject line to attach to the message that is generated.
   UTF-8 characters can be used in the string argument; implementations
   MUST convert the string to [RFC2047] encoded words if and only if
   non-ASCII characters are present.  Implementations MUST preserve the
   previous Subject header as an Original-Subject header.

   If the entire message is being replaced, a ":from" parameter may be
   used to specify an alternate address to use in the From field of the
   message that is generated.  The string must specify a valid [RFC2822]
   mailbox-list.  Implementations SHOULD check the syntax and generate
   an error when a syntactically invalid ":from" parameter is specified.
   Implementations MAY also impose restrictions on what addresses can be
   specified in a ":from" parameter; it is suggested that values that
   fail such a validity check simply be ignored rather than causing the
   replace action to fail.  Implementations MUST preserve the previous
   From header as an Original-From header.

+  Implementations MUST preserve all other header fields from the original
+  message with the exception of those relating to the MIME structure which
+  will need to be replaced.

Although I do note that the security section does at least indicate that
replace creates an entirely new message, so I'm sorry if we covered this
before and I just forgot.

6. Action Enclose
   If multiple "enclose" actions are executed by a script, only the text
-  specified on the last one is used when creating the enclosed message.
+  specified on the last one is used when creating the enclosed message,
+  the message in this case would not be enclosed multiple times.
   This action does not affect messages that are forwarded via a
-  "redirect" action.
+  "redirect" action, rather the unenclosed message would be what was
+  redirected.

   Specifically, the original message becomes a multipart/mixed message
   with two parts: a text/plain portion with the string argument as its
   body, and a message/rfc822 portion with the original message
   enclosed.  The Content-Type: header field becomes multipart/mixed.
-  The Subject: header is specified by the :subject argument.  Any
+  The optional Subject: header is specified by the :subject argument,
+  if not present the subject will be taken from the enclosed message.  Any
   headers specified by :headers are copied from the old message into
   the new message.  If not specified by :headers, Date: and From:
   headers should be synthesized to reflect the current date and the
   user running the Sieve action.

7. Action extract_text
   If extract_text is used outside the context of a "for_every_part"
   loop, the action will set the variable identified by varname to the
   empty string.

I suggest the above SHOULD be a compilation error, otherwise it should
return the empty string.

Cheers

Nigel

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-mailto-07.txt 
Date: Tue, 18 Mar 2008 11: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 Notification Mechanism: mailto
	Author(s)       : B. Leiba, M. Haardt
	Filename        : draft-ietf-sieve-notify-mailto-07.txt
	Pages           : 16
	Date            : 2008-03-18

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

--NextPart--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-sieve-notify-mailto (Sieve Notification  Mechanism: mailto) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Mon, 17 Mar 2008 14:49:11 -0700 (PDT)
Sender: [email-masked]

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

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

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

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-06.txt

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

Date: Sat, 15 Mar 2008 23:15:28 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: Environment Extension) to Proposed Standard]
Sender: [email-masked]

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

FYI.

--------------030809090809050108060304
Content-Type: message/rfc822;
 name="Last Call: draft-freed-sieve-environment (Sieve Email Filtering: 	EnvironmentExtension) to Proposed Standard"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Last Call: draft-freed-sieve-environment (Sieve Email Filtering: 	EnvironmentExtension) to Proposed Standard"

To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Subject: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: 
	Environment Extension) to Proposed Standard 
Date: Fri, 14 Mar 2008 06:52:54 -0700 (PDT)
Reply-To: [email-masked]
Sender: [email-masked]

The IESG has received a request from an individual submitter to consider 
the following document:

- 'Sieve Email Filtering: Environment Extension '
   <draft-freed-sieve-environment-04.txt> as a Proposed Standard

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

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-freed-sieve-environment-04.txt

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

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

--------------030809090809050108060304--

Cc: Ned Freed <[email-masked]>, Philip Guenther <[email-masked]>, [email-masked]
Date: Sat, 15 Mar 2008 14:46:01 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Updated Sieve environment draft posted
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

> On Fri, 14 Mar 2008, Ned Freed wrote:
> ...
> >> > First of all, the specification says that any test against an unknown
> >> > item must fail unconditionally. This provides a simple way to check and
> >> > see if a given item is available:
> >> >
> >> >   if environment :matches "item" {...}
> >
> >> There's a pattern missing there.
> >
> > Right, sorry about that.
> >
> >> Regardless, the empty substring test is
> >> probably more efficient:
> >>  	if environment :contains "item" "" { ... }
> >
> > This almost always works, but not in the case where the environment
> > item has the null string as a possible return value.

> Ummm, what?  Are you saying that there exists some case where
>  	if environment :matches "item" "*" { ... }
> and
>  	if environment :contains "item" "" { ... }

> would return different results?

Sorry, my mistake, I was thinking of :is.

> If that's not what you meant, then I don't understand what you're saying.

> I strongly believe that <<:matches "*">> and <<:contains "">> MUST have
> the same result with *any* combination of test and comparator.

Certainly should be true of all tests and any comparator we've defined so far,
not entirely sure it will extend to all future comparators.

				Ned

Date: Sat, 15 Mar 2008 17:42:30 -0400
From: Philip Guenther <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

On Fri, 14 Mar 2008, Ned Freed wrote:
...
>> > First of all, the specification says that any test against an unknown
>> > item must fail unconditionally. This provides a simple way to check and
>> > see if a given item is available:
>> >
>> >   if environment :matches "item" {...}
>
>> There's a pattern missing there.
>
> Right, sorry about that.
>
>> Regardless, the empty substring test is
>> probably more efficient:
>>  	if environment :contains "item" "" { ... }
>
> This almost always works, but not in the case where the environment
> item has the null string as a possible return value.

Ummm, what?  Are you saying that there exists some case where
 	if environment :matches "item" "*" { ... }
and
 	if environment :contains "item" "" { ... }

would return different results?

If that's not what you meant, then I don't understand what you're saying.

I strongly believe that <<:matches "*">> and <<:contains "">> MUST have 
the same result with *any* combination of test and comparator.

Philip Guenther

Date: Sat, 15 Mar 2008 17:36:00 -0400
From: Philip Guenther <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
cc: IETF mta-filters list <[email-masked]>
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

On Sat, 15 Mar 2008, Mark E. Mallett wrote:
> Except that I made no suggestion that they be tied, and I even said that
> I liked the fact that the test(*) doesn't depend on variables.  What I
> opined was that the draft could state what the behavior would be in the
> presence of the variables extension

One barrier to implementing sieve extensions is exactly that the 
intersection of two extensions may require special handling.  While this 
is true by necessity for match-types and comparators, we should fight the 
tendency to add special cases for other combinations that aren't 
completely necessary.

> -- analogous to how it already
> states what the behavior is in the presence of the relational extension.
> Not that it require variables.

This particular special case seems unnecessary to me.  It appears to have 
been inherited or based on the similar exception for the 'envelope' test. 
IMHO, that behavior should not be propagated to 'environment'.  If you 
want to test whether an environment item returns the empty string, then 
just do exactly that!
 	if environment :is "foo" ""

My opinion is that the correct model for relational's :count is that it 
tests against "the number of distinct entities that would otherwise be 
matched against".  I.e., it's the number of different strings that could 
have been matched by <<:matches "*">>.  The count will be zero iff there 
were no entities to match against.

For environment, that would mean that the count will be zero if the item 
does not exist.  The current draft's exceptional handling of empty strings 
is a wart that does not increase the expressiveness of the test and should 
be removed.

(Stepping further up the abstraction ladder: a test command defines how to 
generate a set of zero or more strings.  The comparator and match-type 
arguments then define how that set of strings is matched against the keys. 
The :count match-type says "take the decimal representation of the 
cardinality of the set of match strings, collate (order) that against each 
key using the indicated comparator and return true if they collate in the 
direction indicated by the relational-match argument."  When we define new 
test commands, we should *ONLY* be specifying how it generates a set of 
strings to match against.)

Philip Guenther

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 15 Mar 2008 14:16:30 -0400
To: IETF mta-filters list <[email-masked]>
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

On Fri, Mar 14, 2008 at 09:37:12PM +0000, Alexey Melnikov wrote:
> I am planning to implement both environment and variables at some point. 
> But environment as written is just a couple of hours of work, while 
> variables is more like a couple of weeks of work. So I would rather not 
> tie environment to variables.

Except that I made no suggestion that they be tied, and I even said that
I liked the fact that the test(*) doesn't depend on variables.  What I
opined was that the draft could state what the behavior would be in the
presence of the variables extension -- analogous to how it already
states what the behavior is in the presence of the relational extension.
Not that it require variables.

I hadn't intended to follow up again, not having anything new to add,
but since two people commented on a perceived requirement to implement
variables according to my remarks, I figured I would.  To me, specifying
a variables namespace here adds utility and symmetry, which appeals to
me (although that's not always a complete justification for anything, I
fall on that side here), and won't require any later extension to do it,
which also appeals to me.  At any rate it's not a huge deal.

mm

(*)tho I did say "verb" - it's a bad habit of mine, like nailbiting.

Date: Fri, 14 Mar 2008 21:37:12 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Mark E Mallett <[email-masked]>, [email-masked]
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

Ned Freed wrote:

>>as it doesn't require variables, but also having the information
>>available via a variable namespace seems clean to me too since it builds
>>on language elements and concepts already out there.  But I can see some
>>of the drawbacks too: one being that it would make implementation of
>>this extension slightly harder/slower/less likely for any product that
>>also implements "variables" if this extension mandated adding a
>>variables namespace.  But only slightly.    
>>
>That's my main concern here - I want to keep this simple. I think the main
>use-case for environment is as a test.
>  
>
Agreed.
I am planning to implement both environment and variables at some point. 
But environment as written is just a couple of hours of work, while 
variables is more like a couple of weeks of work. So I would rather not 
tie environment to variables.

Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Fri, 14 Mar 2008 06:34:46 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Updated Sieve environment draft posted
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

> On Thu, 13 Mar 2008, Ned Freed wrote:
> ...
> >> There is a "host" item listed, which is the FQDN of the local host. It
> >> seems to me that one might want to know the host-only part of that
> >> string.  One could obtain it in a round-about way by using the "domain"
> >> environment item and the "host" item; but is it worth adding
> >> "host-only" ?
> >
> > Frankly, I think the use of shortform names is a bad thing that should
> > be discouraged whenever possible. (IT uses them extensively here at Sun
> > and they cause no end of problems.) I'm therefore very reluctant to add
> > such an item.

> I agree.  Unqualified hostnames should never appear in protocols and,
> IMHO, are only useful in space-constrained interactive environments, where
> the user can obtain the full form if they have any doubt.

> ...
> > First of all, the specification says that any test against an unknown
> > item must fail unconditionally. This provides a simple way to check and
> > see if a given item is available:
> >
> >   if environment :matches "item" {...}

> There's a pattern missing there.

Right, sorry about that.

> Regardless, the empty substring test is
> probably more efficient:
>  	if environment :contains "item" "" { ... }

This almost always works, but not in the case where the environment
item has the null string as a possible return value. Of course in every
case I can think of a null value is going to signify "information not
available", and I cannot think of a use-case where a script would want
to act differently given "item not supported' versus "information not 
available".

				Ned

Date: Fri, 14 Mar 2008 12:27:01 +0100
To: [email-masked]
Subject: Re: Proposed charter change
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> 	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

Implemented, following drafts closely.

> 	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

I would love to implement that, but I am afraid it requires substantial
design changes in Exim, which has always accepted the mail at the time
a filter runs.  It is very unlikely anybody implements that in Exim 4,
but that's a problem with Exim, not with the draft.

> 	(a) Body (draft-ietf-sieve-body-07.txt)
> 	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
> 	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
>
> (2) Finalize and publish the following SIEVE extensions as proposed 
> standards:
>
> 	(a) Date/Index (draft-freed-sieve-date-index-08.txt)
> 	(b) iHave (draft-freed-sieve-ihave-01.txt)
> 	(c) Environment (draft-freed-sieve-environment-03.txt)
> 	(d) Notary (draft-freed-sieve-notary-01.txt)
> 	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
> 	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
> 	(g) ManageSIEVE (draft-martin-managesieve-08.txt)
> 	(h) RegEx (draft-ietf-sieve-regex-00.txt)
> 	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
> 	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
> 	(k) Address data (draft-melnikov-sieve-external-lists-01)

None of these are implemented or and I don't plan to implement any
on my own.  We only require a minimal Sieve implementation.  SIP and
XMPP notification methods might become interesting, though, but not at
this time.

Michael

Date: Fri, 14 Mar 2008 11:15:58 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

Ned Freed writes:
>> as it doesn't require variables, but also having the information 
>> available via a variable namespace seems clean to me too since it 
>> builds on language elements and concepts already out there. But I 
>> can see some of the drawbacks too: one being that it would make 
>> implementation of this extension slightly harder/slower/less likely 
>> for any product that also implements "variables" if this extension 
>> mandated adding a variables namespace. But only slightly.
>
> That's my main concern here - I want to keep this simple. I think the 
> main use-case for environment is as a test.

Yes. I like the simplicity and brevity of the document, and I like that 
it doesn't depend on variables.

Arnt

Date: Fri, 14 Mar 2008 11:00:00 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Proposed charter change
Sender: [email-masked]

Cyrus Daboo writes:
> We would like to see a "show of hands" from implementers on each of=20
> the new extensions being proposed so that we can judge the interest=20
> in each.

OK. Other comments also below.

> Note that we will need document authors/editors to step up for items=20
> (3) and (4) if we are to include these.

I already have done some work on 4...

> The SIEVE email filtering language is specified in RFC 5228, together=20
> with a number of extensions.
>
> The SIEVE working group is being re-chartered to:
>
> (1) Finish work on existing in-progress Working Group documents:
>
>        (a) Body (draft-ietf-sieve-body-07.txt)

Have.

>        (b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

Unlikely. (We'll do notify and some of its children, but I don't feel=20
good about notifying about email messages using other email messages,=20
so mailto isn't an implementation candidate yet.)

>        (c) Edit header (draft-ietf-sieve-editheader-10.txt)

Very likely.

>        (d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)

Will do.

>        (e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

Have older version, will update. (Have updated? I'd have to check.)

> (2) Finalize and publish the following SIEVE extensions as proposed=20
> standards:
>
>        (a) Date/Index (draft-freed-sieve-date-index-08.txt)

Have.

>        (b) iHave (draft-freed-sieve-ihave-01.txt)

Likely.

>        (c) Environment (draft-freed-sieve-environment-03.txt)

Very likely.

>        (d) Notary (draft-freed-sieve-notary-01.txt)

Very likely.

>        (e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)

Yes or no. We'll do Sieve in XML, but I don't know whether we'll do it=20
that way. I don't see any reason to do it differently, but if one=20
appears...

>        (f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)

Likely.

>        (g) ManageSIEVE (draft-martin-managesieve-08.txt)

Have.

>        (h) RegEx (draft-ietf-sieve-regex-00.txt)

Unlikely.

>        (j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)

Don't know.

>        (k) Include/multi-script (draft-daboo-sieve-include-05.txt)

Include is uncertain. (Our code is developing along the lines of Jutta's=20
expired multiscript document, though, so who knows.)

>        (k) Address data (draft-melnikov-sieve-external-lists-01)

Uncertain... more likely no than yes.

> Additional drafts may be added to this list, but only via a charter
> revision. There must also be demonstrable willingness in the SIEVE
> development community to actually implement a given extension before
> it can be added to this charter.

FWIW, we'll do one other extension, but I think I'll talk more about=20
that only when we have code.

> (3) Work on a "Benefits of SIEVE" guide for client and server vendors =
that:
>        (a) Describes the SIEVE protocol and its suite of extensions.
>        (b) Explains the benefits of server-side filtering in practical =
terms.
>        (c) Shows how client-side filtering can be migrated to SIEVE.

Laudable, I'm sure, but my only comment is that I know little about a=20
little and almost nothing about the rest.

> (4) Produce one or more informational RFCs containing a set of test=20
> scripts and test email messages that are to be filtered by the=20
> scripts, and the expected results of that filtering. This will serve=20
> as the basis of a interoperability test suite to help determine the=20
> suitability of moving the base specification and selected extensions=20
> to Draft status.

I did some work on that last summer, which I sent to Barry (and Alexey?=20
don't remember any more). I'd be willing to continue that on my own.

Arnt

Cc: Ned Freed <[email-masked]>, Mark E Mallett <[email-masked]>, [email-masked]
Date: Thu, 13 Mar 2008 21:03:37 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Updated Sieve environment draft posted
To: Mark E Mallett <[email-masked]>
Sender: [email-masked]

> On Thu, Mar 13, 2008 at 04:30:09PM -0700, Ned Freed wrote:
> >
> > > I also think that the draft could benefit by providing for some behavior
> > > in the presence of the "variables" extension, e.g. by defining a
> > > namespace such as "env." and stating what value is returned if the item
> > > is undefined in the implementation.  I realize that one could obtain the
> > > values by using :matches, wildcarding, and variable assignments;
> > > having namespace support would be more straightforward.
> >
> > First of all, the specification says that any test against an unknown
> > item must fail unconditionally. This provides a simple way to check and
> > see if a given item is available:
> >
> >    if environment :matches "item" {...}
> >
> > This test only succeeds if "item" is defined. Since this doesn't appear
> > to be obvious I think I'll add a note about it to the text.

> Actually I think it is pretty obvious, I don't think that needs to be
> clarified.  What I was saying is that while you can indeed use
> ":matches" to get the value into a variable:

>     if environment :matches "domain" "*" { set "domain" "${0}"; }

> using a variable namespace would be more straightforward, and much more
> efficient.  e.g.:

>     set "domain" "${env.domain}";

> and that basically it would be good to have that specified here than not
> to have it at all, or than having it done separately with yet another
> capability.

It's a bit more elegant but I'm just not convinced it is worth it.

> I may be missing the point of your reply.  It occurs to me that you are
> replying to my phrase "stating what value is returned if the item is
> undefined in the implementation" -- but that is in a sentence that is
> about a possible "variables" namespace, not the "environment" verb.

Right.

>  In
> evaluating a variables namespace reference to a non-existent or
> unsupported item, say "${env.remote-host}" when remote-host isn't
> meaningful, or "${env.foobar}" when foobar isn't a real item, the
> hypothetical text that addresses the variables namespace would have to
> describe what value is returned in those situations.  As you say, the
> behavior of the "environment" action is pretty clear already.
    
Yes, that's an issue with the namespace approach.

> > I did consider using namespaces as a means of returning multiple/structured
> > values from environment tests, but I eventually decided it wasn't worth it.

> Different perspectives, I guess.  I like having the "environment" verb,

I think you mean test, not verb.

> as it doesn't require variables, but also having the information
> available via a variable namespace seems clean to me too since it builds
> on language elements and concepts already out there.  But I can see some
> of the drawbacks too: one being that it would make implementation of
> this extension slightly harder/slower/less likely for any product that
> also implements "variables" if this extension mandated adding a
> variables namespace.  But only slightly.

That's my main concern here - I want to keep this simple. I think the main
use-case for environment is as a test.

				Ned

Date: Thu, 13 Mar 2008 22:18:43 -0400
From: Philip Guenther <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked]
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

On Thu, 13 Mar 2008, Ned Freed wrote:
...
>> There is a "host" item listed, which is the FQDN of the local host. It 
>> seems to me that one might want to know the host-only part of that 
>> string.  One could obtain it in a round-about way by using the "domain" 
>> environment item and the "host" item; but is it worth adding 
>> "host-only" ?
>
> Frankly, I think the use of shortform names is a bad thing that should 
> be discouraged whenever possible. (IT uses them extensively here at Sun 
> and they cause no end of problems.) I'm therefore very reluctant to add 
> such an item.

I agree.  Unqualified hostnames should never appear in protocols and, 
IMHO, are only useful in space-constrained interactive environments, where 
the user can obtain the full form if they have any doubt.

...
> First of all, the specification says that any test against an unknown
> item must fail unconditionally. This provides a simple way to check and
> see if a given item is available:
>
>   if environment :matches "item" {...}

There's a pattern missing there.  Regardless, the empty substring test is 
probably more efficient:
 	if environment :contains "item" "" { ... }

Philip Guenther

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 13 Mar 2008 20:47:01 -0400
To: Ned Freed <[email-masked]>
Cc: Mark E Mallett <[email-masked]>, [email-masked]
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

On Thu, Mar 13, 2008 at 04:30:09PM -0700, Ned Freed wrote:
> 
> > I also think that the draft could benefit by providing for some behavior
> > in the presence of the "variables" extension, e.g. by defining a
> > namespace such as "env." and stating what value is returned if the item
> > is undefined in the implementation.  I realize that one could obtain the
> > values by using :matches, wildcarding, and variable assignments;
> > having namespace support would be more straightforward.
> 
> First of all, the specification says that any test against an unknown
> item must fail unconditionally. This provides a simple way to check and
> see if a given item is available:
> 
>    if environment :matches "item" {...}
> 
> This test only succeeds if "item" is defined. Since this doesn't appear
> to be obvious I think I'll add a note about it to the text.

Actually I think it is pretty obvious, I don't think that needs to be
clarified.  What I was saying is that while you can indeed use
":matches" to get the value into a variable:

    if environment :matches "domain" "*" { set "domain" "${0}"; }

using a variable namespace would be more straightforward, and much more
efficient.  e.g.:

    set "domain" "${env.domain}";

and that basically it would be good to have that specified here than not
to have it at all, or than having it done separately with yet another
capability.

I may be missing the point of your reply.  It occurs to me that you are
replying to my phrase "stating what value is returned if the item is
undefined in the implementation" -- but that is in a sentence that is
about a possible "variables" namespace, not the "environment" verb.  In
evaluating a variables namespace reference to a non-existent or
unsupported item, say "${env.remote-host}" when remote-host isn't
meaningful, or "${env.foobar}" when foobar isn't a real item, the
hypothetical text that addresses the variables namespace would have to
describe what value is returned in those situations.  As you say, the
behavior of the "environment" action is pretty clear already.

> I did consider using namespaces as a means of returning multiple/structured
> values from environment tests, but I eventually decided it wasn't worth it.

Different perspectives, I guess.  I like having the "environment" verb,
as it doesn't require variables, but also having the information
available via a variable namespace seems clean to me too since it builds
on language elements and concepts already out there.  But I can see some
of the drawbacks too: one being that it would make implementation of
this extension slightly harder/slower/less likely for any product that
also implements "variables" if this extension mandated adding a
variables namespace.  But only slightly.

Yours,
mm

Cc: [email-masked]
Date: Thu, 13 Mar 2008 16:30:09 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Updated Sieve environment draft posted
To: Mark E Mallett <[email-masked]>
Sender: [email-masked]

> On Mon, Mar 10, 2008 at 04:29:21PM -0700, Ned Freed wrote:
> >
> > I just posted an update to the environment draft; it should be in the
> > repository soon.

> Seems short and sweet.

> > In addition to adding a note about using "name."
> > prefixes to group related standard items,

> That note is actually the only thing that gave me pause.  When I read:

>    > Extensions designed for interoperable use SHOULD be defined in
>    > standards track or experimental RFCs.  Groups of standardized items
>    > MAY choose to use a common name prefix of the form "name.".

> it took me a few passes to realize that this was not recommending the
> literal prefix string "name." (perhaps relating to the "name"
> environment item) but recommending grouping related items by some prefix
> "xxx." where "xxx" is replaced by some mnemonic for the category by
> which they are related.  I dunno if that's even worth mentioning, but
> there it is, mentioned.

Fair enough. When the document is next updated I will add ", where "name" is a
string that identifies the group of related items." to the end of the last
sentence.

> A couple of other musings, again perhaps not worth mentioning, but
> while I'm here:

> There is a "host" item listed, which is the FQDN of the local host.
> It seems to me that one might want to know the host-only part of that
> string.  One could obtain it in a round-about way by using the "domain"
> environment item and the "host" item; but is it worth adding "host-only" ?

Frankly, I think the use of shortform names is a bad thing that should be
discouraged whenever possible. (IT uses them extensively here at Sun and they
cause no end of problems.) I'm therefore very reluctant to add such an item.

> I also think that the draft could benefit by providing for some behavior
> in the presence of the "variables" extension, e.g. by defining a
> namespace such as "env." and stating what value is returned if the item
> is undefined in the implementation.  I realize that one could obtain the
> values by using :matches, wildcarding, and variable assignments;
> having namespace support would be more straightforward.

First of all, the specification says that any test against an unknown
item must fail unconditionally. This provides a simple way to check and
see if a given item is available:

   if environment :matches "item" {...}

This test only succeeds if "item" is defined. Since this doesn't appear
to be obvious I think I'll add a note about it to the text.

I did consider using namespaces as a means of returning multiple/structured
values from environment tests, but I eventually decided it wasn't worth it.

				Ned

Date: Thu, 13 Mar 2008 23:09:16 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-body-08.txt
Sender: [email-masked]

[email-masked] wrote:

>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: Body Extension
>	Author(s)	: P. Guenther, J. Degener
>	Filename	: draft-ietf-sieve-body-08.txt
>	Pages		: 13
>	Date		: 2008-3-13
>	
>This document defines a new command for the "Sieve" email
>   filtering language that tests for the occurrence of one or more
>   strings in the body of an email message.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-08.txt
>  
>
This version addresses comments raised during the IESG review. It also 
contains some other useful clarifications. Please review asap to make 
sure that you are Ok with the changes.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-body-08.txt 
Date: Thu, 13 Mar 2008 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: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-08.txt
	Pages		: 13
	Date		: 2008-3-13
	
This document defines a new command for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

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

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

--NextPart--

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 13 Mar 2008 14:17:16 -0400
To: SIEVE <[email-masked]>
Subject: Re: Proposed charter change
Sender: [email-masked]

On Thu, Mar 13, 2008 at 11:00:30AM -0400, Cyrus Daboo wrote:
> 
> We would like to see a "show of hands" from implementers on each of the new 
> extensions being proposed so that we can judge the interest in each.
  ...

> 	(a) Body (draft-ietf-sieve-body-07.txt)
not yet, might implement some of it.  But enough of it doesn't match my
worldview (or perhaps my code's worldview) that implementing all of it
will be problematic.

> 	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
not yet, probably will

> 	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
have implemented an older draft, need to validate against this one.
Also still have "replaceheader" and probably won't remove it.

> 	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
possibly, but again with the worldview issues (as noted on-list in past)

> 	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)
intend to, at which point I'll find out about any problems I guess.

> 	(a) Date/Index (draft-freed-sieve-date-index-08.txt)
intend to.

> 	(b) iHave (draft-freed-sieve-ihave-01.txt)
will implement, looks very nice.

> 	(c) Environment (draft-freed-sieve-environment-03.txt)
will implement.

> 	(d) Notary (draft-freed-sieve-notary-01.txt)
> 	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
> 	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
I confess that I haven't looked at these close enough.

> 	(g) ManageSIEVE (draft-martin-managesieve-08.txt)
is in the queue, but low priority.

> 	(h) RegEx (draft-ietf-sieve-regex-00.txt)
had not seen this one, but have implemented against
draft-murchison-sieve-regex-08.txt .  (I have also implemented the
quoteregex function, but in a different way; I'll probably add this
style as well.)  I think regex draft could benefit with some
enhancements (such as alternate regex expression methods).

hmm, no (i) ?

> 	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
am unaware of this

> 	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
I'm not happy with the kind of include this specifies, so probably won't
implement it (and already have other include mechanism).

> 	(k) Address data (draft-melnikov-sieve-external-lists-01)
[oh, that's what happened to (i) :) ]

Will probably implement at least a subset of this - probably limited to
the opaque identifier form, as I'm not too keen on implementing
URL-following.  Unless I'm misreading the intent of that.

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 13 Mar 2008 12:59:07 -0400
To: [email-masked]
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

On Mon, Mar 10, 2008 at 04:29:21PM -0700, Ned Freed wrote:
> 
> I just posted an update to the environment draft; it should be in the
> repository soon.

Seems short and sweet.

> In addition to adding a note about using "name."
> prefixes to group related standard items,

That note is actually the only thing that gave me pause.  When I read:

   > Extensions designed for interoperable use SHOULD be defined in
   > standards track or experimental RFCs.  Groups of standardized items
   > MAY choose to use a common name prefix of the form "name.".

it took me a few passes to realize that this was not recommending the
literal prefix string "name." (perhaps relating to the "name"
environment item) but recommending grouping related items by some prefix
"xxx." where "xxx" is replaced by some mnemonic for the category by
which they are related.  I dunno if that's even worth mentioning, but
there it is, mentioned.

A couple of other musings, again perhaps not worth mentioning, but
while I'm here:

There is a "host" item listed, which is the FQDN of the local host.
It seems to me that one might want to know the host-only part of that
string.  One could obtain it in a round-about way by using the "domain"
environment item and the "host" item; but is it worth adding "host-only" ?

I also think that the draft could benefit by providing for some behavior
in the presence of the "variables" extension, e.g. by defining a
namespace such as "env." and stating what value is returned if the item
is undefined in the implementation.  I realize that one could obtain the
values by using :matches, wildcarding, and variable assignments;
having namespace support would be more straightforward.

That's all..

mm

Date: Thu, 13 Mar 2008 16:52:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: Proposed charter change
Sender: [email-masked]

Speaking as an implementor:

Cyrus Daboo wrote:

> (1) Finish work on existing in-progress Working Group documents:
>
>     (a) Body (draft-ietf-sieve-body-07.txt)

Will implement.

>     (b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

Undecided, but will consider implementing

>     (c) Edit header (draft-ietf-sieve-editheader-10.txt)

Will implement

>     (d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)

Will implement

>     (e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

Older version already implemented.

> (2) Finalize and publish the following SIEVE extensions as proposed 
> standards:
>
>     (a) Date/Index (draft-freed-sieve-date-index-08.txt)

Will implement

>     (b) iHave (draft-freed-sieve-ihave-01.txt)

This looks very interesting, but I haven't even started thinking about 
how difficult this would be to implement.

>     (c) Environment (draft-freed-sieve-environment-03.txt)

Will implement

>     (d) Notary (draft-freed-sieve-notary-01.txt)

Will implement

>     (e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)

This looks interesting, even though there is no immediate plan to implement.

>     (f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)

I haven't thought about implementing this yet.

>     (g) ManageSIEVE (draft-martin-managesieve-08.txt)

Implemented.

>     (h) RegEx (draft-ietf-sieve-regex-00.txt)

I am not sure this will be implemented, no customer requirements so far.

>     (j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)

Will implement.

>     (k) Include/multi-script (draft-daboo-sieve-include-05.txt)

I've started implementing something like multiscript and will be looking 
at include.
So this looks interesting to me.

>     (k) Address data (draft-melnikov-sieve-external-lists-01)

Will implement.

> (4) Produce one or more informational RFCs containing a set of test 
> scripts and test email messages that are to be filtered by the 
> scripts, and the expected results of that filtering. This will serve 
> as the basis of a interoperability test suite to help determine the 
> suitability of moving the base specification and selected extensions 
> to Draft status.

I will definitely participate in this effort, but I can't commit to be 
an editor.

X-Spam-Score-scoring_explanation:
X-Spam-Score-spf_status:
X-Spam-Score-Spamcatcher1: a44ffe7655438abf9e3dd266bc77bfa9
X-Spam-Score-Summary: 2,0,0,e6b35046e0522e35,a0ea87fb493ec7f7,[email-masked],,RULES_HIT:355:379:539:540:541:542:543:567:599:601:966:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2196:2199:2393:2538:2559:2562:2828:3027:3352:3865:3868:3869:3870:4250:4385:5007:6119:6261,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Cc: "SIEVE" <[email-masked]>
Subject: Re: Proposed charter change
Date: Thu, 13 Mar 2008 16:16:25 -0000
Sender: [email-masked]

> (1) Finish work on existing in-progress Working Group documents:
> 
> (a) Body (draft-ietf-sieve-body-07.txt)
yes
> (b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
no plan
> (c) Edit header (draft-ietf-sieve-editheader-10.txt)
yes
> (d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
yes
> (e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)
ish

> (2) Finalize and publish the following SIEVE extensions as proposed 
> standards:
> 
> (a) Date/Index (draft-freed-sieve-date-index-08.txt)
no plan
> (b) iHave (draft-freed-sieve-ihave-01.txt)
no plan
> (c) Environment (draft-freed-sieve-environment-03.txt)
no plan
> (d) Notary (draft-freed-sieve-notary-01.txt)
no plan
> (e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
no plan
> (f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
no plan
> (g) ManageSIEVE (draft-martin-managesieve-08.txt)
no plan
> (h) RegEx (draft-ietf-sieve-regex-00.txt)
ish
> (j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
no plan
> (k) Include/multi-script (draft-daboo-sieve-include-05.txt)
no plan
> (k) Address data (draft-melnikov-sieve-external-lists-01)
ish

Cheers

Nigel

Cc: SIEVE <[email-masked]>
Date: Thu, 13 Mar 2008 08:44:43 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Proposed charter change
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> We would like to see a "show of hands" from implementers on each of the new
> extensions being proposed so that we can judge the interest in each.

OK...

> 	(a) Body (draft-ietf-sieve-body-07.txt)

Partial implementation likely, full implementation unlikely - too expensive
computationally.

> 	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

We already implement the old draft of this. An update to the current draft is
planned.

> 	(c) Edit header (draft-ietf-sieve-editheader-10.txt)

Already implemented.

> 	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)

Partially implemented. Full implementation likely.

> 	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

Already implemented.

> (2) Finalize and publish the following SIEVE extensions as proposed
> standards:

> 	(a) Date/Index (draft-freed-sieve-date-index-08.txt)

Already implemented.

> 	(b) iHave (draft-freed-sieve-ihave-01.txt)

Already implemented.

> 	(c) Environment (draft-freed-sieve-environment-03.txt)

Already implemented.

> 	(d) Notary (draft-freed-sieve-notary-01.txt)

Will be implemented once specification is completed.

> 	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)

Already implemented.

> 	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)

Unlikely to implement.

> 	(g) ManageSIEVE (draft-martin-managesieve-08.txt)

Implementation in progress.

> 	(h) RegEx (draft-ietf-sieve-regex-00.txt)

Already implemented, but will probably need i18n work.

> 	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)

Under investigation.

> 	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)

We use the multiple script approach instead and this doesn't reallly fit
our storage model. Unlikely to implement but this may change depending
on how the draft progresses.

> 	(k) Address data (draft-melnikov-sieve-external-lists-01)

Not implemented yet but next on the to-do list.

				Ned

Date: Thu, 13 Mar 2008 11:00:30 -0400
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Proposed charter change
Sender: [email-masked]

Hi folks,
Below is a proposal for a new charter for the working group based on 
discussions at this weeks IETF meeting.

Please review this and comment.

We would like to see a "show of hands" from implementers on each of the new 
extensions being proposed so that we can judge the interest in each.

Note that we will need document authors/editors to step up for items (3) 
and (4) if we are to include these.

Once the WG has discussed this and decided on exactly what we will work on, 
Alexey and I will propose some milestones. I am hoping that we can complete 
all this work in 12 - 18 months. Note that some of the new drafts are 
already close to last call.

This is all subject to AD and IESG approval, of course.

---
The SIEVE email filtering language is specified in RFC 5228, together with 
a number of extensions.

The SIEVE working group is being re-chartered to:

(1) Finish work on existing in-progress Working Group documents:

	(a) Body (draft-ietf-sieve-body-07.txt)
	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

(2) Finalize and publish the following SIEVE extensions as proposed 
standards:

	(a) Date/Index (draft-freed-sieve-date-index-08.txt)
	(b) iHave (draft-freed-sieve-ihave-01.txt)
	(c) Environment (draft-freed-sieve-environment-03.txt)
	(d) Notary (draft-freed-sieve-notary-01.txt)
	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
	(g) ManageSIEVE (draft-martin-managesieve-08.txt)
	(h) RegEx (draft-ietf-sieve-regex-00.txt)
	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
	(k) Address data (draft-melnikov-sieve-external-lists-01)

Additional drafts may be added to this list, but only via a charter
revision. There must also be demonstrable willingness in the SIEVE
development community to actually implement a given extension before
it can be added to this charter.

(3) Work on a "Benefits of SIEVE" guide for client and server vendors that:
	(a) Describes the SIEVE protocol and its suite of extensions.
	(b) Explains the benefits of server-side filtering in practical terms.
	(c) Shows how client-side filtering can be migrated to SIEVE.

(4) Produce one or more informational RFCs containing a set of test scripts 
and test email messages that are to be filtered by the scripts, and the 
expected results of that filtering. This will serve as the basis of a 
interoperability test suite to help determine the suitability of moving the 
base specification and selected extensions to Draft status.

-- 
Cyrus Daboo

Date: Wed, 12 Mar 2008 23:12:33 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: Updated Sieve environment draft posted
Sender: [email-masked]

In my capacity of a technical contributor:

Ned Freed wrote:

> I just posted an update to the environment draft; it should be in the
> repository soon. In addition to adding a note about using "name."
> prefixes to group related standard items, I also rearranged the text
> about IANA registrations a bit to make the group (hopefully) a little 
> more
> logical.

I've reviewed the recent changes (and I've reviewed earlier versions of 
the document) and I believe the document is ready for publication.

In particular, I think the current list of attributes specified in the 
document is sufficient and is reasonably described.

Date: Tue, 11 Mar 2008 15:41:03 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Sieve date/index extension
To: [email-masked]
Sender: [email-masked]

This draft was (briefly) discussed at yesterday's meeting, and Phillip
raised the only issue: Why the handling of a list of headers is
done the way it is.

More specifically, the text currently says:

   Both header and address allow the specification of more than one
   header field name. If more than one header field name is specified
   all the named header fields are counted in the order specified by the
   header-list.

Phillip asked why the semantics weren't instead to look for the nth field in
the order the fields appear in the header.

The main reason for this is that while i see some value in being able to
determin the relative order of fields in a header, the ability to find do a a
limited sort of ordering check while looking for a single string and not being
able to determine which field matched didn't strike me as in any way useful.
And these semantics interfere with implementations like ours that use what
amounts to a hash table to quickly find headers with a given name - as everyone
knows, hashes are great at finding things quickly but sucky at retaining
ordering information.

I frankly have no idea whether or not this optimization in our implementation
is important. But when you operate in the hundreds of messages a second realm
at million mailbox sites and a significant number of mailboxes having
very substantial sieves (hundreds of tests in a single sieve are not uncommon),
it's only sensible to take any speedup you can get.

So, absent a compelling use-case for changing the semantics, I'd really prefer
to leave this as-is.

				Ned

Date: Mon, 10 Mar 2008 16:29:21 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Updated Sieve environment draft posted
To: [email-masked]
Sender: [email-masked]

I just posted an update to the environment draft; it should be in the
repository soon. In addition to adding a note about using "name."
prefixes to group related standard items, I also rearranged the text
about IANA registrations a bit to make the group (hopefully) a little more
logical.

Please review and if this seems OK, it's time for last call.

				Ned

Date: Fri, 7 Mar 2008 23:17:54 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Final sanity check on draft-ietf-sieve-mime-loop-04.txt
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

I lost track of that draft. Sorry. Three comments and a bonus.

1. for_every_part jars. We don't have file_into, we don't have any_child.

I don't mind underscores per se, but I do mind heterodoxy. Using 
gluedtogethernames sometimes, using underscore_names sometimes and 
camelCaseNames sometimes makes the language unnecessarily messy. (Yes, 
I know we don't have camelCase anywhere. At least not that I've 
noticed.)

2. break has been difficult in C for decades when nested loops are used, 
do we need to repeat it? Wouldn't it be better to tie break and its 
loop explicitly, e.g. with an identifier? The identifier would be 
optional on the loop and mandatory on the break.

3. Perhaps I'm tired, but it wasn't clear to me whether if two loops are 
nested, both operate on _every_ bodypart, O(n^2) and all, or whether 
the inner only operates on children of the bodypart currently accessed 
by the outer loop. The former seems correct, but I'm not thrilled to 
have O(n^2) mandatory behaviour, and O(n^m) possible if more than two 
levels is supported.

Bonus. Philosophy. I like the way :anychild without for_every_part 
works. That makes it possible to do parallel processing instead of 
sequential. If I want to process, say, ten or a hundred thousand 
messages with a single sieve script, that becomes important. I can 
transform the test to a database lookup and the query planner will 
generally do well. This makes some clever reprocessing of an entire 
mailbox possible. "Your new sieve script would have filed <these> 
messages into <that mailbox>. Do you want to move them now?". break and 
perhaps for_every_part torpedoes such transformations. I wonder whether 
that's necessary. I wonder whether it's really the same problem as the 
O(n^m) behaviour of nested for_every_part.

Arnt

Date: Fri, 07 Mar 2008 19:09:16 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Final sanity check on draft-ietf-sieve-mime-loop-04.txt
Sender: [email-masked]

Cyrus and Tony have updated Sieve MIME loops document. Cyrus should send 
out a message (I apologize if he did already and I missed it) about 
which changes were addressed and which were not (and why).

I would like to ask all people who commented on the document earlier to 
review if their comments were addressed. If there are no comments on the 
document before March 21st, I would recommend its publication.

Regards,
Alexey,

Cc: [email-masked]
Date: Tue, 04 Mar 2008 18:18:26 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: action reject and smtp RCPT TO:
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Sender: [email-masked]

> Hello,

> >>     About the spamtest issue: it shall be evaluated after data.
> >
> > Why? What if the necessary information is already available and nothing
> > in the message body is capable of overriding it? Why would a ban on early
>  > evaluation of scripts that use spamtest make any more sense than a
>  > ban on early evaluation of scripts that use reject?

> Doing heuristic spam analysis can combine a lot of rules, some giving
> positive and other negative weight on the result. The fact that the
> envelope increases the spaminess, does not mean that the body of the
> message will not decrease it. At the end the total spaminess can be
> acceptable for the recipient, even if the envelope went above the limit.
> So to be accurate, the spamtest shall be done after DATA .

Sigh. All of this is completely obvious and completely irrelevant. For the
third time, there can be cases where the analysis done on the envelope is
sufficient and no, repeat NO, analysis of the message content is capable of
overriding. In such cases the message might as well be refused at the envelope
stage and making some arbitrary rule saying this mustn't be done is every
bit as inappropriate as the rule against doing envelope time rejects
you're arguing against (despite the fact that no such rule exists).

> In the cases when the spam software works only on the envelopes, or
> cannot decrease the spaminess due additional rules, then spamtest can be
> evaluated before DATA as well.

Which is exactly what I've been saying from the start.

> >> If I
> >> remember correctly, there was an idea to extend the envelope test to
> >> check against the sending host (apart from sender and recipient) and
> >> check using external lists if the sending host is blacklisted.

> > However, no such extension has been defined or even, aside from a passing
> > mention, discussed.

> Ned said on 8th October 2007 to look on
> draft-freed-sieve-environment-01, when it comes out, as the idea of
> remote-host and remote-ip will be presented there. Right now I see it is
> really at http://tools.ietf.org/html/draft-freed-sieve-environment-01.

Correct, but the environment extension gives you access to the necessary
information but doesn't do the whitelist/blacklist part, which necessary for
this to gain any sort of equivalency with spamtest.

I actually favor the more general approach described in the (now expired)
draft-melnikov-sieve-external-lists-01.txt, modulo a few changes I suggested
on the list some time back. This provides a generic external list access
mechanism which can be usedd for all sorts of different purposes.

However, now that you have brought up environment, its another extension that
potentially interacts with early evaluation in interesting ways. I hadn't
really thought about it before and the initial set of environment items doesn't
include anything that depends on message content (nor do any of the exxtensions
we''re planning on implementing), but it is not beyond the realm of possibility
that some environment item might be defined that could not be evaluated at RCPT
TO time.

> >>  > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
> >>  > fetch the sieve script as part of verifying that the rcpt to address
> >>  > exists, and evaluate until some test fails for lack of data. I think
> >>  > the draft as it stands is fine.
> >
> >> I think this is wrong, as it does not allow combining keep and reject.
> >
> > I fail to see anything in this implementation description that would
> > create a
> > problem for combining keep and reject. And even if it did, since the draft
> > strongly recommends implementations to forbid this combination (our
> > implementation definitely does this), I fail to see the point of any of
> > this.

> If reject is done at RCPT time and there is no DATA afterwards (due the
> lack of accepting recipients), keep cannot be made. (Keep what?)

> The need of combining keep and reject was addresses in the discussion
> from 2006-07-11 as a sort of logging the process.

Yes, I recall the discussion. I still think its a totally bogus thing to do and
the draft still recommends that they be incompatible.

> >> The reject action shall be executed after RCPT TO:, if the script
> >> terminated successfully (= reached <EOF> or stop; without making
> >> header/body tests, or invoking the keep action) being executed there.
> >
> > This goes much too far - it actually recommends if not requires
> > implementations
> > implement early evaluation - and I am adamantly opposed to it.

> This is my view on Arnt's FWIW: Arnt said that reject is executed, if no
> test or actions failed before reaching "reject". I answered, that this
> approach does not allow to combine keep and reject/fileinto and
> reject/notify and reject/whatever and reject. Instead, reject shall be
> applied during early evaluation only if the script terminates
> successfully. (The other option is to make reject if no actions/tests
> failed yet).

OK, got it. Arnt has already clarified that this is in fact a nonissue for him.
It is for us as well - we don't stop evaluating at reject or anything else for
that matter besides stop or an error of some sort.

				Ned

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Wed, 05 Mar 2008 00:17:13 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
CC: [email-masked]
Subject: Re: action reject and smtp RCPT TO:
Sender: [email-masked]

Hello,

>>     About the spamtest issue: it shall be evaluated after data.
> 
> Why? What if the necessary information is already available and nothing 
> in the message body is capable of overriding it? Why would a ban on early 
 > evaluation of scripts that use spamtest make any more sense than a
 > ban on early evaluation of scripts that use reject?

Doing heuristic spam analysis can combine a lot of rules, some giving 
positive and other negative weight on the result. The fact that the 
envelope increases the spaminess, does not mean that the body of the 
message will not decrease it. At the end the total spaminess can be 
acceptable for the recipient, even if the envelope went above the limit. 
So to be accurate, the spamtest shall be done after DATA .

In the cases when the spam software works only on the envelopes, or 
cannot decrease the spaminess due additional rules, then spamtest can be 
evaluated before DATA as well.

>> If I
>> remember correctly, there was an idea to extend the envelope test to
>> check against the sending host (apart from sender and recipient) and
>> check using external lists if the sending host is blacklisted.
> 
> However, no such extension has been defined or even, aside from a passing
> mention, discussed.

Ned said on 8th October 2007 to look on 
draft-freed-sieve-environment-01, when it comes out, as the idea of 
remote-host and remote-ip will be presented there. Right now I see it is 
really at http://tools.ietf.org/html/draft-freed-sieve-environment-01.

>>  > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
>>  > fetch the sieve script as part of verifying that the rcpt to address
>>  > exists, and evaluate until some test fails for lack of data. I think
>>  > the draft as it stands is fine.
> 
>> I think this is wrong, as it does not allow combining keep and reject.
> 
> I fail to see anything in this implementation description that would 
> create a
> problem for combining keep and reject. And even if it did, since the draft
> strongly recommends implementations to forbid this combination (our
> implementation definitely does this), I fail to see the point of any of 
> this.

If reject is done at RCPT time and there is no DATA afterwards (due the 
lack of accepting recipients), keep cannot be made. (Keep what?)

The need of combining keep and reject was addresses in the discussion 
from 2006-07-11 as a sort of logging the process.

>> The reject action shall be executed after RCPT TO:, if the script
>> terminated successfully (= reached <EOF> or stop; without making
>> header/body tests, or invoking the keep action) being executed there.
> 
> This goes much too far - it actually recommends if not requires 
> implementations
> implement early evaluation - and I am adamantly opposed to it.

This is my view on Arnt's FWIW: Arnt said that reject is executed, if no 
test or actions failed before reaching "reject". I answered, that this 
approach does not allow to combine keep and reject/fileinto and 
reject/notify and reject/whatever and reject. Instead, reject shall be 
applied during early evaluation only if the script terminates 
successfully. (The other option is to make reject if no actions/tests 
failed yet).

	Greetings,
		Dilian

Cc: Ned Freed <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Date: Tue, 04 Mar 2008 13:53:43 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: action reject and smtp RCPT TO:
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Sender: [email-masked]

> 	Hello,

> 	I think draft-ietf-sieve-refuse-reject-06 implicitly forbids sending
> 550 after RCPT. In Section 2.1 (Action ereject) the SMTP 550 way is
> shifted to Section 2.1.1 (Rejecting a message at the SMTP/LMTP protocol
> level) and Section 2.1.1 shifts the problem to Section 2.1.2 (Rejecting
> a message by sending a DSN). Or may be I am wrong?

I'm sorry, but you are quite simply wrong about this. First, just because
something isn't discussed doesn't mean it is disalllowed. And section 2.1.2 is
quite clear in stating that it applies to rejections occuring after message
data has been received. That's the only sensible interpretation the phrase "may
receive a message via SMTP" can possibly have. And the text goes on to talk
about the fact that this restriction doesn't apply to LMTP because LMTP has
per-recipient replies after DATA, which only makes sense if we're talking about
responses after message data has been transfererd.

Now, while I think the current text is already quite clear, in order
to forestall further argument I suggest changing the first paragraph
of section 2.1.2 to read:

   An implementation may need to respond to the transfer of message
   data when more than one RCPT TO has been accepted by the server,
   and at least one recipient but not all of are refusing delivery
   (whether the refusal is caused by a Sieve "ereject" action or for
   some other reason).  In this case, the server MUST accept the
   message and generate DSNs for all recipients that refused delivery.
   Note that this exception does not apply to LMTP, as LMTP is able
   to reject messages on a per-recipient basis after message data
   has been transferred.

> 	About the spamtest issue: it shall be evaluated after data.

Why? What if the necessary information is already available and nothing in the
message body is capable of overriding it? Why would a ban on early evaluation
of scripts that use spamtest make any more sense than a ban on early evalaution
of scripts that use reject?

> If I
> remember correctly, there was an idea to extend the envelope test to
> check against the sending host (apart from sender and recipient) and
> check using external lists if the sending host is blacklisted.

However, no such extension has been defined or even, aside from a passing
mention, discussed.

> Then the
> mail can be rejected according to the user's preferences and not due the
> site policy. Can we leave for now spamtest out the discussion?

Not if what we're talking about is explicit adding text discussing early
evaluation of sieve scripts. In that case I insist that the discussion
encompass the effects of early evaluation on every test and action we have
defined so far. When it comes to implementation methods we either have to
discuss a given approach thoroughly or not at all.

> 	The idea of the early evaluation in multi-recipient messages is to
> reduce the amount of generated NDRs, when some of the recipients are
> mailboxes (accept spam) and others are mailing lists (who do not want to
> discard messages from non list members, ignoring the spaminess). The
> problem with NDRs is that they might end in a spamtrap/honeypot and
> blacklist your server. With early evaluation all this is avoided...

We're all well aware of these issues.

> And
> once again: does draft-ietf-sieve-refuse-reject-06 forbid this behaviour?

No.

>  > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
>  > fetch the sieve script as part of verifying that the rcpt to address
>  > exists, and evaluate until some test fails for lack of data. I think
>  > the draft as it stands is fine.

> I think this is wrong, as it does not allow combining keep and reject.

I fail to see anything in this implementation description that would create a
problem for combining keep and reject. And even if it did, since the draft
strongly recommends implementations to forbid this combination (our
implementation definitely does this), I fail to see the point of any of this.

> The reject action shall be executed after RCPT TO:, if the script
> terminated successfully (= reached <EOF> or stop; without making
> header/body tests, or invoking the keep action) being executed there.

This goes much too far - it actually recommends if not requires implementations
implement early evaluation - and I am adamantly opposed to it.

				Ned

Date: Tue, 4 Mar 2008 09:33:25 -0700
From: Philip Guenther <[email-masked]>
To: =?KOI8-R?B?5MnM0c4g8MHMwdXaz9c=?= <[email-masked]>
cc: Philip Guenther <[email-masked]>, IETF Sieve WG <[email-masked]>
Subject: Re: action reject and smtp RCPT TO:
Sender: [email-masked]

On Sun, 2 Mar 2008, Дилян Палаузов wrote:
>>> Does this mean, that a recipient cannot be rejected after RCPT TO: and 
>>> before DATA: in a multi recipient message?
>> 
>> Yes, that's exactly what it means.

My apologies for my unclear statement.  The above was in relation to this 
text from the draft:
    Note that if a message is arriving over SMTP and has multiple
    recipients, some of whom have accepted the message, Section 2.1.2
    defines how to reject such a message.

In light of the quote, I interpreted the "after RCPT" in your question as 
meaning "after being accepted at RCPT time".  That is, I thought you were 
asking if it was possible to perform individual rejection of recipients 
that were accepted at RCPT time.

As for your actual question: IMO, the possibility of rejecting individual 
recipients by rejecting their RCPT commands is permitted by the draft.

Philip Guenther

Date: Mon, 3 Mar 2008 17:48:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: action reject and smtp RCPT TO:
Cc: Ned Freed <[email-masked]>, =?KOI8-R?b?5MnM0c4g8MHMwdXaz9c=?= <[email-masked]>
Sender: [email-masked]

����� �������� writes:
> I think this is wrong, as it does not allow combining keep and reject.

In my code, keep (even implicit keep) is a command which cannot complete 
at RCPT TO time for lack of data. So it works.

I agree with Ned that going into this level of detail in the document is 
not helpful. This is a very minor point, and spending text on it will 
help very few of the document's readers. For most readers it's just a 
weird digression, and digressions are not good.

Arnt

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Mon, 03 Mar 2008 16:54:26 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: action reject and smtp RCPT TO:
Sender: [email-masked]

	Hello,

	I think draft-ietf-sieve-refuse-reject-06 implicitly forbids sending 
550 after RCPT. In Section 2.1 (Action ereject) the SMTP 550 way is 
shifted to Section 2.1.1 (Rejecting a message at the SMTP/LMTP protocol 
level) and Section 2.1.1 shifts the problem to Section 2.1.2 (Rejecting 
a message by sending a DSN). Or may be I am wrong?

	About the spamtest issue: it shall be evaluated after data. If I 
remember correctly, there was an idea to extend the envelope test to 
check against the sending host (apart from sender and recipient) and 
check using external lists if the sending host is blacklisted. Then the 
mail can be rejected according to the user's preferences and not due the 
site policy. Can we leave for now spamtest out the discussion?

	The idea of the early evaluation in multi-recipient messages is to 
reduce the amount of generated NDRs, when some of the recipients are 
mailboxes (accept spam) and others are mailing lists (who do not want to 
discard messages from non list members, ignoring the spaminess). The 
problem with NDRs is that they might end in a spamtrap/honeypot and 
blacklist your server. With early evaluation all this is avoided... And 
once again: does draft-ietf-sieve-refuse-reject-06 forbid this behaviour?

 > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
 > fetch the sieve script as part of verifying that the rcpt to address
 > exists, and evaluate until some test fails for lack of data. I think
 > the draft as it stands is fine.

I think this is wrong, as it does not allow combining keep and reject. 
The reject action shall be executed after RCPT TO:, if the script 
terminated successfully (= reached <EOF> or stop; without making 
header/body tests, or invoking the keep action) being executed there.

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

Cc: [email-masked], Ned Freed <[email-masked]>, =?KOI8-R?b?5MnM0c4g8MHMwdXaz9c=?= <[email-masked]>
Date: Mon, 03 Mar 2008 06:54:19 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: action reject and smtp RCPT TO:
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> FWIW: My sieve interpreter does exactly what we're (not) allowing:

AFAIK nobodhy is talking about not allowing this. The question is whether or
not we should specify all of the nuances involved in supporting this mode of
operation, and if we're going to whether or not this is the right place to do
it. I remain to be convinced of the need to specify this and I'm opposed to
doing it in this document.

> I
> fetch the sieve script as part of verifying that the rcpt to address
> exists, and evaluate until some test fails for lack of data. I think
> the draft as it stands is fine.

Our implementation doesn't work this way but nevertheless allows some types of
Sieves to be evaluated at RCPT TO or even MAIL FROM time.

				Ned

Date: Mon, 3 Mar 2008 09:13:44 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: action reject and smtp RCPT TO:
Cc: Ned Freed <[email-masked]>, =?KOI8-R?b?5MnM0c4g8MHMwdXaz9c=?= <[email-masked]>
Sender: [email-masked]

FWIW: My sieve interpreter does exactly what we're (not) allowing: I 
fetch the sieve script as part of verifying that the rcpt to address 
exists, and evaluate until some test fails for lack of data. I think 
the draft as it stands is fine.

Arnt

Cc: IETF Sieve WG <[email-masked]>
Date: Sun, 02 Mar 2008 15:52:17 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: action reject and smtp RCPT TO:
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Sender: [email-masked]

> 	Hello,

> 	I read the discussion from Juli 2007 about the reject concerns. There
> is still something that is not addressed in
> draft-ietf-sieve-refuse-reject-06 -- early evaluation of scripts.

Of course it s possible to, say, evaluate a script that only uses envelope
"from" tests at the MAIL FROM stage, or to evaluate a script that only uses
envelope tests at the RCPT TO stage, but I really have to question the utility
of an extended discussions of the issues surrounding using sieve this way. The
overwhelming majority of scripts we end up with in practice make extensive use
of header and other tests that depend on message content and henace cannot be
evaluated until after the DATA phase.

And while the reject action is almost certainly the case where early evaluation
offers the most advantage, it isn't the only test or action where early
evaluation brings up issues, some of them fairly subtle. Consider spamtest - it
is possible in many cases to compute a spam score based solely on envelope
information. But better results are usually produced if content is considered.
So how should this be handled? Should

    require ["spamtest", "reject, "relational", "comparator-i;ascii-numeric"];
    if spamtest :value "ge" :comparator "i;ascii-numeric" "3"
    {
	reject "Keep your spam";
    }

be evaluated at RCPT TO when possible, or should it have to wait until after
DATA because a better score is available then, or perhaps it should be
evaluated twice? And all this totally ignores the implementation issues with
actually using exist spam filtering software with only an envelope.

Now, has the issue of early evaluation been one described in the sieve base
specification and given due considerstion in all the other sieve documents (the
currentdate test defined in date-index is an obvious example of a place where
such considerations should be described), not only would I have no problem with
adding such a discussion to this document, I would have insisted on it. But
that's not now things are. We haven't dealt with this concept at all and IMO
trying t do so as s side note in this one extension is not a good idea.

If early evaluation is indeed of sufficient interest to warrant specification
then the way to handle it at ths point is with an additional informational
specification. But as I stated previously, I am dubious that's there's
sufficient operational utility here to bother.

				Ned

Date: Sun, 2 Mar 2008 14:27:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: action reject and smtp RCPT TO:
Sender: [email-masked]

Philip Guenther writes:
> Because doing so in SMTP is impossible without unstandardized 
> extensions. (How is the server supposed to indicate that a message is 
> being rejected for rcpt A but not rcpt B?)

MAIL FROM:<[email-masked]>
250 OK
RCPT TO:<[email-masked]>
     if envelope :all :is "from" "[email-masked]" {
         reject;
     }
550 I reject mail from [email-masked]

Arnt

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Sun, 02 Mar 2008 00:16:53 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IETF Sieve WG <[email-masked]>
Subject: Re: action reject and smtp RCPT TO:
Sender: [email-masked]

Hello,

>> Does this mean, that a recipient cannot be rejected after RCPT TO: and 
>> before DATA: in a multi recipient message?
> 
> Yes, that's exactly what it means.
> 
>> In the discussion I have not seen why this shall not be possible.
> 
> Because doing so in SMTP is impossible without unstandardized 
> extensions. (How is the server supposed to indicate that a message is 
> being rejected for rcpt A but not rcpt B?)

MAIL FROM: <[email-masked]>
250 OK
RCPT TO: <[email-masked]>
250 OK
RCPT TO: <[email-masked]>
550-You are not permitted to post to [email-masked] from
550 your [email-masked] address.
RCPT TO: <[email-masked]>
250 OK
DATA ...

Why shouldn't be a sieve script allowed to set the 550-response here?

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

Date: Sat, 1 Mar 2008 15:58:45 -0700
From: Philip Guenther <[email-masked]>
To: =?KOI8-R?B?5MnM0c4g8MHMwdXaz9c=?= <[email-masked]>
cc: IETF Sieve WG <[email-masked]>
Subject: Re: action reject and smtp RCPT TO:
Sender: [email-masked]

On Sat, 1 Mar 2008, Дилян Палаузов wrote:
...
> Does this mean, that a recipient cannot be rejected after RCPT TO: and before 
> DATA: in a multi recipient message?

Yes, that's exactly what it means.

> In the discussion I have not seen why this shall not be possible.

Because doing so in SMTP is impossible without unstandardized extensions. 
(How is the server supposed to indicate that a message is being rejected 
for rcpt A but not rcpt B?)

Philip Guenther

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Sat, 01 Mar 2008 19:14:21 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: Re: action reject and smtp RCPT TO:
Sender: [email-masked]

	Hello,

	I read the discussion from Juli 2007 about the reject concerns. There 
is still something that is not addressed in 
draft-ietf-sieve-refuse-reject-06 -- early evaluation of scripts. More 
concrete I mean that a script can be executed after the RCPT TO and 
before the DATA stage, and then has a stop;.

draft-ietf-sieve-refuse-reject-06
2.1.1. Rejecting a message at the SMTP/LMTP protocol level

    Sieve implementations that are able to reject messages at the SMTP/
    LMTP level MUST do so and SHOULD use the 550 response code.  Note
    that if a message is arriving over SMTP and has multiple recipients,
    some of whom have accepted the message, Section 2.1.2 defines how to
    reject such a message.

Does this mean, that a recipient cannot be rejected after RCPT TO: and 
before DATA: in a multi recipient message? In the discussion I have not 
seen why this shall not be possible.

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

Kjetil Torgrim Homme wrote:
> On Wed, 2008-02-13 at 21:09 +0100, Дилян Палаузов wrote:
>> Hello,
>>
>> If sieve scripts are written in the form:
>>
>> if (envelope tests....) { reject; stop;}
>> some other tests and actions;
>>
>> the scripts can be applied once after the RCPT TO: command and once 
>> after the DATA command. If the first script calling is successful (stop; 
>> is reached without trying tests, that require headers or body), and the 
>> reject action is performed, then the sieve script can reject the message 
>> at the RCPT TO: level.
> 
> see the thread "Re: List of open issues with Sieve reject draft
> (draft-ietf-sieve-refuse-reject-02.txt)" from 2006-07-11.
> 
>> The application of such scripts is, e.g. for mailing lists, with scripts 
>> like
>>
>> 	if (recipient is a mailing list and sender is not allowed to post 
>> there) {reject; stop;}
>>
>> which will save the consequent NDRs, send from the mailing list 
>> software. This approach is not considered in 
>> draft-ietf-sieve-refuse-reject-06, 2.2 Action reject...However 
>> implementations MAY refuse delivery over protocol ..., if and only if 
>> all of the following conditions are true:  2. ...
> 
> I agree it would be beneficial to allow early evaluation of Sieve
> scripts, but I believe we need a separate draft to clarify how it should
> work.  it would be preferable if the refuse-reject document had some
> text to indicate the possibility.
>