Subject: new mailing list: [email-masked]

From: Martin Duerst <[email-masked]>
Date: Tue, 17 Aug 2004 08:31:25 +0900

Dear Sieve experts,

After discussion with Chris Newman, author of the Internet Draft
http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-02.txt,
we have created a new mailing list, [email-masked],
for discussion (and hopefully completion) of this work on identifiers
for collations. This mailing list replaces an earlier one hosted at
a different place.

If you want to contribute or are interested in this work, please
subscribe by sending mail to [email-masked]
(capitalization irrelevant) with "subscribe" (without the quotes)
in the subject. The archives of this mailing list can be found at
http://lists.w3.org/Archives/Public/public-ietf-collation/,
and are publicly accessible.

I expect discussion to begin no earlier than Monday, August 23, to
allow everybody interested to subscribe.

Regards,    Martin.

Date: Tue, 17 Aug 2004 08:31:25 +0900
To: [email-masked]
From: Martin Duerst <[email-masked]>
Subject: new mailing list: [email-masked]
Sender: [email-masked]

Dear Sieve experts,

After discussion with Chris Newman, author of the Internet Draft
http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-02.txt,
we have created a new mailing list, [email-masked],
for discussion (and hopefully completion) of this work on identifiers
for collations. This mailing list replaces an earlier one hosted at
a different place.

If you want to contribute or are interested in this work, please
subscribe by sending mail to [email-masked]
(capitalization irrelevant) with "subscribe" (without the quotes)
in the subject. The archives of this mailing list can be found at
http://lists.w3.org/Archives/Public/public-ietf-collation/,
and are publicly accessible.

I expect discussion to begin no earlier than Monday, August 23, to
allow everybody interested to subscribe.

Regards,    Martin.

Date: Sat, 14 Aug 2004 18:06:31 -0700
From: Tim Showalter <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Re: creative use of vacation - is 'reply' action needed?
Sender: [email-masked]

Cyrus Daboo wrote:

> Irrespective of the value of these specific tests I do wonder whether we 
> need a proper 'reply' action to handle automated responses [...]

The early Sieve drafts, in fact, had a reply command, but it was killed 
over an objection from John Myers, who was worried about giving users a 
way of sending replies without some limitations.

This type of automatic reply leads to sorcerer's apprentice problems. 
Of course, it's also really useful.

But that's why it's not there.

Tim

Date: Sat, 14 Aug 2004 19:19:00 -0400
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: creative use of vacation - is 'reply' action needed?
Sender: [email-masked]

Hi folks,
I had a user post a problem about getting a sieve script to work properly. 
They were using vacation is a somewhat 'creative' way to try an implement 
an auto-reply feature. In this case they had three tests, each of which had 
a 'vacation :days 0' action associated with it:

1) Check for use of old email address and send reply telling correspondent 
to use the new one instead.

2) Check for text/html or multipart/alternative and send a reply telling 
correspondent to send plain text in future.

3) Check message size and if over some limit send a reply telling users not 
to send large messages in future.

Irrespective of the value of these specific tests I do wonder whether we 
need a proper 'reply' action to handle automated responses as opposed to 
rejects or vacation (which has restrictions on how it can be used). In this 
case the user was expecting multiple vacations to be sent if a message 
matched more than one of the tests, but of course that is not allowed. It 
would be possible to work around that using variables, but I really don't 
like vacation being used in this way.

Comments?

-- 
Cyrus Daboo

Date: Thu, 12 Aug 2004 15:59:25 -0400
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: lunch bof notes
Sender: [email-masked]

Here are some brief notes on the lunch BOF held last week at the IETF 
meeting:

1) WG Status:

    - the ADs were amenable to setting up a WG for sieve, subject to an 
acceptable charter
    - Ned is putting together a charter (he will post details)
    - Ned will also write a 'justification' document to go along with the 
charter to the IESG
      to explain why we feel the need for a WG now, after having worked 
pretty well without one
      up to now

2) Key charter points:

    - Take base spec to draft. Changes to the base spec will be out of 
scope except for fixing
      errata, or removal of items not implemented.
    - Revise existing extensions if needed (relational, subaddress, 
spamtest).
    - WG will formally work on the following drafts: vacation, regex, 
editheader, body,
      variables, imapflags, notify, mimeheaders/loop
    - other drafts will remain individual submissions: include, 
managesieve, refuse

3) Other comments:

    - Jutta: need percent test in spamtest. General agreement to update 
spamtest with
      :percent argument
    - variables: are variables strings or lists? Issue to list.
    - vacation: interaction with variables is a problem. Want option to set 
>From address.
      'Re' vs 'auto' - discuss further on list but lunch consensus was for 
'Re'.
    - body: use '=' as hex separator so q-p decoder/encoder can be reused? 
No variables.
      Doc missing IANA section.
    - regex: have to wait for Chris N's comparator draft. i18n remains the 
only issue.
      Ask Martin Duerst (w3c) for his opinion. What about capture of regex 
into variables?
    - imapflags: issue with interaction with variables. More list 
discussion required.
    - editheader: insert at top or bottom by default? Lunch consensus was 
default to top but
      allow option to go at bottom as currently specified. Interaction with 
itself: clarify.
      No IANA section.
     - include: not much interest in implementing. Should be 'experimental'?
    - refuse: only useful in limited cases (e.g. single recipient). Why not 
modify reject?
    - mime/loop: agreement that this is very useful. Include attachment 
removal capability.

-- 
Cyrus Daboo

Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Thu, 12 Aug 2004 21:51:16 +0200
Sender: [email-masked]

On Thu, 2004-08-12 at 15:26 -0400, Cyrus Daboo wrote:
> New syntax would be:
> 
> 	reject [":auto" / ":dsn" / ":mdn"] <reason: string>
> 	
> 	optional arguments:
> 	
> 	":auto" - the sieve implementation decides which of SMTP error, DSN
> 	or MDN is appropriate to use when the action is executed. This is
> 	also the default behaviour if none of the optional tags is
> 	specified. The 'reason' string is used in a DSN or MDN if one of
> 	those is generated. The 'reason' string is not used in any SMTP error.
> 	
> 	":dsn" - a DSN is always generated when the reject action is
> 	executed. The 'reason' string is used in the DSN.

make it explicit and add "If a DSN can't be generated, the message is
discarded silently."
	
> 	":mdn" - a MDN is always generated when the reject action is
> 	executed. The 'reason' string is used in the MDN.

since this is the old behaviour, I think this should be the default.
-- 
Kjetil T.

Date: Thu, 12 Aug 2004 15:26:19 -0400
From: Cyrus Daboo <[email-masked]>
To: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
Sender: [email-masked]

Hi Matthew,

--On Wednesday, August 11, 2004 4:30 PM -0700 Matthew Elvey 
<[email-masked]> wrote:

> Allowing the user to specify the response code is a bad idea -
> featuritits.  It provides very little to no benefit, violates KISS, and
> introduces complications.
> What if the user specifies 200 as the response code?  :)
> I want refuse to have all the features it must have, and no more.

Actually we are talking about enhanced error codes here, so the user cannot 
touch the response code (i.e. it will always be a 5xx response).

If you want to really apply KISS then I would argue that the sieve script 
shouldn't even have a way to set the SMTP error text, let alone the 
response or enhanced codes. Why not leave the SMTP error message to the 
SMTP server implementation? That eliminates the need to have two text 
parameters for ascii and non-ascii - you just need the one for 'non-ascii' 
which only gets used for DSN/MDN.

I also strongly dislike the idea of changing the behaviour of the command 
based on whether non-ascii text is present in the reason string or not.

Here is my suggestion in a little bit more detail:

Relax the behaviour of the reject command to allow it to also be used for 
SMTP errors and to allow generation of DSNs in addition to MDNs as needed. 
New syntax would be:

	reject [":auto" / ":dsn" / ":mdn"] <reason: string>
	
	optional arguments:
	
	":auto" - the sieve implementation decides which of SMTP error, DSN
	or MDN is appropriate to use when the action is executed. This is
	also the default behaviour if none of the optional tags is
	specified. The 'reason' string is used in a DSN or MDN if one of
	those is generated. The 'reason' string is not used in any SMTP error.
	
	":dsn" - a DSN is always generated when the reject action is
	executed. The 'reason' string is used in the DSN.
	
	":mdn" - a MDN is always generated when the reject action is
	executed. The 'reason' string is used in the MDN.

This deals with the KISS issue and having the command do different things 
based on ascii/non-ascii in reason. A user has the option to explicitly 
require a DSN or MDN if they know they always want the reason string to get 
back to the sender, bypassing the possibility of a meaningless SMTP error.

-- 
Cyrus Daboo

Subject: Re: regarding short-circuiting
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Thu, 12 Aug 2004 21:16:50 +0200
Sender: [email-masked]

On Thu, 2004-08-12 at 11:44 -0700, wrote:
> > while perusing the list archive, I found another point which probably
> > needs addressing in the draft.  consider:
> 
> >         if address :matches ["To", "Cc"] ["kjetilho@*", "k.t.homme@*"]
> 
> > if a message contains both "To: [email-masked]" and "Cc:
> > [email-masked]" -- what's the value of ${1} ?
> 
> > the current draft says:
> 
> >         The interpreter MUST short-circuit tests, ie. not perform more
> >         tests than necessary to find the result.
> 
> > so the behaviour is undefined.
> 
> I suggest that this case is best left undefined.

okay, I added two sentences to the paragraph:

        The interpreter MUST short-circuit tests, ie. not perform more
        tests than necessary to find the result.  Evaluation order MUST
        be left to right.  If a test has two or more list arguments, the
        implementation is free to choose which to iterate over first.

-- 
Kjetil T.

Date: Thu, 12 Aug 2004 15:02:00 -0400
From: Cyrus Daboo <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
cc: Tony Hansen <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: draft-homme-sieve-variables-03.txt
Sender: [email-masked]

Hi Kjetil,

--On Thursday, August 12, 2004 8:46 PM +0200 Kjetil Torgrim Homme 
<[email-masked]> wrote:

>> I think it has to be a MUST - we can't allow implementations to ignore
>> variables when they are actually used!
>
> I'm kind of glad to see it's not only I who misremembers [KEYWORDS] :-)
>
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.

I guess I read SHALL as SHOULD. As a quick (pointless) exercise I just 
grep'd my entire rfc document cache looking for MUST and SHALL (without 
double-quotes around them) and got:

MUST  - 28010
SHALL -  1777

Somehow MUST seems much more of an imperative to me than SHALL...

-- 
Cyrus Daboo

Date: Thu, 12 Aug 2004 11:44:34 -0700 (PDT)
From: [email-masked]
Subject: Re: regarding short-circuiting
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> while perusing the list archive, I found another point which probably
> needs addressing in the draft.  consider:

>         if address :matches ["To", "Cc"] ["kjetilho@*", "k.t.homme@*"]

> if a message contains both "To: [email-masked]" and "Cc:
> [email-masked]" -- what's the value of ${1} ?

> the current draft says:

>         The interpreter MUST short-circuit tests, ie. not perform more
>         tests than necessary to find the result.

> so the behaviour is undefined.

I suggest that this case is best left undefined.

> one suggestion was to specify ordering explicitly:  for each pattern,
> iterate over each header in the list.  (according to this algorithm,
> ${1} holds "darwin.uio.no".)

> the other view is that users which need determinism can write

> 	if anyof(address :matches ["To", "Cc"] "kjetilho@*",
> 		 address :matches ["To", "Cc"] "k.t.homme@*")

> in either case, I think the draft should make clear whether the result
> is undefined or not.

I agree. I have no problem with requiring left to right short circuit
evaluation of anyof and allof since I suspect most implementations do it
this way already. Evaluating lists in order may be more problematic, and I
could easily see different implementations having done iterators over
multiple list arguments differently, and it is quite possible for
them to have good reasons for doing so.

> on a slightly related note, the draft rules out cute tricks such as

> 	if allof(address :matches ["To", "Cc"] "kjetilho@*",
> 		 address :is ["To", "Cc"] "abuse@${1}")

> based on this wording:

>         The expanded string MUST use the variable values which are
>         current when control reaches the statement the string is part
>         of.

> in other words, ${1} expands to the value it had before the first
> address test.

This sort of thing can get to be so unclear I'm almost tempted to
leave it undefined as well so people won't write stuff this obscurely.
But that's probably a bad idea.

				Ned

Subject: Re: draft-homme-sieve-variables-03.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Tony Hansen <[email-masked]>, IETF MTA Filters List <[email-masked]>
Date: Thu, 12 Aug 2004 20:46:23 +0200
Sender: [email-masked]

On Thu, 2004-08-12 at 14:42 -0400, Cyrus Daboo wrote:
> Kjetil Torgrim Homme <[email-masked]> wrote:
> 
> >> I think the formality is necessary. Consider this:
> >>
> >>      When a string is evaluated, substrings matching variable-ref
> >>      MUST BE replaced by the value of variable-name.  The string
> >>      MUST BE passed through exactly once.
> >
> > okay, but I stuck to your first patch, only changing "shall" into
> > "SHALL" :-)
> 
> I think it has to be a MUST - we can't allow implementations to ignore 
> variables when they are actually used!

I'm kind of glad to see it's not only I who misremembers [KEYWORDS] :-)

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

-- 
Kjetil T.

Date: Thu, 12 Aug 2004 11:42:32 -0700 (PDT)
From: [email-masked]
Subject: Re: a conflict between Sieve base and variables
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> [RFC 3028]
> | 2.5.     Tests
> |
> |    Tests are given as arguments to commands in order to control their
> |    actions.  In this document, tests are given to if/elsif/else to
> |    decide which block of code is run.
> |
> |    Tests MUST NOT have side effects.  That is, a test cannot affect the
> |    state of the filter or message.  No tests in this specification have
> |    side effects, and side effects are forbidden in extension tests as
> |    well.

> it's interesting to see that in the discussion leading up to this in
> late 1998 Tim Showalter wrote:

> 4.  Request: Short-circuit evaluation should be either MAY or MUST, and
>     must be discussed in case it matters in the future.

>     (I have heard contradictory opinions on this.  Someone (I forget
>     who) wanted it removed since it doesn't yet matter.  Chris (and
>     probably others) want it in there because it will probably
>     eventually matter.  I propose that it has to be discussed, is a MAY
>     for implementations, and a MUST if extensions offer tests with side
>     effects.)

> in the end the consensus was to sidestep the short-circuit requirement
> by outlawing side effects.

> when Marc Mutz brought up the conflict between the base specification
> and the variables extension, Ned replied:

> > We have to reach consensus to revise the specification and remove the
> > MUST.

> must this be done before submitting "variables" to IESG?

Coincident with it would be OK.

				Ned

Date: Thu, 12 Aug 2004 14:42:35 -0400
From: Cyrus Daboo <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>, Tony Hansen <[email-masked]>
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: draft-homme-sieve-variables-03.txt
Sender: [email-masked]

Hi Kjetil,

--On Thursday, August 12, 2004 8:34 PM +0200 Kjetil Torgrim Homme 
<[email-masked]> wrote:

>> I think the formality is necessary. Consider this:
>>
>>      When a string is evaluated, substrings matching variable-ref
>>      MUST BE replaced by the value of variable-name.  The string
>>      MUST BE passed through exactly once.
>
> okay, but I stuck to your first patch, only changing "shall" into
> "SHALL" :-)

I think it has to be a MUST - we can't allow implementations to ignore 
variables when they are actually used!

-- 
Cyrus Daboo

Subject: Re: draft-homme-sieve-variables-03.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Thu, 12 Aug 2004 20:34:12 +0200
Sender: [email-masked]

On Thu, 2004-08-12 at 13:05 -0400, Tony Hansen wrote:
> I think the formality is necessary. Consider this:
> 
>      When a string is evaluated, substrings matching variable-ref
>      MUST BE replaced by the value of variable-name.  The string
>      MUST BE passed through exactly once.

okay, but I stuck to your first patch, only changing "shall" into
"SHALL" :-)

-- 
Kjetil T.

Subject: regarding short-circuiting
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Thu, 12 Aug 2004 20:14:31 +0200
Sender: [email-masked]

while perusing the list archive, I found another point which probably
needs addressing in the draft.  consider:

        if address :matches ["To", "Cc"] ["kjetilho@*", "k.t.homme@*"]

if a message contains both "To: [email-masked]" and "Cc:
[email-masked]" -- what's the value of ${1} ?

the current draft says:

        The interpreter MUST short-circuit tests, ie. not perform more
        tests than necessary to find the result.

so the behaviour is undefined.

one suggestion was to specify ordering explicitly:  for each pattern,
iterate over each header in the list.  (according to this algorithm,
${1} holds "darwin.uio.no".)

the other view is that users which need determinism can write

	if anyof(address :matches ["To", "Cc"] "kjetilho@*",
		 address :matches ["To", "Cc"] "k.t.homme@*")

in either case, I think the draft should make clear whether the result
is undefined or not.

on a slightly related note, the draft rules out cute tricks such as

	if allof(address :matches ["To", "Cc"] "kjetilho@*",
		 address :is ["To", "Cc"] "abuse@${1}")

based on this wording:

        The expanded string MUST use the variable values which are
        current when control reaches the statement the string is part
        of.

in other words, ${1} expands to the value it had before the first
address test.

(the user can get the desired behaviour by nesting if-tests.)
-- 
Kjetil T.

Subject: a conflict between Sieve base and variables
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Thu, 12 Aug 2004 20:12:48 +0200
Sender: [email-masked]

[RFC 3028]
| 2.5.     Tests
| 
|    Tests are given as arguments to commands in order to control their
|    actions.  In this document, tests are given to if/elsif/else to
|    decide which block of code is run.
| 
|    Tests MUST NOT have side effects.  That is, a test cannot affect the
|    state of the filter or message.  No tests in this specification have
|    side effects, and side effects are forbidden in extension tests as
|    well.

it's interesting to see that in the discussion leading up to this in
late 1998 Tim Showalter wrote:

4.  Request: Short-circuit evaluation should be either MAY or MUST, and
    must be discussed in case it matters in the future.

    (I have heard contradictory opinions on this.  Someone (I forget
    who) wanted it removed since it doesn't yet matter.  Chris (and
    probably others) want it in there because it will probably
    eventually matter.  I propose that it has to be discussed, is a MAY
    for implementations, and a MUST if extensions offer tests with side
    effects.)

in the end the consensus was to sidestep the short-circuit requirement
by outlawing side effects.

when Marc Mutz brought up the conflict between the base specification
and the variables extension, Ned replied:

> We have to reach consensus to revise the specification and remove the
> MUST.

must this be done before submitting "variables" to IESG?

-- 
Kjetil T.

Date: Thu, 12 Aug 2004 13:05:09 -0400
From: Tony Hansen <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: draft-homme-sieve-variables-03.txt
Sender: [email-masked]

Kjetil Torgrim Homme wrote:
> On Thu, 2004-08-12 at 10:28 -0400, Tony Hansen wrote:
> 
>>Kjetil Torgrim Homme wrote:
>>
>>>is it appropriate to use these capitalised forms everywhere?  if so,
>>>this should(!) be a MUST.
>>
>>SHALL and MUST are equivalent in strength. See [KEYWORDS].
> 
> doh!
> 
> but I still think it makes the text needlessly formal.
> 
>         When a string is evaluated, substrings matching variable-ref
>         shall be replaced by the value of variable-name.  Only one pass
>         through the string shall be done.
> 
> consider a rewrite such as
> 
>         When a string is evaluated, substrings matching variable-ref are
>         replaced by the value of variable-name.  The string is only
>         passed through once.
> 
> is this text less binding for the implementor?
> 
> sorry about the stylistic quibbling, I'm just curious.

I think the formality is necessary. Consider this:

     When a string is evaluated, substrings matching variable-ref
     MUST BE replaced by the value of variable-name.  The string
     MUST BE passed through exactly once.

	Tony Hansen
	[email-masked]

Subject: Re: draft-homme-sieve-variables-03.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Thu, 12 Aug 2004 18:46:46 +0200
Sender: [email-masked]

On Thu, 2004-08-12 at 10:28 -0400, Tony Hansen wrote:
> Kjetil Torgrim Homme wrote:
> > is it appropriate to use these capitalised forms everywhere?  if so,
> > this should(!) be a MUST.
> 
> SHALL and MUST are equivalent in strength. See [KEYWORDS].

doh!

but I still think it makes the text needlessly formal.

        When a string is evaluated, substrings matching variable-ref
        shall be replaced by the value of variable-name.  Only one pass
        through the string shall be done.

consider a rewrite such as

        When a string is evaluated, substrings matching variable-ref are
        replaced by the value of variable-name.  The string is only
        passed through once.

is this text less binding for the implementor?

sorry about the stylistic quibbling, I'm just curious.
-- 
Kjetil T.

Date: Thu, 12 Aug 2004 11:43:19 -0400
From: Cyrus Daboo <[email-masked]>
To: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: Are option extensions exclusive?
Sender: [email-masked]

Hi Michael,

--On Thursday, August 12, 2004 4:29 PM +0200 Michael Haardt 
<[email-masked]> wrote:

> But can I use
>   command ":a" ":b"

Look at the base spec's description of positional, tagged and option 
arguments in section 2.6 - I think that makes it pretty clear how to handle 
this.

Also the extensibility section (6) in the base spec requires extensions to 
explicitly state how they interact (or not) with other actions (that is a 
MUST).

-- 
Cyrus Daboo

Date: Thu, 12 Aug 2004 15:55:08 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Are option extensions exclusive?
Sender: [email-masked]

I just want to make a general observation that this is nothing unique to 
Sieve. For example, there is the same issue for IMAP protocol extensions.
So each extension should try to describe all extensions it is 
incompatible with, or when there are some special interactions.

Michael Haardt wrote:

>>Extensions can be mutually exclusive, but normally won't be.
>>    
>>
>
>I was talking specifically about options.  Say extension "a" adds
>":a" for a command and extension "b" adds ":b" for the same command.
>
>Obviously, the script can use both
>
>  command ":a"
>
>and
>
>  command ":b"
>
>But can I use
>
>  command ":a" ":b"
>
>?
>
>Each extension defines how the option modifies the semantics of
>and only the /base/ command and its /base/ options.  In case the
>extension options interact semantically, there is a problem.
>  
>

Date: Thu, 12 Aug 2004 07:49:58 -0700 (PDT)
From: [email-masked]
Subject: Re: Are option extensions exclusive?
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > Extensions can be mutually exclusive, but normally won't be.

> I was talking specifically about options.  Say extension "a" adds
> ":a" for a command and extension "b" adds ":b" for the same command.

> Obviously, the script can use both

>   command ":a"

> and

>   command ":b"

> But can I use

>   command ":a" ":b"

> ?

Again, that depends. If:

(a) The interpreter supports both extensions.
(b) Both are listed in the require clause.
(c) Both extensions can be used at the same time.

Then the answer is "yes". Isn't this obvious?

				Ned

Date: Thu, 12 Aug 2004 07:32:54 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-homme-sieve-variables-03.txt
To: Kjetil Torgrim Homme <[email-masked]>
Cc: Tony Hansen <[email-masked]>, IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

> On Wed, 2004-08-11 at 11:21 -0400, Tony Hansen wrote:
> > It says this:
> >
> >     This extension changes the semantics of quoted-string, multi-line-
> >     literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
> >     sion of the value of variables.  The syntax follows [ABNF].
> >
> > but never gives the redefined ABNF for quoted-string, multi-line-literal
> > nor multi-line-dotstuff.

> my very first draft (not submitted) tried to make a change to the
> syntax, but it was pointed out on this list that it was ambiguous:
> *CHAR expands to valid variable references.  I tried to rewrite the
> syntax to avoid the problem, but it got really convoluted.

Exacly. I ran into the same thing in MIME when I tried to fix the
ABNF there that did this. The solution was to dump it all. I don't
believe I've seen a single complaint that this was done.

> list
> consensus at the time was to leave the syntax alone and change the
> semantics.  this also mimics the natural way of implementing the
> extension, IMHO.

Given the recent addition of text making it clear extensions may need
access to unexpanded parameters, it is pretty much the only way to
implement it.

> I do agree the wording in that paragraph is a little confusing, though.
> perhaps it's better to put the grammar _below_ the explanation of the
> procedure.  also, the reference to [ABNF] is a better fit in the
> conventions paragraph in the introduction:

>     Conventions for notations are as in [SIEVE] section 1.1, including
> -   use of [KEYWORDS].  In this document, "character" means a [UNICODE]
> +   use of [KEYWORDS] and [ABNF].  In this document, "character" means a

Much better.

> my copy now says:

> 3.  Interpretation of strings

>    This extension changes the semantics of quoted-string, multi-line-
>    literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
>    sion of the value of variables.

>    When a string is evaluated, substrings matching variable-ref shall be
>    replaced by the value of variable-name.  Only one pass through the
>    string shall be done.  Variable names are case insensitive, so "foo"
>    and "FOO" refer to the same variable.  Unknown variables are replaced
>    by the empty string.

>       variable-ref        =  "${" variable-name "}"
>       variable-name       =  num-variable / *namespace identifier
>       namespace           =  identifier "."
>       num-variable        =  1*DIGIT

>    Examples:
>       [...]

This sounds fine to me.

				Ned

To: [email-masked]
Subject: Re: Are option extensions exclusive?
From: Michael Haardt <[email-masked]>
Date: Thu, 12 Aug 2004 16:29:47 +0200
Sender: [email-masked]

> Extensions can be mutually exclusive, but normally won't be.

I was talking specifically about options.  Say extension "a" adds
":a" for a command and extension "b" adds ":b" for the same command.

Obviously, the script can use both

  command ":a"

and

  command ":b"

But can I use

  command ":a" ":b"

?

Each extension defines how the option modifies the semantics of
and only the /base/ command and its /base/ options.  In case the
extension options interact semantically, there is a problem.

> > o  Option extensions can be used together.  Extensions are supposed
> >    to address completely different issues, thus not interacting
> >    badly.  I could imagine that existing implementations work that way
> >    and I prefer it.
>
> This is the normal case.

Well, then it should be specified when this applies and when it doesn't.

Michael

Date: Thu, 12 Aug 2004 10:28:09 -0400
From: Tony Hansen <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: draft-homme-sieve-variables-03.txt
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

> On Wed, 2004-08-11 at 11:21 -0400, Tony Hansen wrote:
> 
> my very first draft (not submitted) tried to make a change to the
> syntax, but it was pointed out on this list that it was ambiguous:
> ...
> my copy now says:
> ...

looks good

>>242c242
>><    When the string is evaluated, substrings matching variable-ref
>><    shall
>>---
>> >    When the string is evaluated, substrings matching variable-ref
>> >    SHALL
> 
> is it appropriate to use these capitalised forms everywhere?  if so,
> this should(!) be a MUST.

SHALL and MUST are equivalent in strength. See [KEYWORDS].

	Tony Hansen
	[email-masked]

Date: Thu, 12 Aug 2004 07:03:22 -0700 (PDT)
From: [email-masked]
Subject: Re: Are option extensions exclusive?
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Hello,

> there has been talk recently if commands have been extended with new
> options, which is the case, although rare (:copy, the suggestion to
> rework refuse into reject options).

> IMHO, such extensions may be very useful, but so far I miss a
> specification if multiple option extensions may be used together or not.

This is covered in the base sieve specification. Each extension has
a capability name associated with it. The name of each extension used
has to be listed in a require clause at the beginning of the script
before the extension can be used. An implementation that doesn't
support a given capability will refuse to run the script, and compliant
implementations are supposed to refused to run scripts that fail to list
all the capabilities they use.

It is possible, although certainly not encouraged, for two extensions hto
conflict with each other. (The most likely reason for this: An extension gets
specified, deployed, and then revised in an incompatible way. The capability
string would need to change if this happens. The one example we have of this so
far is the imapflags extension.) In this case an implementation can support
both but forbid both from being listed in the require clause at the same time.

Now, nothing about this is in any way specific to extensions that add
tests or actions; it also applies to extensions that add options to existing
commands.

> I can imagine three answers:

> o  Option extensions are exclusive.  This makes it easy for the
>    author to define the semantics, but some possibly useful
>    combinations would be forbidden.

Extensions can be mutually exclusive, but normally won't be.

> o  Option extensions can be used together.  Extensions are supposed
>    to address completely different issues, thus not interacting
>    badly.  I could imagine that existing implementations work that way
>    and I prefer it.

This is the normal case.

> o  The extension specifies if it is exclusive or not.  Do we need
>    this freedom and does it make sense?

I think it is fairly obvious that an extension that conflicts with another
extension would need to make that clear in its specification.

				Ned

Date: Tue, 10 Aug 2004 20:23:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Matthew Elvey <[email-masked]>
CC: [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Sender: [email-masked]

Matthew Elvey wrote:

> [...]

> Arguments for the change:
> 1)A change won't break anything, according to the URL below.
>
> Have we done something like this (e.g. modify an action to accept a 
> special parameter flag) before? 

Yes, :copy parameter to fileinto.

Subject: Re: Are option extensions exclusive?
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Thu, 12 Aug 2004 14:33:20 +0200
Sender: [email-masked]

On Thu, 2004-08-12 at 14:05 +0200, Michael Haardt wrote:
> there has been talk recently if commands have been extended with new
> options, which is the case, although rare (:copy, the suggestion to
> rework refuse into reject options).
> 
> IMHO, such extensions may be very useful, but so far I miss a
> specification if multiple option extensions may be used together or not.

I'd say: _obviously_ extensions which are registered with IANA can be
combined, no matter their mechanisms.  any exceptions to this must be
explicitly listed in the new extension.

> o  The extension specifies if it is exclusive or not.  Do we need
>    this freedom and does it make sense?

yes.

> Anyway, it should be specified somewhere.  If it is, please just
> point me to the relevant document.

I don't see a great need, but I guess an update of RFC 3028 could
generalise this paragraph to include tests and options:

   Extension actions MUST state how they interact with actions defined
   in this specification.

e.g.

   Extensions MUST state how they interact with mechanisms defined
   in this specification.

-- 
Kjetil T.

To: [email-masked]
Subject: Are option extensions exclusive?
From: Michael Haardt <[email-masked]>
Date: Thu, 12 Aug 2004 14:05:14 +0200
Sender: [email-masked]

Hello,

there has been talk recently if commands have been extended with new
options, which is the case, although rare (:copy, the suggestion to
rework refuse into reject options).

IMHO, such extensions may be very useful, but so far I miss a
specification if multiple option extensions may be used together or not.

I can imagine three answers:

o  Option extensions are exclusive.  This makes it easy for the
   author to define the semantics, but some possibly useful
   combinations would be forbidden.
o  Option extensions can be used together.  Extensions are supposed
   to address completely different issues, thus not interacting
   badly.  I could imagine that existing implementations work that way
   and I prefer it.
o  The extension specifies if it is exclusive or not.  Do we need
   this freedom and does it make sense?

Anyway, it should be specified somewhere.  If it is, please just
point me to the relevant document.

Michael

Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
From: Kjetil Torgrim Homme <[email-masked]>
To: Matthew Elvey <[email-masked]>
Cc: [email-masked]
Date: Thu, 12 Aug 2004 11:45:18 +0200
Sender: [email-masked]

On Wed, 2004-08-11 at 16:30 -0700, Matthew Elvey wrote:
> On 8/10/2004 4:30 PM, Kjetil Torgrim Homme sent forth electrons to convey:
> > I think this draft doesn't go far enough: it should state the rules for
> > running a Sieve script before the message is accepted. it can be kept
> > quite simple: a Sieve script can be run after RCPT TO, but only "stop"
> > and "refuse" are acted on. tests against headers before DATA will
> > likewise fail. there is no implicit keep.
> 
> This is out of scope.  An extension allowing sieve scripts to run early 
> in the SMTP conversation may well be a good idea, however.

I don't agree, since I can't think of any other actions than "refuse"
which make any sense before DATA.

> Normally, Sieve should (BCP) run after the end-of-data (CRLF.CRLF) has 
> been sent, but not acknowledged.
> 
> My sieve script would do all sorts of crazy things under the scheme 
> suggested.   I'd probably have to very carefully debug it, e.g.  |not 
> header ||:||contains ||"Subject"... would always trigger?...
> |

I don't quite understand your example, but I don't think it is a problem
according to the set of rules I quickly outlined.  think of "stop" as
"accept", "refuse" as, well, "refuse", and every other action as "no-
op".  default behaviour (when the execution of the script reaches the
end of file) is "accept".

it may be worth noting that an MTA can compile a script into two forms,
one for running after RCPT TO, one for after DATA.  a very simple
optimisation is to transform any script which isn't using both the
"refuse" and the "envelope" extensions into simply "stop" (or "accept",
if you will).

-- 
Kjetil T.

Subject: Re: draft-homme-sieve-variables-03.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Thu, 12 Aug 2004 11:22:39 +0200
Sender: [email-masked]

On Wed, 2004-08-11 at 11:21 -0400, Tony Hansen wrote:
> It says this:
> 
>     This extension changes the semantics of quoted-string, multi-line-
>     literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
>     sion of the value of variables.  The syntax follows [ABNF].
> 
> but never gives the redefined ABNF for quoted-string, multi-line-literal 
> nor multi-line-dotstuff.

my very first draft (not submitted) tried to make a change to the
syntax, but it was pointed out on this list that it was ambiguous:
*CHAR expands to valid variable references.  I tried to rewrite the
syntax to avoid the problem, but it got really convoluted.  list
consensus at the time was to leave the syntax alone and change the
semantics.  this also mimics the natural way of implementing the
extension, IMHO.

I do agree the wording in that paragraph is a little confusing, though.
perhaps it's better to put the grammar _below_ the explanation of the
procedure.  also, the reference to [ABNF] is a better fit in the
conventions paragraph in the introduction:

    Conventions for notations are as in [SIEVE] section 1.1, including
-   use of [KEYWORDS].  In this document, "character" means a [UNICODE]
+   use of [KEYWORDS] and [ABNF].  In this document, "character" means a

my copy now says:

3.  Interpretation of strings

   This extension changes the semantics of quoted-string, multi-line-
   literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
   sion of the value of variables.

   When a string is evaluated, substrings matching variable-ref shall be
   replaced by the value of variable-name.  Only one pass through the
   string shall be done.  Variable names are case insensitive, so "foo"
   and "FOO" refer to the same variable.  Unknown variables are replaced
   by the empty string.

      variable-ref        =  "${" variable-name "}"
      variable-name       =  num-variable / *namespace identifier
      namespace           =  identifier "."
      num-variable        =  1*DIGIT

   Examples:
      [...]

> 242c242
> <    When the string is evaluated, substrings matching variable-ref
> <    shall
> ---
>  >    When the string is evaluated, substrings matching variable-ref
>  >    SHALL

is it appropriate to use these capitalised forms everywhere?  if so,
this should(!) be a MUST.

> 244c244
> <    string shall be done.  Variable names are case insensitive.
> 407c407
> <    stops.  Variable names are case insensitive.

hmm, a little duplication.  I guess it doesn't hurt to point it out
twice, though.

thank you for your nits, with the exception of SHALL, they have been
incorporated in my copy.

-- 
Kjetil T.

Date: Wed, 11 Aug 2004 16:30:04 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
Sender: [email-masked]

I sure wish for an SMTP extension that allows for transmission of 
non-ASCII reply
text in a response. Can the scheme used to put such text in Subject 
headers be easily applied here?

Revisions:
Two texts is a necessary hack given the multiple recipient case and the 
non-ASCII text issue. Given
<action> <SMTP> <MDN>, an implementation supporting "refuse" MUST do an 
SMTP-time reject with SMTP, unless
a)a message has multiple valid recipients
or
b)MDN contains non-ASCII characters.

I am concerned that adding
c)or it is unable to do so
 is an invitation to an implementation that can't to SMTP-time refusals, 
but says (either in marketing material OR by accepting a script 
requiring it) that requires "refuse")
that it supports 'refuse'. This could be addressed by introducing the 
term <Sieve "refuse" syntax-only compatibility>.
and saying that only implementations that support SMTP-time refusals are 
to be termed "refuse"-compatible or "refuse"-supporting.

Sending MDNs where SMTP rejects can be done is simply not BCP.  
(Exception:  MDN contains a non-ASCII supported language inexpressible 
in the reject.)   I wish not to go out of my way to change the spec to 
facilitate poor policy.

On 8/10/2004 1:17 PM, Kristin Hubner sent forth electrons to convey:

>
>
> Being able to provide a reason in their "own" language (a language 
> that  needs a non-ASCII
> charset for proper representation) is very important to some users.   
> I  can hardly stress
> enough how important this is to some users and user communities!
>
> So either: (1) A "relaxed" reject action would need another parameter  
> specifying whether
> SMTP level rejection vs. later MDN should be performed, and then the  
> value of that
> parameter would need to affect what sorts of characters are allowed 
> in  the reason string, or
> else (2) A "relaxed" reject action would need two parameters, one 
> being  the SMTP rejection
> text (ASCII only) and a second parameter would be the MDN text which  
> would allow
> non-ASCII text.   Or maybe some third approach  I haven't thought of,  
> as long as it allows
> non-ASCII text when non-ASCII text is legal, and uses ASCII text when  
> ASCII text is required.
>
> To me, such approaches, complicating the reason text in a single 
> action  ("relaxed"
> reject) seems uglier than adding a new action refuse that does the 
> SMTP  rejection case and
> leaving reject alone as the MDN rejection case.  And I think that the  
> necessity for scripts
> to be aware of the difference between SMTP rejection and MDN 
> rejection  means that
> they might as well be coded with different actions -- I think that  
> there is no real simplicity
> benefit to using a single action.
>
> Elvey wrote:
>
>>> What's the gist of the argument for the change [modify 'reject' 
>>> instead of
>>> create 'refuse']?  
>>

Small procedural note: The above question (from me) needed to be 
answered on the list.  That's how the IETF is supposed to work. I'm not 
strongly opposed to the idea, but an argument for it needed to be 
presented!  Cyrus has argued that the multiple recipient case makes it 
preferable, and at first I agreed.  But the multiple recipient case can 
be handled by a new action with two texts, as Kristin suggested.  So 
there's no argument for the change right now.

Allowing the user to specify the response code is a bad idea - 
featuritits.  It provides very little to no benefit, violates KISS, and 
introduces complications.
What if the user specifies 200 as the response code?  :) 

I want refuse to have all the features it must have, and no more.

On 8/10/2004 4:30 PM, Kjetil Torgrim Homme sent forth electrons to convey:

>
> I think this draft doesn't go far enough: it should state the rules for
> running a Sieve script before the message is accepted. it can be kept
> quite simple: a Sieve script can be run after RCPT TO, but only "stop"
> and "refuse" are acted on. tests against headers before DATA will
> likewise fail. there is no implicit keep.

This is out of scope.  An extension allowing sieve scripts to run early 
in the SMTP conversation may well be a good idea, however.
Normally, Sieve should (BCP) run after the end-of-data (CRLF.CRLF) has 
been sent, but not acknowledged.

My sieve script would do all sorts of crazy things under the scheme 
suggested.   I'd probably have to very carefully debug it, e.g.  |not 
header ||:||contains ||"Subject"... would always trigger?...
|

> <snip>
> I strongly object to section 4.2 of the draft. it must not be possible
> to "reject" a message but actually store it. we should not condone
> lying about whether a message was accepted or not.

It says :
...

> "Implementations SHOULD prohibit reject when used with other
> actions." However we feel that "refuse" should be permitted when
> used with other actions such as "fileinto" and "redirect". This
> could be useful for analyzing, tracking or reporting spam. Also,
> users can use tricks (such as multiple redirects back to their own
> email addresses) to get around such a prohibition anyway.)

Anyone else have feelings on this?

On 8/10/2004 4:51 PM, Cyrus Daboo sent forth electrons to convey:

> The reality is that even refuse suffers from this problem as there are 
> several cases where refuse results in a DSN joe-job (in fact I think 
> it will be the majority of cases). The only way to really address this 
> is to only allow discard.

I disagree. The draft states that
"a message has multiple valid recipients" is the ONLY case where DSN may 
be sent by Sieve. The only other issue is relays that don't themselves 
run Sieve.
Most spam (80%-90%, IIRC) is sent with one RCPT TO. Note, a refuse in an 
LMTP dialog is NOT allowed by the spec!
"This extension can be only supported by a Sieve implementation running 
in a MTA."

I'm going to be way for a couple weeks, folks. Sorry.  I hope Alexey has 
time to handle things.

Thanks for all the feedback! 

Date: Wed, 11 Aug 2004 17:25:22 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
CC: [email-masked], IETF MTA Filters List <[email-masked]>
Subject: Re: draft-homme-sieve-variables-03.txt
Sender: [email-masked]

[email-masked] wrote:

>> It says this:
> 
>>     This extension changes the semantics of quoted-string, multi-line-
>>     literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
>>     sion of the value of variables.  The syntax follows [ABNF].
> 
>> but never gives the redefined ABNF for quoted-string, multi-line-literal
>> nor multi-line-dotstuff.
> 
> I don't get this at all. Why would redefining the _semantics_ of
> something change its _syntax_? Not only do I thini redefning the
> syntax of the things you list is unnecessary, I view it as quite
> harmful and I strongly oppose adding it. I base this on having had to
> deal with similar "overlapped" syntax in the MIME draft, which ended
> up causing lots of confusion and no enlightenment.
> 
> Perhaps the problem is the trailing statement referring to [ABNF].
> This could be moved to a separate section if it is confusing for it
> to be there.

Okay, I guess my problem is that I was thinking it really changed the 
syntax. When I was reading it, and looked at the definition of 
quoted-string, etc., I thought "doesn't this mean that quoted-string 
needs to change to

	 quoted-string = DQUOTE *(CHAR / "${" *(DIGIT / LETTER) "}")
			 DQUOTE

?"

But if you want to treat the parsing of the string separately from the 
language parsing, then I guess it really does mean that only the 
semantics is changing, and hence, no ABNF changes are required.

At this point, I'll just say "it can be done either way" and forego any 
further comment.

	Tony Hansen
	[email-masked]

Date: Wed, 11 Aug 2004 09:34:12 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-homme-sieve-variables-03.txt
To: Tony Hansen <[email-masked]>
Cc: [email-masked], IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

> It says this:

>     This extension changes the semantics of quoted-string, multi-line-
>     literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
>     sion of the value of variables.  The syntax follows [ABNF].

> but never gives the redefined ABNF for quoted-string, multi-line-literal
> nor multi-line-dotstuff.

I don't get this at all. Why would redefining the _semantics_ of something
change its _syntax_? Not only do I thini redefning the syntax of the things you
list is unnecessary, I view it as quite harmful and I strongly oppose adding
it. I base this on having had to deal with similar "overlapped" syntax in the
MIME draft, which ended up causing lots of confusion and no enlightenment.

Perhaps the problem is the trailing statement referring to [ABNF]. This could
be moved to a separate section if it is confusing for it to be there.

> Nits below.

The fixes for the nits look fine to me.

				Ned

Date: Wed, 11 Aug 2004 11:21:26 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], IETF MTA Filters List <[email-masked]>
Subject: draft-homme-sieve-variables-03.txt
Sender: [email-masked]

It says this:

    This extension changes the semantics of quoted-string, multi-line-
    literal and multi-line-dotstuff found in [SIEVE] to enable the inclu-
    sion of the value of variables.  The syntax follows [ABNF].

but never gives the redefined ABNF for quoted-string, multi-line-literal 
nor multi-line-dotstuff.

Nits below.

	Tony Hansen
	[email-masked]

201c201
<    scripts which include a require clause for the "variables"
<    extension.
---
 >    scripts that include a require clause for the "variables"
 >    extension.
242c242
<    When the string is evaluated, substrings matching variable-ref
<    shall
---
 >    When the string is evaluated, substrings matching variable-ref
 >    SHALL
244c244
<    string shall be done.  Variable names are case insensitive.
---
 >    string SHALL be done.  Variable names are case insensitive.
407c407
<    stops.  Variable names are case insensitive.
---
 >    stops.  Variable names are case insensitive, so ${foo} and ${FOO}
 >    refer to the same variable.
437c437
<    Modifiers are applied on value before it is stored in the variable.
---
 >    Modifiers are applied on a value before it is stored in the
 >    variable.
463,466c463,466
<       set :length "var" "${var}";            => "15"
<       set :lower "var" "${var}";             => "jumbled letters"
<       set :upperfirst "var" "${var}";        => "JuMBlEd lETteRS"
<       set :upperfirst :lower "var" "${var}"; => "Jumbled letters"
---
 >       set :length "var2" "${var}";            => "15"
 >       set :lower "var2" "${var}";             => "jumbled letters"
 >       set :upperfirst "var2" "${var}";        => "JuMBlEd lETteRS"
 >       set :upperfirst :lower "var2" "${var}"; => "Jumbled letters"
473c473
<    The value is the decimal number of letters in the expansion,
---
 >    The value is the decimal number of characters in the expansion,
578,580c578,579
<    When numbered variables are used, strings can contain arbitrary
<    values controlled by the sender of the e-mail if the author of the
<    script isn't careful.
---
 >    When numbered variables are used, and the author of the script
 >    isn't careful, strings can contain arbitrary values controlled by
 >    the sender of the e-mail.

Date: Tue, 10 Aug 2004 17:39:59 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> On tir, 2004-08-10 at 16:18 -0700, Philip Guenther wrote:
> > I disagree: just because the text for the two may be different
> > doesn't mean I want to be forced to choose which of the two is done.
> > I would prefer to be able to say "do an SMTP-level reject if you
> > can with _this_ text, else send an MDN with _this_ text".

> I think "reject" should be deprecated.  it is never appropriate to send
> an MDN.  the tests available in Sieve today are not sufficient to have
> any chance of avoiding being an accomplice in a joe-job attack.

I certainly agree that using reject to block spam or virii is inappropriate.
But this assumes that this is the only think you'd use it for. There are
other uses - not all email is spam. At least not yet...

I guess I'm slightly in favor of a new command, but only slightly.

				Ned

Subject: Re: draft-elvey-refuse-sieve-02.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Wed, 11 Aug 2004 02:31:47 +0200
Sender: [email-masked]

Cyrus Daboo wrote:
> The effectiveness of reducing joe-job DSNs depends on exactly how the 
> original spam message is being submitted and sent. If the submission server 
> (MSA) is the client that connects to the final delivery server (MDA) where 
> SIEVE is being run, then the DSN/MDN is avoided. However, if there is one 
> or more intervening MTA's relaying the message, then a DSN will always be 
> generated by the client connecting to the MDA when the script does the SMTP 
> error refuse. So the question is how many messages fall into these two 
> categories: 'direct' delivery vs 'relayed' delivery. That will determine 
> the real effectiveness of refuse.

indeed.  I claim that most spam is submitted directly to an MX
responsible for the final recipient.  the spammer software will
obviously not produce an MDN in response to the DSN.

I want to make it possible to run a user's Sieve script on the border.
this can't be guaranteed in general, but a system designer can make sure
that the MTA on the border supports the same Sieve extensions as the
MDA.
-- 
Kjetil T.

Date: Tue, 10 Aug 2004 17:27:42 -0700
From: Kristin Hubner <[email-masked]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
To: Philip Guenther <[email-masked]>
Cc: Matthew Elvey <[email-masked]>, [email-masked]
Sender: [email-masked]

On Aug 10, 2004, at 4:18 PM, Philip Guenther wrote:

>
> Kristin Hubner <[email-masked]> writes:
> ..
>> I'm sorry I missed the discussion, as perhaps the issues I will repeat
>> below have been already discussed.
>
> Ned brought this up and it was discussed.
>
>
> ...
>> So either: (1) A "relaxed" reject action would need another parameter
>> specifying whether SMTP level rejection vs. later MDN should be
>> performed, and then the value of that parameter would need to
>> affect what sorts of characters are allowed in the reason string,
>> or else (2) A "relaxed" reject action would need two parameters,
>> one being the SMTP rejection text (ASCII only) and a second parameter
>> would be the MDN text which would allow non-ASCII text.   Or maybe
>> some third approach  I haven't thought of, as long as it allows
>> non-ASCII text when non-ASCII text is legal, and uses ASCII text
>> when ASCII text is required.
>
> At the lunch meeting, it was felt that (2) was the preferable way
> to resolve this, but that the details should be worked out on the
> list.

I also prefer (2).

>
> IMHO, reject should only send an SMTP-level reject if "given
> permission" by an additional tagged argument.  If this argument was
> given but the implementation was unable to perform rejection at the
> SMTP-level for any reason, then it would send a MDN as if the
> argument hasn't been given at all.

Ok, this is sounding good to me: if the latest plan is to extend 
"reject" by adding
some explicit "do-refuse-if-possible" tag and include both possible 
texts, then that
satisfies my concerns.   I was under the (clearly wrong) impression 
that the latest
plan was that just one text would suffice.

In such a case, though, it's still not clear to me why extending 
"reject" with a
"refuse-if-possible" tag and two texts is then necessarily any simpler 
than making a
new "refuse-if-possible" action with two texts.  But I don't have any 
objections to the
way that such an extended "reject" would work.

> It would be nice if the script could not only specify the SMTP
> response text but also the last two digits of the enhanced status
> code (i.e., y and z in the "x.y.z" after the SMTP status code),
> either via another tagged argument or by pulling them from the start
> of the response text whenever it starts with
> 	1*3digit "." 1*3digit SP
>
>
> ...
>> And I think that the necessity for scripts to be aware of the
>> difference between SMTP rejection and MDN rejection means that
>> they might as well be coded with different actions -- I think that
>> there is no real simplicity benefit to using a single action.
>
> I disagree: just because the text for the two may be different
> doesn't mean I want to be forced to choose which of the two is done.
> I would prefer to be able to say "do an SMTP-level reject if you
> can with _this_ text, else send an MDN with _this_ text".

Yes, I agree that that is exactly what users will tend to want.

>
>
>> The "portable script" argument only works for sites that are
>> supporting English-only (or at best, Western-European-languages-
>> that-can-be-adequately-represented-in-ASCII-only) user communities.
>>
>> For other sites that are already using reject with MDN text that
>> is not ASCII-only, their script already isn't suitable for SMTP
>> reject time interpretation.  Such sites are going to have to care,
>> in their scripts, about the different requirements for reason text
>> for SMTP rejections vs. MDNs.
>
> If specified as I suggested above, these scripts would see *NO*
> change in behavior.

Yes.

Regards,

Kristin

> Philip Guenther

Date: Tue, 10 Aug 2004 20:25:27 -0400
From: Cyrus Daboo <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt
Sender: [email-masked]

Hi Kjetil,

--On Wednesday, August 11, 2004 2:01 AM +0200 Kjetil Torgrim Homme 
<[email-masked]> wrote:

> yes, as it stands, few mail clusters will be able to do this right, but
> it would be nice if we made it possible.  Sieve is today typically run
> by the MDA only, and a refuce in the LMTP dialogue is as you imply of
> little value.  this extension should allow the MTA to run the Sieve
> script, _in_addition_to_ the MDA.  this way, we can do the refuse on the
> border and avoid the DSN joejob problem (or at least drastically
> minimise it).

The effectiveness of reducing joe-job DSNs depends on exactly how the 
original spam message is being submitted and sent. If the submission server 
(MSA) is the client that connects to the final delivery server (MDA) where 
SIEVE is being run, then the DSN/MDN is avoided. However, if there is one 
or more intervening MTA's relaying the message, then a DSN will always be 
generated by the client connecting to the MDA when the script does the SMTP 
error refuse. So the question is how many messages fall into these two 
categories: 'direct' delivery vs 'relayed' delivery. That will determine 
the real effectiveness of refuse.

-- 
Cyrus Daboo

Subject: Re: draft-elvey-refuse-sieve-02.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Wed, 11 Aug 2004 02:01:47 +0200
Sender: [email-masked]

Cyrus Daboo wrote:
> Kjetil Torgrim Homme wrote:
> > I think "reject" should be deprecated.  it is never appropriate to send
> > an MDN.  the tests available in Sieve today are not sufficient to have
> > any chance of avoiding being an accomplice in a joe-job attack.
> 
> Well what is the difference between a DSN and an MDN joe-job? The reality 
> is that even refuse suffers from this problem as there are several cases 
> where refuse results in a DSN joe-job (in fact I think it will be the 
> majority of cases). The only way to really address this is to only allow 
> discard.

yes, as it stands, few mail clusters will be able to do this right, but
it would be nice if we made it possible.  Sieve is today typically run
by the MDA only, and a refuce in the LMTP dialogue is as you imply of
little value.  this extension should allow the MTA to run the Sieve
script, _in_addition_to_ the MDA.  this way, we can do the refuse on the
border and avoid the DSN joejob problem (or at least drastically
minimise it).

> Also this assumes that you are only using sieve for spam filtering, but 
> there are other legitimate uses for it!

but the legitimate uses are wide open for attack.  I'm getting really
tired of "Thank you for contacting Acme customer service.  You've been
assigned ticket #4378353."

-- 
Kjetil T.

Date: Tue, 10 Aug 2004 19:52:52 -0400
From: Cyrus Daboo <[email-masked]>
To: Kristin Hubner <[email-masked]>
cc: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt
Sender: [email-masked]

Hi Kristin,

--On Tuesday, August 10, 2004 1:17 PM -0700 Kristin Hubner 
<[email-masked]> wrote:

> For other sites that are already using reject with MDN text that is not
> ASCII-only, their script
> already isn't suitable for SMTP reject time interpretation.  Such sites
> are going to have to
> care, in their scripts, about the different requirements for reason  text
> for SMTP rejections
> vs. MDNs.
>

In addition to Phillip's comment there is another issue here: how do you do 
deal with multiple recipients? What happens in the case where one 
recipient's script accepts the message and the other does not? In that case 
a 250 has to be returned on SMTP DATA and a DSN sent back for the recipient 
that does not accept the message (the refuse spec does describe that). 
However, the current refuse command only accepts ascii as the reason 
string, and anyone that cares about i18n charset issues will likely want 
the DSN to allow non-ascii.

So to handle the multiple recipient case there has to be a single action 
that can handle both cases: an SMTP error rejection (ascii only) or a 
DSN/MDN (potentially non-ascii) rejection - and the implementation picks 
the appropriate one based on what it is allowed to do for a given message 
and recipient list. Given that I think it makes sense to extend reject 
rather than add a new action.

-- 
Cyrus Daboo

Date: Tue, 10 Aug 2004 19:51:55 -0400
From: Cyrus Daboo <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt;	http://wiki.fastmail.fm/wiki/index.php/Sieve ExtensionsSupportMatrix
Sender: [email-masked]

Hi Kjetil,

--On Wednesday, August 11, 2004 1:33 AM +0200 Kjetil Torgrim Homme 
<[email-masked]> wrote:

>> I disagree: just because the text for the two may be different
>> doesn't mean I want to be forced to choose which of the two is done.
>> I would prefer to be able to say "do an SMTP-level reject if you
>> can with _this_ text, else send an MDN with _this_ text".
>
> I think "reject" should be deprecated.  it is never appropriate to send
> an MDN.  the tests available in Sieve today are not sufficient to have
> any chance of avoiding being an accomplice in a joe-job attack.

Well what is the difference between a DSN and an MDN joe-job? The reality 
is that even refuse suffers from this problem as there are several cases 
where refuse results in a DSN joe-job (in fact I think it will be the 
majority of cases). The only way to really address this is to only allow 
discard.

Also this assumes that you are only using sieve for spam filtering, but 
there are other legitimate uses for it!

-- 
Cyrus Daboo

Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Wed, 11 Aug 2004 01:33:45 +0200
Sender: [email-masked]

On tir, 2004-08-10 at 16:18 -0700, Philip Guenther wrote:
> I disagree: just because the text for the two may be different
> doesn't mean I want to be forced to choose which of the two is done.
> I would prefer to be able to say "do an SMTP-level reject if you
> can with _this_ text, else send an MDN with _this_ text".

I think "reject" should be deprecated.  it is never appropriate to send
an MDN.  the tests available in Sieve today are not sufficient to have
any chance of avoiding being an accomplice in a joe-job attack.

I think a new command is best.
-- 
Kjetil T.

Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
From: Kjetil Torgrim Homme <[email-masked]>
To: Matthew Elvey <[email-masked]>
Cc: [email-masked]
Date: Wed, 11 Aug 2004 01:30:03 +0200
Sender: [email-masked]

On man, 2004-08-09 at 22:46 -0700, Matthew Elvey wrote:
> 1) Belatedly announcing, in case folks missed it:
>     http://www1.ietf.org/internet-drafts/draft-elvey-refuse-sieve-02.txt
> 
>     Last discussion post on 'refuse' was my post on 6/8/04.
>     I believe 'refuse' is ready for last call.

I think this draft doesn't go far enough:  it should state the rules for
running a Sieve script before the message is accepted.  it can be kept
quite simple: a Sieve script can be run after RCPT TO, but only "stop"
and "refuse" are acted on.  tests against headers before DATA will
likewise fail.  there is no implicit keep.

this allows me to write

  if envelope "To" "[email-masked]" {
     refuse "This address has been discontinued"; stop;
  }
  fileinto "INBOX.whatever";

if the test fails, control passes to the fileinto which is ignored,
otherwise, the e-mail is refused.  only after acceptance of the message
after DATA will the fileinto be executed.  (an implementation may elect
to run the Sieve script only once, after DATA.)

I strongly object to section 4.2 of the draft.  it must not be possible
to "reject" a message but actually store it.  we should not condone
lying about whether a message was accepted or not.
-- 
Kjetil T.

To: Kristin Hubner <[email-masked]>
Cc: Matthew Elvey <[email-masked]>, [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix 
Date: Tue, 10 Aug 2004 16:18:17 -0700
Sender: [email-masked]

Kristin Hubner <[email-masked]> writes:
..
>I'm sorry I missed the discussion, as perhaps the issues I will repeat  
>below have been already discussed.

Ned brought this up and it was discussed.

...
>So either: (1) A "relaxed" reject action would need another parameter
>specifying whether SMTP level rejection vs. later MDN should be
>performed, and then the value of that parameter would need to
>affect what sorts of characters are allowed in the reason string,
>or else (2) A "relaxed" reject action would need two parameters,
>one being the SMTP rejection text (ASCII only) and a second parameter
>would be the MDN text which would allow non-ASCII text.   Or maybe
>some third approach  I haven't thought of, as long as it allows
>non-ASCII text when non-ASCII text is legal, and uses ASCII text
>when ASCII text is required.

At the lunch meeting, it was felt that (2) was the preferable way
to resolve this, but that the details should be worked out on the
list.

IMHO, reject should only send an SMTP-level reject if "given
permission" by an additional tagged argument.  If this argument was
given but the implementation was unable to perform rejection at the
SMTP-level for any reason, then it would send a MDN as if the
argument hasn't been given at all.

It would be nice if the script could not only specify the SMTP
response text but also the last two digits of the enhanced status
code (i.e., y and z in the "x.y.z" after the SMTP status code),
either via another tagged argument or by pulling them from the start
of the response text whenever it starts with
	1*3digit "." 1*3digit SP

...
>And I think that the necessity for scripts to be aware of the
>difference between SMTP rejection and MDN rejection means that
>they might as well be coded with different actions -- I think that
>there is no real simplicity benefit to using a single action.

I disagree: just because the text for the two may be different
doesn't mean I want to be forced to choose which of the two is done.
I would prefer to be able to say "do an SMTP-level reject if you
can with _this_ text, else send an MDN with _this_ text".

>The "portable script" argument only works for sites that are
>supporting English-only (or at best, Western-European-languages-
>that-can-be-adequately-represented-in-ASCII-only) user communities.
>
>For other sites that are already using reject with MDN text that
>is not ASCII-only, their script already isn't suitable for SMTP
>reject time interpretation.  Such sites are going to have to care,
>in their scripts, about the different requirements for reason text
>for SMTP rejections vs. MDNs.

If specified as I suggested above, these scripts would see *NO*
change in behavior.

Philip Guenther

Subject: Re: managesieve
From: Kjetil Torgrim Homme <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Date: Wed, 11 Aug 2004 01:06:10 +0200
Sender: [email-masked]

On tir, 2004-08-10 at 23:21 +0200, Simon Josefsson wrote:
> I'm sad to see that ManageSieve apparently won't be on the WG agenda.
> It was suggested ManageSieve was considered a "hack".  Could someone
> explain that?

since it was I who said it, I guess I should come forward.  I only meant
that managesieve is a stopgap measure.  the proper method would be ACAP.

> I'm trying to understand what it is about that is a
> "hack".  To me, ManageSieve much less of a hack compared to
> transferring Sieve from clients to servers over LDAP or ACAP.  I've
> explained it before, but my reason for that is that to be useful, the
> protocol transferring Sieve will have to support syntax validation of
> the script, and crafting that on to LDAP or ACAP is to me a very big
> hack.

ACAP caters for dataset class specific validation rules.  you're right
there is a problem, since the ACAP server can't know which extensions
the server supports, and indeed, there may be more than one server (ACAP
consumer) using the same values.

managesieve assumes that it is run on each server instance.  I don't
think it is problematic that ACAP is used similarily.  (it can partly be
hidden by referrals, ie. multiple servers for different uses at a site
can appear as one to a user.)  the user can still easily migrate
settings between ACAP servers.
-- 
Kjetil T.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Date: Tue, 10 Aug 2004 23:21:07 +0200
Lines: 21
Cancel-Lock: sha1:SbDhJ5vWkyyQYEaY8pQ9bsM6OsY=
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:

> <http://www.xmpp.org/ietf-logs/[email-masked]/2004-08-04.txt>
>
> I will also attempt to write up a brief summary and post to the list in the 
> next day or so.

Very useful, thanks.

I'm sad to see that ManageSieve apparently won't be on the WG agenda.
It was suggested ManageSieve was considered a "hack".  Could someone
explain that?  I'm trying to understand what it is about that is a
"hack".  To me, ManageSieve much less of a hack compared to
transferring Sieve from clients to servers over LDAP or ACAP.  I've
explained it before, but my reason for that is that to be useful, the
protocol transferring Sieve will have to support syntax validation of
the script, and crafting that on to LDAP or ACAP is to me a very big
hack.

Thanks,
Simon

Date: Tue, 10 Aug 2004 13:17:49 -0700
From: Kristin Hubner <[email-masked]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
To: Cyrus Daboo <[email-masked]>
Cc: Matthew Elvey <[email-masked]>, [email-masked]
Sender: [email-masked]

On Aug 10, 2004, at 12:16 PM, Cyrus Daboo wrote:

>
> Hi Matthew,
>
> --On Tuesday, August 10, 2004 11:36 AM -0700 Matthew Elvey  
> <[email-masked]> wrote:
>
>>> There was some discussion at the lunch BOF last week about the  
>>> utility
>>> of refuse.
>>
>> Cool; wish I coulda been there/participated.  Anyone take minutes?
>> (edit: I just heard that Alexey has notes he may share.)
>
> The Jabber log is here:
>
> <http://www.xmpp.org/ietf-logs/[email-masked]/2004-08-04.txt>
>
> I will also attempt to write up a brief summary and post to the list  
> in the next day or so.
>
>>> There was general consensus among the participants that it would be
>>> better to extend reject to allow for SMTP refusal and DSN generation
>>> rather than add a new command. Personally I prefer that approach -  
>>> but
>>> the issue needs more discussion on the list.
>>>
>>> We've probably been over this before, but can you explain in detail
>>> why you think a new command is better than extending the behaviour of
>>> reject?
>>
>> So the idea is just a syntax change, yes?
>
> A syntax change and also a relaxation of the requirement that 'reject'  
> must generate an MDN. i.e. if 'reject' occurs in an  implementation  
> that runs SIEVE during SMTP then that implementation is allowed to do  
> either an SMTP error code, DSN or MDN as it feels appropriate. The  
> 'reject' text specified by the user would be used for DSN or MDN text,  
> and we would add a new optional parameter for the SMTP error code and  
> descriptive error text.

I'm sorry I missed the discussion, as perhaps the issues I will repeat  
below have been
already discussed.

If done as a relaxation of "reject", then one will need to be able to  
handle the DNS and MDN cases differently due to the issue of character  
sets and non-ASCII text in the reason text.

The SMTP text has to be ASCII only.  The MDN text can potentially  
contain non-ASCII text.

Being able to provide a reason in their "own" language (a language that  
needs a non-ASCII
charset for proper representation) is very important to some users.   I  
can hardly stress
enough how important this is to some users and user communities!

So either: (1) A "relaxed" reject action would need another parameter  
specifying whether
SMTP level rejection vs. later MDN should be performed, and then the  
value of that
parameter would need to affect what sorts of characters are allowed in  
the reason string, or
else (2) A "relaxed" reject action would need two parameters, one being  
the SMTP rejection
text (ASCII only) and a second parameter would be the MDN text which  
would allow
non-ASCII text.   Or maybe some third approach  I haven't thought of,  
as long as it allows
non-ASCII text when non-ASCII text is legal, and uses ASCII text when  
ASCII text is required.

To me, such approaches, complicating the reason text in a single action  
("relaxed"
reject) seems uglier than adding a new action refuse that does the SMTP  
rejection case and
leaving reject alone as the MDN rejection case.  And I think that the  
necessity for scripts
to be aware of the difference between SMTP rejection and MDN rejection  
means that
they might as well be coded with different actions -- I think that  
there is no real simplicity
benefit to using a single action.

>> What's the gist of the argument for the change? I can't think of any
>> strong arguments against the change; here are some less strong  
>> arguments:
>
>> 1)A normal extension (the current 'refuse') is a cleaner  
>> implementation
>> in the sense that it's a standard extension - something that's well
>> understood, instead of something that makes the base Sieve RFC  
>> 'wrong' by
>> changing it.
>
> My argument against a new command is that it makes scripts less  
> portable. By relaxing the restriction on reject the same script can  
> run efficiently on an implementation that runs at SMTP time and one  
> that runs at final delivery/LMTP time. It will also make switching  
> between such implementations easier as scripts will not have to be  
> changed to gain the benefits of SMTP time rejection.

The "portable script" argument only works for sites that are supporting  
English-only (or
at best,  
Western-European-languages-that-can-be-adequately-represented-in-ASCII- 
only)
user communities.

For other sites that are already using reject with MDN text that is not  
ASCII-only, their script
already isn't suitable for SMTP reject time interpretation.  Such sites  
are going to have to
care, in their scripts, about the different requirements for reason  
text for SMTP rejections
vs. MDNs.

Regards,

Kristin

>
> The question is whether there is ever a case where you would care what  
> type of reject behaviour is carried out: SMTP error, DSN or MDN. If  
> there is a requirement to allow users to explicitly state the type of  
> error that can easily be done as a parameter.
>
>> 2)It's already written and debugged.
>
> True, but I don't think switching to 'relaxed' reject would be a  
> significant change. I suspect the integration with SMTP is the biggest  
> issue.
>
>> Arguments for the change:
>> 1)A change won't break anything, according to the URL below.
>>
>> Have we done something like this (e.g. modify an action to accept a
>> special parameter flag) before?
>
> Yes - the copy extension adds a :copy parameter to fileinto and  
> redirect. imapflags also extends fileinto and also keep.
>
>
> -- 
> Cyrus Daboo
>

To: Matthew Elvey <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix 
Date: Tue, 10 Aug 2004 12:23:40 -0700
Sender: [email-masked]

Matthew Elvey <[email-masked]> writes:
...
>Have we done something like this (e.g. modify an action to accept a 
>special parameter flag) before?

RFC 3431 (relational tests) adds the :count and :value match-types.
Even closer is draft-degener-sieve-copy-03.txt, which adds the :copy
parameter to redirect and fileinto.

Philip Guenther

Date: Tue, 10 Aug 2004 15:16:36 -0400
From: Cyrus Daboo <[email-masked]>
To: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Sender: [email-masked]

Hi Matthew,

--On Tuesday, August 10, 2004 11:36 AM -0700 Matthew Elvey 
<[email-masked]> wrote:

>> There was some discussion at the lunch BOF last week about the utility
>> of refuse.
>
> Cool; wish I coulda been there/participated.  Anyone take minutes?
> (edit: I just heard that Alexey has notes he may share.)

The Jabber log is here:

<http://www.xmpp.org/ietf-logs/[email-masked]/2004-08-04.txt>

I will also attempt to write up a brief summary and post to the list in the 
next day or so.

>> There was general consensus among the participants that it would be
>> better to extend reject to allow for SMTP refusal and DSN generation
>> rather than add a new command. Personally I prefer that approach - but
>> the issue needs more discussion on the list.
>>
>> We've probably been over this before, but can you explain in detail
>> why you think a new command is better than extending the behaviour of
>> reject?
>
> So the idea is just a syntax change, yes?

A syntax change and also a relaxation of the requirement that 'reject' must 
generate an MDN. i.e. if 'reject' occurs in an  implementation that runs 
SIEVE during SMTP then that implementation is allowed to do either an SMTP 
error code, DSN or MDN as it feels appropriate. The 'reject' text specified 
by the user would be used for DSN or MDN text, and we would add a new 
optional parameter for the SMTP error code and descriptive error text.

> What's the gist of the argument for the change? I can't think of any
> strong arguments against the change; here are some less strong arguments:

> 1)A normal extension (the current 'refuse') is a cleaner implementation
> in the sense that it's a standard extension - something that's well
> understood, instead of something that makes the base Sieve RFC 'wrong' by
> changing it.

My argument against a new command is that it makes scripts less portable. 
By relaxing the restriction on reject the same script can run efficiently 
on an implementation that runs at SMTP time and one that runs at final 
delivery/LMTP time. It will also make switching between such 
implementations easier as scripts will not have to be changed to gain the 
benefits of SMTP time rejection.

The question is whether there is ever a case where you would care what type 
of reject behaviour is carried out: SMTP error, DSN or MDN. If there is a 
requirement to allow users to explicitly state the type of error that can 
easily be done as a parameter.

> 2)It's already written and debugged.

True, but I don't think switching to 'relaxed' reject would be a 
significant change. I suspect the integration with SMTP is the biggest 
issue.

> Arguments for the change:
> 1)A change won't break anything, according to the URL below.
>
> Have we done something like this (e.g. modify an action to accept a
> special parameter flag) before?

Yes - the copy extension adds a :copy parameter to fileinto and redirect. 
imapflags also extends fileinto and also keep.

-- 
Cyrus Daboo

Date: Tue, 10 Aug 2004 19:22:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Sender: [email-masked]

Cyrus Daboo wrote:

> There was some discussion at the lunch BOF last week about the utility 
> of refuse. There was general consensus among the participants that it 
> would be better to extend reject to allow for SMTP refusal and DSN 
> generation rather than add a new command. Personally I prefer that 
> approach - but the issue needs more discussion on the list.
>
> We've probably been over this before, but can you explain in detail 
> why you think a new command is better than extending the behaviour of 
> reject?

I personally don't care, this is just syntax. I think somebody has 
objected to this before.

Alexey

Date: Tue, 10 Aug 2004 11:36:52 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Sender: [email-masked]

On 8/10/2004 8:13 AM, Cyrus Daboo sent forth electrons to convey:

>
> Hi Matthew,
>
> --On Monday, August 09, 2004 10:46 PM -0700 Matthew Elvey 
> <[email-masked]> wrote:
>
>> 1) Belatedly announcing, in case folks missed it:
>>     http://www1.ietf.org/internet-drafts/draft-elvey-refuse-sieve-02.txt
>>
>>     Last discussion post on 'refuse' was my post on 6/8/04.
>>     I believe 'refuse' is ready for last call.
>
>
> There was some discussion at the lunch BOF last week about the utility 
> of refuse. 

Cool; wish I coulda been there/participated.  Anyone take minutes?   
(edit: I just heard that Alexey has notes he may share.)

> There was general consensus among the participants that it would be 
> better to extend reject to allow for SMTP refusal and DSN generation 
> rather than add a new command. Personally I prefer that approach - but 
> the issue needs more discussion on the list.
>
> We've probably been over this before, but can you explain in detail 
> why you think a new command is better than extending the behaviour of 
> reject?

So the idea is just a syntax change, yes?
What's the gist of the argument for the change? 
I can't think of any strong arguments against the change; here are some 
less strong arguments:
1)A normal extension (the current 'refuse') is a cleaner implementation 
in the sense that it's a standard extension - something that's well 
understood, instead of something that makes the base Sieve RFC 'wrong' 
by changing it. 
2)It's already written and debugged.

Arguments for the change:
1)A change won't break anything, according to the URL below.

Have we done something like this (e.g. modify an action to accept a 
special parameter flag) before?

>
>>
>> 2) http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
>> might make a good addition to http://cyrusoft.com/sieve/.
>
>
> I am planning on several updates to our webpage and will add a link to 
> your page at the same time.

Great.

Date: Tue, 10 Aug 2004 11:13:57 -0400
From: Cyrus Daboo <[email-masked]>
To: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Sender: [email-masked]

Hi Matthew,

--On Monday, August 09, 2004 10:46 PM -0700 Matthew Elvey 
<[email-masked]> wrote:

> 1) Belatedly announcing, in case folks missed it:
>     http://www1.ietf.org/internet-drafts/draft-elvey-refuse-sieve-02.txt
>
>     Last discussion post on 'refuse' was my post on 6/8/04.
>     I believe 'refuse' is ready for last call.

There was some discussion at the lunch BOF last week about the utility of 
refuse. There was general consensus among the participants that it would be 
better to extend reject to allow for SMTP refusal and DSN generation rather 
than add a new command. Personally I prefer that approach - but the issue 
needs more discussion on the list.

We've probably been over this before, but can you explain in detail why you 
think a new command is better than extending the behaviour of reject?

>
> 2) http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
> might make a good addition to http://cyrusoft.com/sieve/.

I am planning on several updates to our webpage and will add a link to your 
page at the same time.

-- 
Cyrus Daboo

Date: Mon, 09 Aug 2004 22:46:40 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Sender: [email-masked]

1) Belatedly announcing, in case folks missed it:
    http://www1.ietf.org/internet-drafts/draft-elvey-refuse-sieve-02.txt

    Last discussion post on 'refuse' was my post on 6/8/04.
    I believe 'refuse' is ready for last call.
=-=-=

2) http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
might make a good addition to http://cyrusoft.com/sieve/.

--
Matthew

Date: Thu, 05 Aug 2004 16:48:46 -0700
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: updated variables draft submitted
Sender: [email-masked]

Hi Kjetil,

--On Friday, August 6, 2004 1:37 AM +0200 Kjetil Torgrim Homme 
<[email-masked]> wrote:

> I just submitted version -03 to the IETF Secretariat.  perhaps I'm the
> only one not subscribed to the i-d announce list, but anyway.  it
> probably takes some time until it's on the official list, so here's a
> link to my copy:
>
>   http://folk.uio.no/kjetilho/draft-homme-sieve-variables-03.txt

Whilst the IETF meeting is in progress, draft announcement do not take 
place, though the drafts themselves are accepted. Announcements should 
start up again on Monday.

-- 
Cyrus Daboo

Date: Thu, 05 Aug 2004 16:48:14 -0700
From: Cyrus Daboo <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Subject: Re: updated variables draft submitted
Sender: [email-masked]

Hi Kjetil,

--On Friday, August 6, 2004 1:37 AM +0200 Kjetil Torgrim Homme 
<[email-masked]> wrote:

> I just submitted version -03 to the IETF Secretariat.  perhaps I'm the
> only one not subscribed to the i-d announce list, but anyway.  it
> probably takes some time until it's on the official list, so here's a
> link to my copy:
>
>   http://folk.uio.no/kjetilho/draft-homme-sieve-variables-03.txt

Whilst the IETF meeting is in progress, draft announcement do not take 
place, though the drafts themselves are accepted. Announcements should 
start up again on Monday.

-- 
Cyrus Daboo

Subject: updated variables draft submitted
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Fri, 06 Aug 2004 01:37:59 +0200
Sender: [email-masked]

I just submitted version -03 to the IETF Secretariat.  perhaps I'm the
only one not subscribed to the i-d announce list, but anyway.  it
probably takes some time until it's on the official list, so here's a
link to my copy:

  http://folk.uio.no/kjetilho/draft-homme-sieve-variables-03.txt

-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 5 Aug 2004 14:52:17 -0400
To: [email-masked]
Cc: Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Subject: Re: Three more comments about the vacation draft
Sender: [email-masked]

On Wed, Aug 04, 2004 at 09:48:56AM -0700, [email-masked] wrote:
> > On Tue, 2004-08-03 at 09:53 -0700, Ned Freed wrote:
> 
> Interesting. I had forgotten about that. I personally have a slight
> preference for "Auto: ", but since this is only a MAY in Keith's draft,
> I could live with either.
> 
> What do other people think?

Our implementation also already uses "Auto: " for auto-generated
responses, as well as adding an Auto-Submitted header, per
draft-moore-auto-email-response .  Also it seems to me that if in
general the sieve community endorses draft-moore-auto-email-response at
all, it should be done consistently.

Is the -06 version of the vacation draft online somewhere, i.e. to
avoid making remarks that have already been made?  Ditto a
non-expired version of the variables draft?

Yours,
-mm-

Date: Thu, 05 Aug 2004 09:05:23 -0700 (PDT)
From: [email-masked]
Subject: Re: variables and relational interaction
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> relational defines to new modifiers for all tests, :value and :count.
> the variables draft has a new test, "string", but it doesn't mention any
> match types explicitly.  the relational RFC defines :value quite
> generally, and I don't think the variables draft needs to the say
> anything about it.  however, the :count match type has its behaviour
> listed for each of the known tests.

>         The COUNT match type first determines the number of the
>         specified entities in the message and does a relational
>         comparison of the number of entities to the values specified in
>         the test expression.

>         [...] The envelope "from" will be 0 if the MAIL FROM is blank,
>         or 1 if MAIL FROM is not blank. [...] In all cases, if more than
>         one field name is specified, the counts for all specified fields
>         are added together to obtain the number for comparison.

> I suggest that the value of :count is 0 if the string is empty (""), and
> 1 if not.

> 	if string :count "eq" :comparator "i;ascii-numeric"
>            ["foo", "bar", ""] "2" {
> 		# the test is always true
> 	}

> probably not very useful, but I think it should be added for
> completeness.  suggested wording, at the end of the section on the
> "string" test:

>         The "relational" extensions adds a match type called ":count".
>         The count of a single string is 0 if it is the empty string, or
>         1 otherwise.  The count of a string list is the sum of the
>         counts of the member strings.

The alternative would be to prohibit :count on string. I have no real
preference either way; as you say it isn't very useful, but it also
isn't hard to implement.

				Ned

Date: Thu, 05 Aug 2004 07:34:20 -0700 (PDT)
From: [email-masked]
Subject: Re: variables extension redux
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> thank you for your feedback, Ned, I've updated my copy of the draft, and
> closed all the open issues.

> I'd like to bring up a new open issue, though:

> 6.  Implementation Limits

>    An implementation of this draft MUST support at least 128 distinct
>    variables.  The supported length of variable names MUST be at least
>    32 characters.  Each variable MUST be able to hold at least 4000
>    characters.  Attempts to set the variable to a value larger than what
>    the implementation supports MUST be treated as an error.

>    Numeric variables ${1} through ${9} MUST be supported.  Referencing
>    higher indices than is supported is a syntax error which MUST be dis-
>    covered at compile-time.  If the string matching a wildcard or a
>    regex group operator exceeds the maximum variable size, the implemen-
>    tation SHOULD truncate it and MUST NOT treat it as an error.

> I'm not entirely happy with this since in a minimal implementaion it
> makes

>    if header :matches "Subject" "*" {
>       set "subject" "I'm gone (was: ${1})";
>    }

> a run-time error whenever Subject is more than 4000 characters long:  $1
> is truncated, but the expanded string is too long.  the result is Sieve
> aborting, and the e-mail is implicitly kept.  if the desired action is a
> redirect, this can be as bad as losing e-mail.

> it *is* possible to code defensively:

>    require ["relational", "variables", "i;ascii-numeric"];

>    if header :matches "Subject" "*" {
>       set "orig_subject" "${1}";
>       set :length "length" "${orig_subject}";
>       if string :value "ge" :comparator "i;ascii-numeric"
>                 "${length}" "3983" {
>          set "orig_subject" "[excessively long Subject]";
>       }
>       set "subject" "I'm gone (was: ${orig_subject})";
>    }

> but clearly this isn't very practical :-).  there is an alternative
> method which is more readable:

>    require ["regex", "variables"];

>    if header :regex "Subject" "(.{,3983})" {
>       set "subject" "I'm gone (was: ${1})";
>    }

> but I'm thinking I specified the wrong behaviour when the limit is
> exceeded in the first place.  it doesn't really solve any problems to
> treat it as an error.  I think simply truncating silently is better.
> users who are worried by this, can code defensively.  such long strings
> are after all quite uncommon, and will probably mostly occur in the
> context of vacation.  a truncated vacation message is better than no
> message at all, IMO.

I agree with your analysis. Truncation is the better option.

				Ned

Subject: variables and relational interaction
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Thu, 05 Aug 2004 16:32:55 +0200
Sender: [email-masked]

relational defines to new modifiers for all tests, :value and :count.
the variables draft has a new test, "string", but it doesn't mention any
match types explicitly.  the relational RFC defines :value quite
generally, and I don't think the variables draft needs to the say
anything about it.  however, the :count match type has its behaviour
listed for each of the known tests.

        The COUNT match type first determines the number of the
        specified entities in the message and does a relational
        comparison of the number of entities to the values specified in
        the test expression.

        [...] The envelope "from" will be 0 if the MAIL FROM is blank,
        or 1 if MAIL FROM is not blank. [...] In all cases, if more than
        one field name is specified, the counts for all specified fields
        are added together to obtain the number for comparison.

I suggest that the value of :count is 0 if the string is empty (""), and
1 if not.

	if string :count "eq" :comparator "i;ascii-numeric"
           ["foo", "bar", ""] "2" {
		# the test is always true
	}

probably not very useful, but I think it should be added for
completeness.  suggested wording, at the end of the section on the
"string" test:

        The "relational" extensions adds a match type called ":count".
        The count of a single string is 0 if it is the empty string, or
        1 otherwise.  The count of a string list is the sum of the
        counts of the member strings.

-- 
Kjetil T.

Subject: Re: variables extension redux
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Thu, 05 Aug 2004 16:04:06 +0200
Sender: [email-masked]

thank you for your feedback, Ned, I've updated my copy of the draft, and
closed all the open issues.

I'd like to bring up a new open issue, though:

6.  Implementation Limits

   An implementation of this draft MUST support at least 128 distinct
   variables.  The supported length of variable names MUST be at least
   32 characters.  Each variable MUST be able to hold at least 4000
   characters.  Attempts to set the variable to a value larger than what
   the implementation supports MUST be treated as an error.

   Numeric variables ${1} through ${9} MUST be supported.  Referencing
   higher indices than is supported is a syntax error which MUST be dis-
   covered at compile-time.  If the string matching a wildcard or a
   regex group operator exceeds the maximum variable size, the implemen-
   tation SHOULD truncate it and MUST NOT treat it as an error.

I'm not entirely happy with this since in a minimal implementaion it
makes

   if header :matches "Subject" "*" {
      set "subject" "I'm gone (was: ${1})";
   }

a run-time error whenever Subject is more than 4000 characters long:  $1
is truncated, but the expanded string is too long.  the result is Sieve
aborting, and the e-mail is implicitly kept.  if the desired action is a
redirect, this can be as bad as losing e-mail.

it *is* possible to code defensively:

   require ["relational", "variables", "i;ascii-numeric"];

   if header :matches "Subject" "*" {
      set "orig_subject" "${1}";
      set :length "length" "${orig_subject}";
      if string :value "ge" :comparator "i;ascii-numeric"
                "${length}" "3983" {
         set "orig_subject" "[excessively long Subject]";
      }
      set "subject" "I'm gone (was: ${orig_subject})";
   }

but clearly this isn't very practical :-).  there is an alternative
method which is more readable:

   require ["regex", "variables"];

   if header :regex "Subject" "(.{,3983})" {
      set "subject" "I'm gone (was: ${1})";
   }

but I'm thinking I specified the wrong behaviour when the limit is
exceeded in the first place.  it doesn't really solve any problems to
treat it as an error.  I think simply truncating silently is better.
users who are worried by this, can code defensively.  such long strings
are after all quite uncommon, and will probably mostly occur in the
context of vacation.  a truncated vacation message is better than no
message at all, IMO.
-- 
Kjetil T.

To: [email-masked]
Subject: Re: Three more comments about the vacation draft
From: Michael Haardt <[email-masked]>
Date: Thu, 05 Aug 2004 13:25:35 +0200
Sender: [email-masked]

> Interesting. I had forgotten about that. I personally have a slight
> preference for "Auto: ", but since this is only a MAY in Keith's draft,
> I could live with either.
>
> What do other people think?

I like "Auto: ", too.

Concerning my recent question regarding the response rate limiting,
the draft says:

     Vacation responses are not just per address, but are per address
     per vacation command.

After some discussion, I suggest now:

     Vacation responses are not just per address, but are per address
     per reason string and per specified subject and ":mime" option.

Using the ":mime" option is for correctness.

Michael

Date: Wed, 04 Aug 2004 19:45:33 +0100
From: Alexey Melnikov <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Sieve lunch
Sender: [email-masked]

Where are you people? I've lost you.

Date: Wed, 04 Aug 2004 13:19:59 -0400
From: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: Three more comments about the vacation draft
Sender: [email-masked]

I like Auto:.

	Tony Hansen
	[email-masked]

[email-masked] wrote:

> Interesting. I had forgotten about that. I personally have a slight
> preference for "Auto: ", but since this is only a MAY in Keith's draft,
> I could live with either.

Date: Wed, 04 Aug 2004 09:48:56 -0700 (PDT)
From: [email-masked]
Subject: Re: Three more comments about the vacation draft
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> On Tue, 2004-08-03 at 09:53 -0700, Ned Freed wrote:
> > > The default subject is "Re: " followed by the subject with stripped
> > > "Re: " strings.  Is the latter to be taken literally, as "Re: " or
> > > does it mean "[rR][eE]:*" (case insensitive with zero or more spaces
> > > following)?
> >
> > RFC 2822 limits this to the literal string "Re: " and suggests that no other
> > forms be used. IMO this is the right course; any other course opens cans of
> > worms best left unopened.

> Keith Moore's draft suggests "Auto: "?

> in our vacation feature, we use

>    Subject: Auto: I'm away from my mail (was: SUBJECT )

> "(was: ...)" is one of those small things which should've been
> standardised.  Gnus will ask the user if the "(was: ...)" should be
> removed from Subject when replying.
> --
> Kjetil T.

Interesting. I had forgotten about that. I personally have a slight
preference for "Auto: ", but since this is only a MAY in Keith's draft,
I could live with either.

What do other people think?

				Ned

Date: Wed, 04 Aug 2004 08:50:20 -0700 (PDT)
From: [email-masked]
Subject: Re: variables extension redux
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> On tir, 2004-08-03 at 10:51 -0700, [email-masked] wrote:
> > > d)   the EDITHEADER draft includes an action that needs the unexpanded
> > >      string to be passed to the procedure, since the action first per-
> > >      forms matching which may influence numeric variable references in
> > >      the argument.  this is can be seen as a layering violation, and the
> > >      variable draft should state explicitly whether such extensions are
> > >      possible.
> >
> > Vacation also needs access to the unexpanded strings for its internal hash
> > computations. This means that implementations need to allow for argument
> > evaluation to be done in two steps, first get the argument, then expand it.
> > Given that you have to allow for this anyway I don't see a problem with letting
> > future extensions do this sort of thing explicitly.

> "vacation" is a good example.  perhaps a implementor's hint is off-topic
> for the draft, but I suggest adding this to the end of 3 (just after the
> next excerpt), before 3.1.

>         Tests or actions in future extensions may want to access the
>         unexpanded version of the string argument and do the expansion
>         after, e.g., setting variables in its namespace.  The design of
>         the implementation should allow this.

> or more tersely:

>         Future extensions may require access to the unexpanded version
>         of the string argument.

> (it's a given the implementation provides an internal function for
> expanding a string...)

I prefer the wordier of these two.

> > Banning variable substitutions in body parameters may also be something
> > implementations want to do, but this is a somewhat different issue.

> right, there is already this wording:

>         Strings where no variable substitutions take place are referred
>         to as constant strings.  Future extensions may specify that
>         passing non-constant strings as arguments to its actions or
>         tests is an error.

> > > [SETMATCH]
> >
> > This would be easy for me to implement but I really don't care for it. In
> > particular, I find
> >
> >      setmatch ["", "", "", "foo"];
> >
> > to be pretty awful.
> >
> > I'd feel differently if this actually solved the value changing problem during
> > compound tests, but it doesn't.

> okay, I'll kill the issue and stick to numeric variables unless someone
> else weighs in.

> > >      a related question is what happens when a match fails.  the draft
> > >      currently says that the numeric variables are reset, but this may
> > >      be inconvenient.
> >
> > I'd prefer to have the values remain unchanged, but I can live with it
> > either way.

> I'm currently favouring the same, mostly due to precedence of this
> behaviour in Perl.

Yes, good point.

> I note that Sendmail claims to have implemented
> "variables" already, and this is one of those small things which can
> bite script writers if we change it around, although I think most
> scripts will be straightforward and use a "SET" immediately after the ":
> matches".  My conclusion is that we can do the change.

FWIW, we have also implemented variables in our product, but we haven't
documented its availability yet and you have to enable it. Nor does our GUI
sieve interface generate sieves that depend on it (yet). We may be forceed to
change this in the not-so-distant future, however, since customer calls for the
functionality variables gives them are pretty common.

				Ned

Date: Wed, 04 Aug 2004 08:47:36 -0700 (PDT)
From: [email-masked]
Subject: Re: Three more comments about the vacation draft
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > > I just noticed that the vacation draft 05 does not specify the
> > > envelope sender, just the recipient.  I suggest to quote the
> > > paragraph from draft-moore-auto-email-response and to refer
> > > to it.
> >
> > I believe this has already been addressed in Tim's -06 revision.

> Good.

> > >      Vacation responses are not just per address, but are per address
> > >      per reason string.
> >
> > If explicitly specified the subject should also be included in this.

> That makes sense, so how about this?

>      Vacation responses are not just per address, but are per address
>      per reason string and per subject, if it is explicitly specified.

Something along these lines seems fine to me.

> > RFC 2822 limits this to the literal string "Re: " and suggests that no other
> > forms be used. IMO this is the right course; any other course opens cans of
> > worms best left unopened.

> I agree, but asked, because I am used to software talking about "Re: ",
> but in fact matching a regular expression.

> I would appreciate if the draft would state explictly that the /literal/
> string "Re: " is stripped.

Sounds fine as well.

				Ned

To: [email-masked]
Subject: Re: Three more comments about the vacation draft
From: Michael Haardt <[email-masked]>
Date: Wed, 04 Aug 2004 11:41:24 +0200
Sender: [email-masked]

> > I just noticed that the vacation draft 05 does not specify the
> > envelope sender, just the recipient.  I suggest to quote the
> > paragraph from draft-moore-auto-email-response and to refer
> > to it.
>
> I believe this has already been addressed in Tim's -06 revision.

Good.

> >      Vacation responses are not just per address, but are per address
> >      per reason string.
>
> If explicitly specified the subject should also be included in this.

That makes sense, so how about this?

     Vacation responses are not just per address, but are per address
     per reason string and per subject, if it is explicitly specified.

> RFC 2822 limits this to the literal string "Re: " and suggests that no other
> forms be used. IMO this is the right course; any other course opens cans of
> worms best left unopened.

I agree, but asked, because I am used to software talking about "Re: ",
but in fact matching a regular expression.

I would appreciate if the draft would state explictly that the /literal/
string "Re: " is stripped.

Michael

Subject: Re: variables extension redux
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 04 Aug 2004 10:13:36 +0200
Sender: [email-masked]

On tir, 2004-08-03 at 10:51 -0700, [email-masked] wrote:
> > d)   the EDITHEADER draft includes an action that needs the unexpanded
> >      string to be passed to the procedure, since the action first per-
> >      forms matching which may influence numeric variable references in
> >      the argument.  this is can be seen as a layering violation, and the
> >      variable draft should state explicitly whether such extensions are
> >      possible.
> 
> Vacation also needs access to the unexpanded strings for its internal hash
> computations. This means that implementations need to allow for argument
> evaluation to be done in two steps, first get the argument, then expand it.
> Given that you have to allow for this anyway I don't see a problem with letting
> future extensions do this sort of thing explicitly.

"vacation" is a good example.  perhaps a implementor's hint is off-topic
for the draft, but I suggest adding this to the end of 3 (just after the
next excerpt), before 3.1.

        Tests or actions in future extensions may want to access the
        unexpanded version of the string argument and do the expansion
        after, e.g., setting variables in its namespace.  The design of
        the implementation should allow this.

or more tersely:

        Future extensions may require access to the unexpanded version
        of the string argument.

(it's a given the implementation provides an internal function for
expanding a string...)

> Banning variable substitutions in body parameters may also be something
> implementations want to do, but this is a somewhat different issue.

right, there is already this wording:

        Strings where no variable substitutions take place are referred
        to as constant strings.  Future extensions may specify that
        passing non-constant strings as arguments to its actions or
        tests is an error.

> > [SETMATCH]
>
> This would be easy for me to implement but I really don't care for it. In
> particular, I find
> 
>      setmatch ["", "", "", "foo"];
> 
> to be pretty awful.
> 
> I'd feel differently if this actually solved the value changing problem during
> compound tests, but it doesn't.

okay, I'll kill the issue and stick to numeric variables unless someone
else weighs in.

> >      a related question is what happens when a match fails.  the draft
> >      currently says that the numeric variables are reset, but this may
> >      be inconvenient.
> 
> I'd prefer to have the values remain unchanged, but I can live with it
> either way.

I'm currently favouring the same, mostly due to precedence of this
behaviour in Perl.  I note that Sendmail claims to have implemented
"variables" already, and this is one of those small things which can
bite script writers if we change it around, although I think most
scripts will be straightforward and use a "SET" immediately after the ":
matches".  My conclusion is that we can do the change.

-- 
Kjetil T.

Date: Tue, 03 Aug 2004 17:22:05 -0700
From: Cyrus Daboo <[email-masked]>
To: Tony Hansen <[email-masked]>
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: Lunch-BOF reminder
Sender: [email-masked]

Hi Tony,

--On Tuesday, August 3, 2004 8:11 PM -0400 Tony Hansen <[email-masked]> wrote:

> Shouldn't that be 11:30 am? The lunch break is only from 11:30 am to 1:00
> pm.
>

Sorry you're right - we will meet at 11.30 am PST.

-- 
Cyrus Daboo

Date: Tue, 03 Aug 2004 20:11:45 -0400
From: Tony Hansen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: Lunch-BOF reminder
Sender: [email-masked]

Shouldn't that be 11:30 am? The lunch break is only from 11:30 am to 
1:00 pm.

	Tony Hansen
	[email-masked]

Cyrus Daboo wrote:

> 
> Just a reminder of the lunch-BOF for tomorrow (Wednesday). I suggest we 
> meet at the IETF registration desk area at 12:30 pm and find a suitable 
> location (with wireless support for jabber) from there.
> 
> For remote participants:
> 
> The Jabber room is [email-masked]
> 
> We are on Pacific Standard Time (-0700) here in San Diego.
> 

Date: Tue, 03 Aug 2004 17:04:45 -0700
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Lunch-BOF reminder
Sender: [email-masked]

Just a reminder of the lunch-BOF for tomorrow (Wednesday). I suggest we 
meet at the IETF registration desk area at 12:30 pm and find a suitable 
location (with wireless support for jabber) from there.

For remote participants:

The Jabber room is [email-masked]

We are on Pacific Standard Time (-0700) here in San Diego.

-- 
Cyrus Daboo

Subject: Re: Three more comments about the vacation draft
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 03 Aug 2004 21:07:22 +0200
Sender: [email-masked]

On Tue, 2004-08-03 at 09:53 -0700, Ned Freed wrote:
> > The default subject is "Re: " followed by the subject with stripped
> > "Re: " strings.  Is the latter to be taken literally, as "Re: " or
> > does it mean "[rR][eE]:*" (case insensitive with zero or more spaces
> > following)?
> 
> RFC 2822 limits this to the literal string "Re: " and suggests that no other
> forms be used. IMO this is the right course; any other course opens cans of
> worms best left unopened.

Keith Moore's draft suggests "Auto: "?

in our vacation feature, we use

   Subject: Auto: I'm away from my mail (was: SUBJECT )

"(was: ...)" is one of those small things which should've been
standardised.  Gnus will ask the user if the "(was: ...)" should be
removed from Subject when replying.
-- 
Kjetil T.

Date: Tue, 03 Aug 2004 10:51:47 -0700 (PDT)
From: [email-masked]
Subject: Re: variables extension redux
To: Kjetil Torgrim Homme <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

> On fre, 2004-07-30 at 16:31 +0100, Alexey Melnikov wrote:
> > If this helps to get Sieve variables published (I am being selfish here,
> > of course :-)), than I agree.

> I'm sorry, but I've lost track.  what should be done about it?  there
> are some open issues in it, but they don't seem very hard problems,
> really.  I apologise if I have left out criticisms, it is not
> intentional, my memory isn't so good.

> === excerpt ===
> 0.3.  Open Issues

> b)   this extension is particularily useful if fileinto creates new
>      folders on demand.  [SIEVE] doesn't prohibit this, and currently
>      some implementations will create new folders automatically, others
>      won't.

> [out of scope, an explicit :createfolder for fileinto should be a
> separate extension.  this can be closed.]

Agreed.

> d)   the EDITHEADER draft includes an action that needs the unexpanded
>      string to be passed to the procedure, since the action first per-
>      forms matching which may influence numeric variable references in
>      the argument.  this is can be seen as a layering violation, and the
>      variable draft should state explicitly whether such extensions are
>      possible.

Vacation also needs access to the unexpanded strings for its internal hash
computations. This means that implementations need to allow for argument
evaluation to be done in two steps, first get the argument, then expand it.
Given that you have to allow for this anyway I don't see a problem with letting
future extensions do this sort of thing explicitly.

Banning variable substitutions in body parameters may also be something
implementations want to do, but this is a somewhat different issue.

> e)   the numeric variables are causing many headaches since they may
>      change spontaneously when running tests or even _during_ actions.

I don't see this as causing real problems in practice. If you need reliable
access to these variables you need to code your tests and actions accordingly.

>      an alternative approach is SETMATCH ["var1", "var2", "var3"] which
>      stores the first three match components into the listed variables.
>      (an empty string as a variable name means skip storing that match.)
>      this approach makes REPLACEHEADER less powerful.

> [this is a big change to the draft, but I think it makes the semantics
> clearer and reduces the chances of pitfalls.  the REPLACEHEADER magic
> was too magic, IMHO (it was removed from the draft anyway, but someone
> else may want something similar in the future)]

This would be easy for me to implement but I really don't care for it. In
particular, I find

     setmatch ["", "", "", "foo"];

to be pretty awful.

I'd feel differently if this actually solved the value changing problem during
compound tests, but it doesn't.

>      a related question is what happens when a match fails.  the draft
>      currently says that the numeric variables are reset, but this may
>      be inconvenient.

I'd prefer to have the values remain unchanged, but I can live with it
either way.

				Ned

Date: Tue, 03 Aug 2004 10:37:53 -0700 (PDT)
From: [email-masked]
Subject: Re: Three more comments about the vacation draft
To: [email-masked]
Cc: Michael Haardt <[email-masked]>, [email-masked]
Sender: [email-masked]

> > The following sentence made me wonder the first time I read it,
> > and it is probably not meant that way:

> >      Vacation responses are not just per address, but are per address
> >      per vacation command.

> > How about:

> >      Vacation responses are not just per address, but are per address
> >      per reason string.

> If explicitly specified the subject should also be included in this.

Another point we should make is that the hash needs to be computed on the
strings before variable substitution has taken place. This introduces a
reference to the variables draft, but I believe it is informative, not
normative.

				Ned

Date: Tue, 03 Aug 2004 09:53:53 -0700 (PDT)
From: [email-masked]
Subject: Re: Three more comments about the vacation draft
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I just noticed that the vacation draft 05 does not specify the
> envelope sender, just the recipient.  I suggest to quote the
> paragraph from draft-moore-auto-email-response and to refer
> to it.

I believe this has already been addressed in Tim's -06 revision.

> The following sentence made me wonder the first time I read it,
> and it is probably not meant that way:

>      Vacation responses are not just per address, but are per address
>      per vacation command.

> How about:

>      Vacation responses are not just per address, but are per address
>      per reason string.

If explicitly specified the subject should also be included in this.

> The rest of the document talks about it that way.  Otherwise, the
> Sieve implementation had to put an attribute to each command, e.g.
> a sequence number.

> The default subject is "Re: " followed by the subject with stripped
> "Re: " strings.  Is the latter to be taken literally, as "Re: " or
> does it mean "[rR][eE]:*" (case insensitive with zero or more spaces
> following)?

RFC 2822 limits this to the literal string "Re: " and suggests that no other
forms be used. IMO this is the right course; any other course opens cans of
worms best left unopened.

				Ned

Date: Tue, 3 Aug 2004 17:00:44 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Three more comments about the vacation draft
Sender: [email-masked]

I just noticed that the vacation draft 05 does not specify the
envelope sender, just the recipient.  I suggest to quote the
paragraph from draft-moore-auto-email-response and to refer
to it.

The following sentence made me wonder the first time I read it,
and it is probably not meant that way:

     Vacation responses are not just per address, but are per address
     per vacation command.

How about:

     Vacation responses are not just per address, but are per address
     per reason string.

The rest of the document talks about it that way.  Otherwise, the
Sieve implementation had to put an attribute to each command, e.g.
a sequence number.

The default subject is "Re: " followed by the subject with stripped
"Re: " strings.  Is the latter to be taken literally, as "Re: " or
does it mean "[rR][eE]:*" (case insensitive with zero or more spaces
following)?

Sorry about all these mails, but when I am done, the next person
doing a clean room implementation will ask less. :)

Michael

To: [email-masked]
Subject: Re: Vacation draft
From: Michael Haardt <[email-masked]>
Date: Tue, 03 Aug 2004 12:46:16 +0200
Sender: [email-masked]

> I know this because I originally tried not to have this in our implementation
> for the reasons you have given. The  result was I got my butt kicked, not once
> but many times.

Interesting! I got absolutely no negative feedback here at all.

> While I guess I could live with the *sieve* default being to use a fixed
> subject, all that will mean for us is that the sieves our UI generates will
> build sieve code to override this  default.

And it would require variables to reach the same functionality, plus
code to strip the "Re: ".  A hack like ":resubject" could solve that,
but it is ugly.

> The reality is that perceived need to incorporate the original subject into the
> new one overwhelms the perceived risk of this being used for negarious
> purposes.

That may well be.  I don't like riskful defaults, that's all.  Since
few people ever write Sieve scripts on their own, it is not as bad,
though.  GUI authors hopefully read the draft/RFC, so they know what
they are doing.

Michael

To: [email-masked]
Subject: Re: Vacation draft
From: Michael Haardt <[email-masked]>
Date: Tue, 03 Aug 2004 12:37:08 +0200
Sender: [email-masked]

> Why would they bother claiming opt-in?  It wouldn't be worth exposing 
> their SMTP servers to obvious attack; most people do not have a vacation 
> command in place most of the time; and it's easier to just lie big 
> instead of lie small.

Don't ask me about a spammers thinking.  I see all kinds of odd behaviour
that makes no sense to me, including obviously made up excuses and
threats against sueing for blocking their "legitimate" mail.

This time of the year, there is a good chance to hit vacation
auto-responders.  Ask mailing list admins about that issue, but duck
fast. ;-)

> I added verbage stating not to reply to Auto-submitted messages (wasn't 
> there, I was surprised), so in any case, there's an obvious fix for 
> mailing list managers that aren't covered by List-* headers, owner-*, 
> *-request, etc.

Good.  Will the new version also contain a warning about the risk of
responding with the old subject?  Since ":subject" already allows to
change it to a fixed subject, everybody can decide between the risk
and losing the context.

Michael

Date: Mon, 02 Aug 2004 13:55:02 -0700
From: Tim Showalter <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Vacation draft
Sender: [email-masked]

Michael Haardt wrote:
>>This is obviously a problem, but the fix is not quite obvious.  The 
>>obvious thing to do is to change the subject to whatever, but that's not 
>>clearly the right thing to do, because it loses context of the original 
>>message.  We could specify that this happens unless a List-* header is 
>>present or unless Auto-Submitted is not present or set to no (I have no 
>>idea if this header was ever documented).
> 
> 
> Neither would stop spammers saying: "We use opt-in with address
> verification, and you did verify your subscription request".  They won't
> be stupid enough to make their newsletter system look like a regular
> mailing list, because they *want* vacation responses to be sent in order
> to gain subscribers.

Why would they bother claiming opt-in?  It wouldn't be worth exposing 
their SMTP servers to obvious attack; most people do not have a vacation 
command in place most of the time; and it's easier to just lie big 
instead of lie small.

I think you guys have already hashed out the court arguments on this, 
but I'll note that if it's going to go to the courts, we have to assume 
that they have some common sense; if we can't do that, then we can't 
rely on the courts to make those decisions, and perhaps vacation just 
can't be used at all.

I added verbage stating not to reply to Auto-submitted messages (wasn't 
there, I was surprised), so in any case, there's an obvious fix for 
mailing list managers that aren't covered by List-* headers, owner-*, 
*-request, etc.

I will re-publish the draft tonight.

Tim

Date: Mon, 02 Aug 2004 10:05:50 -0700 (PDT)
From: [email-masked]
Subject: Re: Specification of ":mime" in vacation extension
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> when using ":mime", CMU Sieve 2.3 uses the MIME header and body
> to build a message with Content-Type multipart/mixed, the only
> part being the reason string.

This seems like one possible way to do it. Another way would be to construct a
message containing a single MIME part specified in the reason string, without
putting it in a multipart/mixed.

> The vacation draft refers to RFC 3028, which in turn does not
> specify how such mails are composed.

Perhaps not in the sense of what's done with the part, but the specification
certainly defines what goes in the reason string.

> Do other implementations work the same way?

Our implementation doesn't use a multipart/mixed wrapper. It simply treats
the content as a MIME entity and wraps it inside of a message.

> What's the reason
> behind not adding the MIME header to the message header, thus
> giving the script writer full control over the message?

So that things besides text/plain; charset=utf-8 can be returned.

> The
> current specification (or lack thereof) would allow doing so.

It is supposed to.

				Ned

Date: Mon, 02 Aug 2004 09:36:02 -0700 (PDT)
From: [email-masked]
Subject: Re: Vacation draft
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > > First of all, users will be annoyed by being subscribed to a list, and
> > > be very annoyed if subscribed to multiple lists.  Vacation MUST contain
> > > heuristics to lock out mailing lists and their owner/request addresses,
> > > but there is no safe way to detect them.  Subscribing typical users to
> > > old-style lists without web interface causes them grief to no end and
> > > there are enough idiots around having fun doing so.
> >
> > there are plenty of lists which don't require confirmation messages,
> > either.  Sieve can't fix these.  if there are lists which don't do
> > proper checks to see if the confirmation checks are automatically
> > submitted, Sieve can't fix these either.

> When it comes to not using "Re: $subject" for not replying with a sent
> secret key, Sieve can fix the problem. :)

> Personally, I use a fixed subject to address this problem.  With a large
> number of users, I don't think I have a choice.

I also have a large number of users, and I also don't have a choice - I either
offer the ability to use a subject of the form "Re: <origina>" or people won't
use the mechanism.

I know this because I originally tried not to have this in our implementation
for the reasons you have given. The  result was I got my butt kicked, not once
but many times.

While I guess I could live with the *sieve* default being to use a fixed
subject, all that will mean for us is that the sieves our UI generates will
build sieve code to override this  default.

The reality is that perceived need to incorporate the original subject into the
new one overwhelms the perceived risk of this being used for negarious
purposes. (I cannot and will not speak to the actual need and actual risk since
I have no good way to assess either one.)

> I see Tim's point in
> that it loses context (something I am not afraid of) and it is certainly
> unexpected for users that know autoresponders.

I note that this may be a cultural issue.

> If the majority on the list does not think that the default subject
> should be changed to a fixed string, it would be fine with me to add
> this topic under the section "security considerations".

I agree that it definitely needs to be discussed.

				Ned

Date: Mon, 02 Aug 2004 07:56:28 -0700 (PDT)
From: [email-masked]
Subject: Re: Vacation draft
To: Kjetil Torgrim Homme <[email-masked]>
Cc: Michael Haardt <[email-masked]>, [email-masked]
Sender: [email-masked]

> (please include References or In-Reply-To in your messages, every new
> message from you creates a new thread, which is inconvenient.)

> On Mon, 2004-08-02 at 14:26 +0200, Michael Haardt wrote:
> > > you have too little faith in the common sense of judges.  a spammer
> > > claiming that a vacation message or a bounce (both should have "MAIL
> > > FROM:<>") is opting-in would be laughed out of court.
> >
> > I have pretty much no faith at all in the common sense of judges when
> > it comes to technical issues indeed, and good reasons for doing so.
> > It may be a German issue, but I doubt it.  I could imagine very well that
> > a spammer using vacation based opt-in does not get in serious trouble
> > for a year or even longer over here.  Hell, even without that he may
> > not get any trouble.  All you can do is subscribing his administrative
> > addresses to his own list, among others. :-( But that's another point.

> yes, I don't think fixing the German judiciary system is practically
> possible for Sieve :-)

Or the American, for that matter. (Which one is more deeply broken is
a good topic for a bar-BOF...)

> > First of all, users will be annoyed by being subscribed to a list, and
> > be very annoyed if subscribed to multiple lists.  Vacation MUST contain
> > heuristics to lock out mailing lists and their owner/request addresses,
> > but there is no safe way to detect them.  Subscribing typical users to
> > old-style lists without web interface causes them grief to no end and
> > there are enough idiots around having fun doing so.

> there are plenty of lists which don't require confirmation messages,
> either.  Sieve can't fix these.  if there are lists which don't do
> proper checks to see if the confirmation checks are automatically
> submitted, Sieve can't fix these either.

Exactly. Additionally, we have a set of rules autoresponders are supposed
to follow; these are laid out in draft-moore-auto-email-response-05.txt.
This document was approved some time back as a proposed standard RFC; IMO
we need to make sure we're aligned with it (and reference it) but going
beyond it is unnecessary.

Auto-submitted is defined in this document, BTW.

> the vacation extension should leverage whatever mechanisms other RFCs
> specify for recognising automatically submitted messages.  this includes
> RFC 2919 (List-Id) and RFC 2369 (List-Help etc.), but not heuristics
> like "if the local part of the sender address starts with 'owner-' or
> ends in '-owner'".  making such heuristics standard is work for a
> different group, IMHO.

draft-moore-auto-email-response-05.txt specifically allows such checks, both in
the form of sender and message content checks. I also note that vacation can be
combined with spamtest/virustest.

				Ned

To: [email-masked]
Subject: Re: Vacation draft
From: Michael Haardt <[email-masked]>
Date: Mon, 02 Aug 2004 17:02:01 +0200
Sender: [email-masked]

> > First of all, users will be annoyed by being subscribed to a list, and
> > be very annoyed if subscribed to multiple lists.  Vacation MUST contain
> > heuristics to lock out mailing lists and their owner/request addresses,
> > but there is no safe way to detect them.  Subscribing typical users to
> > old-style lists without web interface causes them grief to no end and
> > there are enough idiots around having fun doing so.
>
> there are plenty of lists which don't require confirmation messages,
> either.  Sieve can't fix these.  if there are lists which don't do
> proper checks to see if the confirmation checks are automatically
> submitted, Sieve can't fix these either.

When it comes to not using "Re: $subject" for not replying with a sent
secret key, Sieve can fix the problem. :)

Personally, I use a fixed subject to address this problem.  With a large
number of users, I don't think I have a choice.  I see Tim's point in
that it loses context (something I am not afraid of) and it is certainly
unexpected for users that know autoresponders.

If the majority on the list does not think that the default subject
should be changed to a fixed string, it would be fine with me to add
this topic under the section "security considerations".

> the vacation extension should leverage whatever mechanisms other RFCs
> specify for recognising automatically submitted messages.  this includes
> RFC 2919 (List-Id) and RFC 2369 (List-Help etc.), but not heuristics
> like "if the local part of the sender address starts with 'owner-' or
> ends in '-owner'".  making such heuristics standard is work for a
> different group, IMHO.

Apart from "List-", draft 05 (I didn't find 06) says:

     Implementations are encouraged, however, to include well-known
     addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
     addresses typically used only by automated systems.  Additionally,
     addresses ending in "-request" or beginning in "owner-", i.e.,
     reserved for mailing list software, are also suggested.

That's heuristics to me.  Is this different in draft 06? I would
appreciate if it still contained this, because it specifies current best
practice, at least part of it (listmaster, Precedence: bulk|junk|list
are not listed).  It does not give people a choice to get this wrong
and the more Sieve is used, the less broken vacation mails will be sent.

Michael

Subject: Re: Vacation draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Mon, 02 Aug 2004 15:37:24 +0200
Sender: [email-masked]

(please include References or In-Reply-To in your messages, every new
message from you creates a new thread, which is inconvenient.)

On Mon, 2004-08-02 at 14:26 +0200, Michael Haardt wrote:
> > you have too little faith in the common sense of judges.  a spammer
> > claiming that a vacation message or a bounce (both should have "MAIL
> > FROM:<>") is opting-in would be laughed out of court.
> 
> I have pretty much no faith at all in the common sense of judges when
> it comes to technical issues indeed, and good reasons for doing so.
> It may be a German issue, but I doubt it.  I could imagine very well that
> a spammer using vacation based opt-in does not get in serious trouble
> for a year or even longer over here.  Hell, even without that he may
> not get any trouble.  All you can do is subscribing his administrative
> addresses to his own list, among others. :-( But that's another point.

yes, I don't think fixing the German judiciary system is practically
possible for Sieve :-)

> First of all, users will be annoyed by being subscribed to a list, and
> be very annoyed if subscribed to multiple lists.  Vacation MUST contain
> heuristics to lock out mailing lists and their owner/request addresses,
> but there is no safe way to detect them.  Subscribing typical users to
> old-style lists without web interface causes them grief to no end and
> there are enough idiots around having fun doing so.

there are plenty of lists which don't require confirmation messages,
either.  Sieve can't fix these.  if there are lists which don't do
proper checks to see if the confirmation checks are automatically
submitted, Sieve can't fix these either.

the vacation extension should leverage whatever mechanisms other RFCs
specify for recognising automatically submitted messages.  this includes
RFC 2919 (List-Id) and RFC 2369 (List-Help etc.), but not heuristics
like "if the local part of the sender address starts with 'owner-' or
ends in '-owner'".  making such heuristics standard is work for a
different group, IMHO.
-- 
Kjetil T.

To: [email-masked]
Subject: Re: Vacation draft
From: Michael Haardt <[email-masked]>
Date: Mon, 02 Aug 2004 14:26:31 +0200
Sender: [email-masked]

> you have too little faith in the common sense of judges.  a spammer
> claiming that a vacation message or a bounce (both should have "MAIL
> FROM:<>") is opting-in would be laughed out of court.

I have pretty much no faith at all in the common sense of judges when
it comes to technical issues indeed, and good reasons for doing so.
It may be a German issue, but I doubt it.  I could imagine very well that
a spammer using vacation based opt-in does not get in serious trouble
for a year or even longer over here.  Hell, even without that he may
not get any trouble.  All you can do is subscribing his administrative
addresses to his own list, among others. :-( But that's another point.

First of all, users will be annoyed by being subscribed to a list, and
be very annoyed if subscribed to multiple lists.  Vacation MUST contain
heuristics to lock out mailing lists and their owner/request addresses,
but there is no safe way to detect them.  Subscribing typical users to
old-style lists without web interface causes them grief to no end and
there are enough idiots around having fun doing so.

Michael

Subject: Re: Vacation draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Mon, 02 Aug 2004 14:06:12 +0200
Sender: [email-masked]

On Mon, 2004-08-02 at 13:19 +0200, Michael Haardt wrote:
> > This is obviously a problem, but the fix is not quite obvious.  The 
> > obvious thing to do is to change the subject to whatever, but that's not 
> > clearly the right thing to do, because it loses context of the original 
> > message.  We could specify that this happens unless a List-* header is 
> > present or unless Auto-Submitted is not present or set to no (I have no 
> > idea if this header was ever documented).
> 
> Neither would stop spammers saying: "We use opt-in with address
> verification, and you did verify your subscription request".  They won't
> be stupid enough to make their newsletter system look like a regular
> mailing list, because they *want* vacation responses to be sent in order
> to gain subscribers.

you have too little faith in the common sense of judges.  a spammer
claiming that a vacation message or a bounce (both should have "MAIL
FROM:<>") is opting-in would be laughed out of court.

-- 
Kjetil T.

To: [email-masked]
Subject: Specification of ":mime" in vacation extension
From: Michael Haardt <[email-masked]>
Date: Mon, 02 Aug 2004 13:26:17 +0200
Sender: [email-masked]

Hello,

when using ":mime", CMU Sieve 2.3 uses the MIME header and body
to build a message with Content-Type multipart/mixed, the only
part being the reason string.

The vacation draft refers to RFC 3028, which in turn does not
specify how such mails are composed.

Do other implementations work the same way? What's the reason
behind not adding the MIME header to the message header, thus
giving the script writer full control over the message? The
current specification (or lack thereof) would allow doing so.

Michael

To: [email-masked]
Subject: Re: Vacation draft
From: Michael Haardt <[email-masked]>
Date: Mon, 02 Aug 2004 13:19:17 +0200
Sender: [email-masked]

> This is obviously a problem, but the fix is not quite obvious.  The 
> obvious thing to do is to change the subject to whatever, but that's not 
> clearly the right thing to do, because it loses context of the original 
> message.  We could specify that this happens unless a List-* header is 
> present or unless Auto-Submitted is not present or set to no (I have no 
> idea if this header was ever documented).

Neither would stop spammers saying: "We use opt-in with address
verification, and you did verify your subscription request".  They won't
be stupid enough to make their newsletter system look like a regular
mailing list, because they *want* vacation responses to be sent in order
to gain subscribers.

> [database size of vacation message recipients]

> I figure a thousand is enough for a lower limit, but maybe that should 
> be a SHOULD.

1000 would be fine with me, because most people get mail from fewer
addresses within a week, so the average of large systems should be less
by far.

Michael

Date: Sun, 01 Aug 2004 21:14:18 -0700
From: Tim Showalter <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Subject: Re: Vacation draft
Sender: [email-masked]

Michael Haardt wrote:

> I have two comments to the section security considerations:
> 
> Sending out an automated reply with "Re: " and the subject is dangerous.
> Many mailing lists verify the mail address by sending a mail with a key
> in the subject.  Simply replying to such a mail confirms you want to
> subscribe to it.  If people use vacation, it is easy to subscribe them
> to a spam list and prove that it *is* opt-in by keeping the confirmation
> and throwing away the original faked subscription request.

This is obviously a problem, but the fix is not quite obvious.  The 
obvious thing to do is to change the subject to whatever, but that's not 
clearly the right thing to do, because it loses context of the original 
message.  We could specify that this happens unless a List-* header is 
present or unless Auto-Submitted is not present or set to no (I have no 
idea if this header was ever documented).

> Mail systems should be allowed to bypass the time if the database to
> remember senders becomes too large.  I suggest to allow the implementation
> to expire entries if the number of different senders becomes too big.
> The draft could set a minimum database size. Say 100 or 1000 different
> senders must be remembered, but implementations may store more.

I am adding the following text to section 3.2:

Implementations are free to limit the number of remembered responses,
provided the limit is no less than 1000.  Implementations SHOULD make
the limit no less than 1000 per vacation command if using the hash
algorithm described above.

I figure a thousand is enough for a lower limit, but maybe that should 
be a SHOULD.

Tim