new mailing list: [e-mail]

[Martin Duerst <[e-mail]>]

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, [e-mail],
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 [e-mail]
(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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H2DSQ5017949; Mon, 16 Aug 2004 19:13:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7H2DSAR017948; Mon, 16 Aug 2004 19:13:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H2DRXY017941 for <[e-mail]>; Mon, 16 Aug 2004 19:13:27 -0700 (PDT) (envelope-from [e-mail])
Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id A58D84EF75 for <[e-mail]>; Mon, 16 Aug 2004 22:13:31 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040817083100.0459f798@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Tue, 17 Aug 2004 08:31:25 +0900
To: [e-mail]
From: Martin Duerst <[e-mail]>
Subject: new mailing list: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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, [e-mail],
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 [e-mail]
(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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F16SHn080357; Sat, 14 Aug 2004 18:06:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F16SKu080356; Sat, 14 Aug 2004 18:06:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.apptran.com (adsl-64-164-137-105.dsl.snfc21.pacbell.net [64.164.137.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F16ST4080348 for <[e-mail]>; Sat, 14 Aug 2004 18:06:28 -0700 (PDT) (envelope-from [e-mail])
Received: from psaux.com (linux5.apptran.com [192.168.1.157] (may be forged)) by mail.apptran.com (8.12.8/8.12.8) with ESMTP id i7F16VB0010583 for <[e-mail]>; Sat, 14 Aug 2004 18:06:31 -0700
Message-ID: <[e-mail]>
Date: Sat, 14 Aug 2004 18:06:31 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: Re: creative use of vacation - is 'reply' action needed?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ENIxjp074462; Sat, 14 Aug 2004 16:18:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ENIxvQ074461; Sat, 14 Aug 2004 16:18:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ENIwnR074454 for <[e-mail]>; Sat, 14 Aug 2004 16:18:58 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.3] (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7EN3Wo3012513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 14 Aug 2004 19:03:34 -0400
Date: Sat, 14 Aug 2004 19:19:00 -0400
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: creative use of vacation - is 'reply' action needed?
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJxP8B022000; Thu, 12 Aug 2004 12:59:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJxPcY021999; Thu, 12 Aug 2004 12:59:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJxOvr021992 for <[e-mail]>; Thu, 12 Aug 2004 12:59:24 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7CJiHo3023527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Aug 2004 15:44:19 -0400
Date: Thu, 12 Aug 2004 15:59:25 -0400
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: lunch bof notes
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJpNTS021213; Thu, 12 Aug 2004 12:51:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJpNLr021211; Thu, 12 Aug 2004 12:51:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJpMSq021195 for <[e-mail]>; Thu, 12 Aug 2004 12:51:23 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1BvLbf-0000cW-KL for [e-mail]; Thu, 12 Aug 2004 21:51:23 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvLbc-0008Km-Ov for [e-mail]; Thu, 12 Aug 2004 21:51:20 +0200
Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Aug 2004 21:51:16 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJQJFK018690; Thu, 12 Aug 2004 12:26:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJQJvX018689; Thu, 12 Aug 2004 12:26:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJQICP018678 for <[e-mail]>; Thu, 12 Aug 2004 12:26:18 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7CJBBo3022682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 15:11:12 -0400
Date: Thu, 12 Aug 2004 15:26:19 -0400
From: Cyrus Daboo <[e-mail]>
To: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Matthew,

--On Wednesday, August 11, 2004 4:30 PM -0700 Matthew Elvey 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJH5Vs017201; Thu, 12 Aug 2004 12:17:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJH5iq017200; Thu, 12 Aug 2004 12:17:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJH4a4017185 for <[e-mail]>; Thu, 12 Aug 2004 12:17:05 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47] ident=[O+z5r/ZtVMDNvF4/qtv6uwn/MfaGjXm/]) by pat.uio.no with esmtp (Exim 4.34) id 1BvL4O-00033e-RM for [e-mail]; Thu, 12 Aug 2004 21:17:01 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvL4J-0007TK-GH for [e-mail]; Thu, 12 Aug 2004 21:16:57 +0200
Subject: Re: regarding short-circuiting
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Aug 2004 21:16:50 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 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: [e-mail]" and "Cc:
> > [e-mail]" -- 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJ23IQ014507; Thu, 12 Aug 2004 12:02:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJ23KQ014506; Thu, 12 Aug 2004 12:02:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJ22SI014492 for <[e-mail]>; Thu, 12 Aug 2004 12:02:02 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7CIkqo3022070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 14:46:52 -0400
Date: Thu, 12 Aug 2004 15:02:00 -0400
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
cc: Tony Hansen <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: draft-homme-sieve-variables-03.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kjetil,

--On Thursday, August 12, 2004 8:46 PM +0200 Kjetil Torgrim Homme 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIpbrZ013330; Thu, 12 Aug 2004 11:51:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CIpbcL013329; Thu, 12 Aug 2004 11:51:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIpZQc013316 for <[e-mail]>; Thu, 12 Aug 2004 11:51:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 12 Aug 2004 11:51:31 -0700 (PDT)
Date: Thu, 12 Aug 2004 11:44:34 -0700 (PDT)
From: [e-mail]
Subject: Re: regarding short-circuiting
In-reply-to: "Your message dated Thu, 12 Aug 2004 20:14:31 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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: [e-mail]" and "Cc:
> [e-mail]" -- 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIkYBQ012807; Thu, 12 Aug 2004 11:46:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CIkY3C012806; Thu, 12 Aug 2004 11:46:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIkXKc012799 for <[e-mail]>; Thu, 12 Aug 2004 11:46:33 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1BvKav-0004pK-Af; Thu, 12 Aug 2004 20:46:33 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvKaq-0007eh-0B; Thu, 12 Aug 2004 20:46:28 +0200
Subject: Re: draft-homme-sieve-variables-03.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: Tony Hansen <[e-mail]>, IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Aug 2004 20:46:23 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2004-08-12 at 14:42 -0400, Cyrus Daboo wrote:
> Kjetil Torgrim Homme <[e-mail]> 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIgsgg012413; Thu, 12 Aug 2004 11:42:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CIgsGQ012412; Thu, 12 Aug 2004 11:42:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIgsEk012399 for <[e-mail]>; Thu, 12 Aug 2004 11:42:54 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 12 Aug 2004 11:42:54 -0700 (PDT)
Date: Thu, 12 Aug 2004 11:42:32 -0700 (PDT)
From: [e-mail]
Subject: Re: a conflict between Sieve base and variables
In-reply-to: "Your message dated Thu, 12 Aug 2004 20:12:48 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIggd9012383; Thu, 12 Aug 2004 11:42:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CIgguF012382; Thu, 12 Aug 2004 11:42:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIgfQ2012352 for <[e-mail]>; Thu, 12 Aug 2004 11:42:41 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7CIRRo3021755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 14:27:27 -0400
Date: Thu, 12 Aug 2004 14:42:35 -0400
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, Tony Hansen <[e-mail]>
cc: IETF MTA Filters List <[e-mail]>
Subject: Re: draft-homme-sieve-variables-03.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kjetil,

--On Thursday, August 12, 2004 8:34 PM +0200 Kjetil Torgrim Homme 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIYJ1j011436; Thu, 12 Aug 2004 11:34:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CIYJmx011435; Thu, 12 Aug 2004 11:34:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIYIS5011424 for <[e-mail]>; Thu, 12 Aug 2004 11:34:18 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1BvKP4-0002VV-Va; Thu, 12 Aug 2004 20:34:19 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvKP2-0003bo-Rw; Thu, 12 Aug 2004 20:34:16 +0200
Subject: Re: draft-homme-sieve-variables-03.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Aug 2004 20:34:12 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIEYYD008997; Thu, 12 Aug 2004 11:14:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CIEYhg008996; Thu, 12 Aug 2004 11:14:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIEXA7008988 for <[e-mail]>; Thu, 12 Aug 2004 11:14:33 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1BvK5y-0006uT-0t for [e-mail]; Thu, 12 Aug 2004 20:14:34 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvK5w-0000en-2l for [e-mail]; Thu, 12 Aug 2004 20:14:32 +0200
Subject: regarding short-circuiting
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Thu, 12 Aug 2004 20:14:31 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]" and "Cc:
[e-mail]" -- 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CID0t6008799; Thu, 12 Aug 2004 11:13:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CID0Nk008798; Thu, 12 Aug 2004 11:13:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CICxph008687 for <[e-mail]>; Thu, 12 Aug 2004 11:13:00 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1BvK4O-0006gY-3t for [e-mail]; Thu, 12 Aug 2004 20:12:56 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvK4I-00028d-7t for [e-mail]; Thu, 12 Aug 2004 20:12:50 +0200
Subject: a conflict between Sieve base and variables
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Thu, 12 Aug 2004 20:12:48 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CH5F60002920; Thu, 12 Aug 2004 10:05:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CH5Fpm002919; Thu, 12 Aug 2004 10:05:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CH5E2j002911 for <[e-mail]>; Thu, 12 Aug 2004 10:05:15 -0700 (PDT) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7CH5AWN000727 for <[e-mail]>; Thu, 12 Aug 2004 12:05:10 -0500
Received: from [135.91.110.75] (thansen-n.mt.att.com[135.91.110.75](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040812170522gw1002eu2ce> (Authid: tony); Thu, 12 Aug 2004 17:05:22 +0000
Message-ID: <[e-mail]>
Date: Thu, 12 Aug 2004 13:05:09 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: draft-homme-sieve-variables-03.txt
References: <[e-mail]>	 <[e-mail]>  <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
	[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CGkumM000689; Thu, 12 Aug 2004 09:46:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CGku4B000688; Thu, 12 Aug 2004 09:46:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CGktad000679 for <[e-mail]>; Thu, 12 Aug 2004 09:46:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1BvIj8-0004qU-Bu; Thu, 12 Aug 2004 18:46:54 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvIj5-0003WD-Sw; Thu, 12 Aug 2004 18:46:51 +0200
Subject: Re: draft-homme-sieve-variables-03.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Aug 2004 18:46:46 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CFeZ0i093677; Thu, 12 Aug 2004 08:40:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CFeZSX093676; Thu, 12 Aug 2004 08:40:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CFeWF2093669 for <[e-mail]>; Thu, 12 Aug 2004 08:40:32 -0700 (PDT) (envelope-from [e-mail])
Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7CFPNo3017424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 11:25:23 -0400
Date: Thu, 12 Aug 2004 11:43:19 -0400
From: Cyrus Daboo <[e-mail]>
To: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: Are option extensions exclusive?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Michael,

--On Thursday, August 12, 2004 4:29 PM +0200 Michael Haardt 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEtHoe089654; Thu, 12 Aug 2004 07:55:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CEtH5V089653; Thu, 12 Aug 2004 07:55:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEtGN0089646 for <[e-mail]>; Thu, 12 Aug 2004 07:55:17 -0700 (PDT) (envelope-from [e-mail])
Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com  via TCP (internal) with ESMTPA; Thu, 12 Aug 2004 15:59:16 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 Aug 2004 15:55:08 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Are option extensions exclusive?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEqYeg088628; Thu, 12 Aug 2004 07:52:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CEqY94088627; Thu, 12 Aug 2004 07:52:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEqXen088621 for <[e-mail]>; Thu, 12 Aug 2004 07:52:33 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 12 Aug 2004 07:52:35 -0700 (PDT)
Date: Thu, 12 Aug 2004 07:49:58 -0700 (PDT)
From: [e-mail]
Subject: Re: Are option extensions exclusive?
In-reply-to: "Your message dated Thu, 12 Aug 2004 16:29:47 +0200" <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEa69c085175; Thu, 12 Aug 2004 07:36:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CEa6Sa085174; Thu, 12 Aug 2004 07:36:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEa58I085161 for <[e-mail]>; Thu, 12 Aug 2004 07:36:06 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 12 Aug 2004 07:36:06 -0700 (PDT)
Date: Thu, 12 Aug 2004 07:32:54 -0700 (PDT)
From: [e-mail]
Subject: Re: draft-homme-sieve-variables-03.txt
In-reply-to: "Your message dated Thu, 12 Aug 2004 11:22:39 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Tony Hansen <[e-mail]>, IETF MTA Filters List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Wed, 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CETkjM083870; Thu, 12 Aug 2004 07:29:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CETkQQ083869; Thu, 12 Aug 2004 07:29:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CETj3W083862 for <[e-mail]>; Thu, 12 Aug 2004 07:29:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout1.freenet.de with asmtp (Exim 4.41) id 1BvGaR-0000oX-Lx for [e-mail]; Thu, 12 Aug 2004 16:29:47 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BvGaR-0001Bv-KY for [e-mail]; Thu, 12 Aug 2004 16:29:47 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.42 #1) id 1BvGaR-00027g-40 for [e-mail]; Thu, 12 Aug 2004 16:29:47 +0200
To: [e-mail]
Subject: Re: Are option extensions exclusive?
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 12 Aug 2004 16:29:47 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CESH58083500; Thu, 12 Aug 2004 07:28:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CESHeo083499; Thu, 12 Aug 2004 07:28:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CESGZA083469 for <[e-mail]>; Thu, 12 Aug 2004 07:28:16 -0700 (PDT) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7CESDl1028229 for <[e-mail]>; Thu, 12 Aug 2004 10:28:13 -0400
Received: from [135.210.128.124] (unknown[135.210.128.124](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040812142823gw1002evjae> (Authid: tony); Thu, 12 Aug 2004 14:28:23 +0000
Message-ID: <[e-mail]>
Date: Thu, 12 Aug 2004 10:28:09 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: draft-homme-sieve-variables-03.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
	[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CECVUJ079197; Thu, 12 Aug 2004 07:12:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CECVBm079196; Thu, 12 Aug 2004 07:12:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CECV52079190 for <[e-mail]>; Thu, 12 Aug 2004 07:12:31 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 12 Aug 2004 07:12:30 -0700 (PDT)
Date: Thu, 12 Aug 2004 07:03:22 -0700 (PDT)
From: [e-mail]
Subject: Re: Are option extensions exclusive?
In-reply-to: "Your message dated Thu, 12 Aug 2004 14:05:14 +0200" <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CDsBqa074255; Thu, 12 Aug 2004 06:54:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CDsBQT074254; Thu, 12 Aug 2004 06:54:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CDsADX074240 for <[e-mail]>; Thu, 12 Aug 2004 06:54:10 -0700 (PDT) (envelope-from [e-mail])
Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com  via TCP (internal) with ESMTPA; Thu, 12 Aug 2004 14:58:12 +0100
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 2004 20:23:28 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Matthew Elvey <[e-mail]>
CC: [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CCYPgS055406; Thu, 12 Aug 2004 05:34:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CCYPro055405; Thu, 12 Aug 2004 05:34:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CCYOED055393 for <[e-mail]>; Thu, 12 Aug 2004 05:34:24 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1BvEmk-0003O1-1f for [e-mail]; Thu, 12 Aug 2004 14:34:22 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvElx-0007XU-OE for [e-mail]; Thu, 12 Aug 2004 14:33:33 +0200
Subject: Re: Are option extensions exclusive?
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Aug 2004 14:33:20 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.001, required 12, NEW_DOMAIN_EXTENSIONS 2.00, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CC5MRG048920; Thu, 12 Aug 2004 05:05:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CC5M72048919; Thu, 12 Aug 2004 05:05:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CC5LTB048893 for <[e-mail]>; Thu, 12 Aug 2004 05:05:21 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with asmtp (Exim 4.41) id 1BvEKZ-0003u0-G3 for [e-mail]; Thu, 12 Aug 2004 14:05:15 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BvEKZ-00007T-EH for [e-mail]; Thu, 12 Aug 2004 14:05:15 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.42 #1) id 1BvEKY-00022J-Vq for [e-mail]; Thu, 12 Aug 2004 14:05:14 +0200
To: [e-mail]
Subject: Are option extensions exclusive?
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 12 Aug 2004 14:05:14 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C9kZ2x015611; Thu, 12 Aug 2004 02:46:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C9kZQF015610; Thu, 12 Aug 2004 02:46:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C9kZj1015587 for <[e-mail]>; Thu, 12 Aug 2004 02:46:35 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1BvCAK-00064x-Qd; Thu, 12 Aug 2004 11:46:32 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvC9C-0001L5-Ta; Thu, 12 Aug 2004 11:45:22 +0200
Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
From: Kjetil Torgrim Homme <[e-mail]>
To: Matthew Elvey <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Aug 2004 11:45:18 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C9Mv7u010426; Thu, 12 Aug 2004 02:22:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C9MvkB010425; Thu, 12 Aug 2004 02:22:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C9MuI2010415 for <[e-mail]>; Thu, 12 Aug 2004 02:22:57 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1BvBnR-0000M3-NP; Thu, 12 Aug 2004 11:22:53 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BvBnK-0003Q5-34; Thu, 12 Aug 2004 11:22:46 +0200
Subject: Re: draft-homme-sieve-variables-03.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Aug 2004 11:22:39 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNS4Ct000627; Wed, 11 Aug 2004 16:28:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BNS4hc000626; Wed, 11 Aug 2004 16:28:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNS4hC000620 for <[e-mail]>; Wed, 11 Aug 2004 16:28:04 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: oJI1ipUEr+CuquJogW8zeg 1092266884
Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 6D865C1470B; Wed, 11 Aug 2004 19:28:03 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 2004 16:30:04 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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! 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLPPFZ092228; Wed, 11 Aug 2004 14:25:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BLPPTI092227; Wed, 11 Aug 2004 14:25:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLPO7o092218 for <[e-mail]>; Wed, 11 Aug 2004 14:25:24 -0700 (PDT) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7BLPNwC030457 for <[e-mail]>; Wed, 11 Aug 2004 16:25:24 -0500
Received: from [135.210.112.182] (unknown[135.210.112.182](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040811212534gw1002euqte> (Authid: tony); Wed, 11 Aug 2004 21:25:34 +0000
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 2004 17:25:22 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], IETF MTA Filters List <[e-mail]>
Subject: Re: draft-homme-sieve-variables-03.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] 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
	[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGcU8E062803; Wed, 11 Aug 2004 09:38:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGcUgl062802; Wed, 11 Aug 2004 09:38:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGcUTm062793 for <[e-mail]>; Wed, 11 Aug 2004 09:38:30 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 11 Aug 2004 09:38:30 -0700 (PDT)
Date: Wed, 11 Aug 2004 09:34:12 -0700 (PDT)
From: [e-mail]
Subject: Re: draft-homme-sieve-variables-03.txt
In-reply-to: "Your message dated Wed, 11 Aug 2004 11:21:26 -0400" <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: [e-mail], IETF MTA Filters List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFLaaG052927; Wed, 11 Aug 2004 08:21:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BFLaq4052926; Wed, 11 Aug 2004 08:21:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFLYOf052890 for <[e-mail]>; Wed, 11 Aug 2004 08:21:35 -0700 (PDT) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i7BFLUl1002895 for <[e-mail]>; Wed, 11 Aug 2004 11:21:30 -0400
Received: from [135.210.36.223] (unknown[135.210.36.223](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040811152140gw1002f18me> (Authid: tony); Wed, 11 Aug 2004 15:21:40 +0000
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 2004 11:21:26 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], IETF MTA Filters List <[e-mail]>
Subject: draft-homme-sieve-variables-03.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
	[e-mail]

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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0gVW4086034; Tue, 10 Aug 2004 17:42:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B0gV8v086033; Tue, 10 Aug 2004 17:42:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0gULF086026 for <[e-mail]>; Tue, 10 Aug 2004 17:42:31 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 10 Aug 2004 17:42:32 -0700 (PDT)
Date: Tue, 10 Aug 2004 17:39:59 -0700 (PDT)
From: [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
In-reply-to: "Your message dated Wed, 11 Aug 2004 01:33:45 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0YXKr085399; Tue, 10 Aug 2004 17:34:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B0YX8t085398; Tue, 10 Aug 2004 17:34:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0YWlF085385 for <[e-mail]>; Tue, 10 Aug 2004 17:34:33 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1Buh4a-00037W-VV for [e-mail]; Wed, 11 Aug 2004 02:34:33 +0200
Received: from 110.80-203-29.nextgentel.com ([80.203.29.110] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Buh4Z-0002t2-2Z for [e-mail]; Wed, 11 Aug 2004 02:34:31 +0200
Subject: Re: draft-elvey-refuse-sieve-02.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 11 Aug 2004 02:31:47 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0RxfX084113; Tue, 10 Aug 2004 17:27:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B0Rxu2084112; Tue, 10 Aug 2004 17:27:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0Rv5B084102 for <[e-mail]>; Tue, 10 Aug 2004 17:27:59 -0700 (PDT) (envelope-from [e-mail])
Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7B0Ru0R024213; Tue, 10 Aug 2004 17:27:56 -0700 (PDT)
Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id i7B0RuN29255; Tue, 10 Aug 2004 17:27:56 -0700 (PDT)
Received: from [129.153.12.231] (dhcp-uwcv01-12-231.West.Sun.COM [129.153.12.231]) by we-gotmail.red.iplanet.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Jul 26 2004)) with ESMTPSA id <[e-mail]>; Tue, 10 Aug 2004 17:27:56 -0700 (PDT)
Date: Tue, 10 Aug 2004 17:27:42 -0700
From: Kristin Hubner <[e-mail]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
In-reply-to: <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: Matthew Elvey <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>
> Kristin Hubner <[e-mail]> 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
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0PVZS083993; Tue, 10 Aug 2004 17:25:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B0PVTP083992; Tue, 10 Aug 2004 17:25:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B0PVc9083986 for <[e-mail]>; Tue, 10 Aug 2004 17:25:31 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.3] (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7B0AZo3002383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2004 20:10:38 -0400
Date: Tue, 10 Aug 2004 20:25:27 -0400
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kjetil,

--On Wednesday, August 11, 2004 2:01 AM +0200 Kjetil Torgrim Homme 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B04bcB082680; Tue, 10 Aug 2004 17:04:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B04bVF082679; Tue, 10 Aug 2004 17:04:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B04ap9082670 for <[e-mail]>; Tue, 10 Aug 2004 17:04:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1Bugbe-0004OT-5I for [e-mail]; Wed, 11 Aug 2004 02:04:38 +0200
Received: from 110.80-203-29.nextgentel.com ([80.203.29.110] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BugbZ-0000fK-8h for [e-mail]; Wed, 11 Aug 2004 02:04:33 +0200
Subject: Re: draft-elvey-refuse-sieve-02.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 11 Aug 2004 02:01:47 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANquWA081465; Tue, 10 Aug 2004 16:52:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ANquAZ081464; Tue, 10 Aug 2004 16:52:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANqtYx081458 for <[e-mail]>; Tue, 10 Aug 2004 16:52:55 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.3] (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7ANc1o3001719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2004 19:38:06 -0400
Date: Tue, 10 Aug 2004 19:52:52 -0400
From: Cyrus Daboo <[e-mail]>
To: Kristin Hubner <[e-mail]>
cc: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kristin,

--On Tuesday, August 10, 2004 1:17 PM -0700 Kristin Hubner 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANpuYT081413; Tue, 10 Aug 2004 16:51:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ANpuLj081412; Tue, 10 Aug 2004 16:51:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANptcV081405 for <[e-mail]>; Tue, 10 Aug 2004 16:51:56 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.3] (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7ANb3o3001674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2004 19:37:06 -0400
Date: Tue, 10 Aug 2004 19:51:55 -0400
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt;	http://wiki.fastmail.fm/wiki/index.php/Sieve ExtensionsSupportMatrix
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kjetil,

--On Wednesday, August 11, 2004 1:33 AM +0200 Kjetil Torgrim Homme 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANaV1K080406; Tue, 10 Aug 2004 16:36:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ANaV8D080405; Tue, 10 Aug 2004 16:36:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANaUlV080394 for <[e-mail]>; Tue, 10 Aug 2004 16:36:31 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1BugAR-0006P9-Ve for [e-mail]; Wed, 11 Aug 2004 01:36:32 +0200
Received: from 110.80-203-29.nextgentel.com ([80.203.29.110] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BugAP-0007AE-7I for [e-mail]; Wed, 11 Aug 2004 01:36:29 +0200
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 11 Aug 2004 01:33:45 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANWpRv080212; Tue, 10 Aug 2004 16:32:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ANWpB6080211; Tue, 10 Aug 2004 16:32:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANWoY0080202 for <[e-mail]>; Tue, 10 Aug 2004 16:32:50 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1Bug6r-0005Qh-Sg; Wed, 11 Aug 2004 01:32:50 +0200
Received: from 110.80-203-29.nextgentel.com ([80.203.29.110] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Bug6o-0006uC-PV; Wed, 11 Aug 2004 01:32:46 +0200
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
From: Kjetil Torgrim Homme <[e-mail]>
To: Matthew Elvey <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 11 Aug 2004 01:30:03 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 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" "[e-mail]" {
     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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANIHFG079333; Tue, 10 Aug 2004 16:18:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ANIHZh079332; Tue, 10 Aug 2004 16:18:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ANIGed079324 for <[e-mail]>; Tue, 10 Aug 2004 16:18:16 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7ANIJMW011832 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 Aug 2004 16:18:19 -0700
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i7ANIHNL028776; Tue, 10 Aug 2004 16:18:17 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kristin Hubner <[e-mail]>
Cc: Matthew Elvey <[e-mail]>, [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Tue, 10 Aug 2004 16:18:17 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kristin Hubner <[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AN90pI078412; Tue, 10 Aug 2004 16:09:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AN902o078411; Tue, 10 Aug 2004 16:09:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AN8swr078388 for <[e-mail]>; Tue, 10 Aug 2004 16:08:55 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1Bufjk-00076v-Mz; Wed, 11 Aug 2004 01:08:56 +0200
Received: from 110.80-203-29.nextgentel.com ([80.203.29.110] helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Bufji-00055B-Jq; Wed, 11 Aug 2004 01:08:54 +0200
Subject: Re: managesieve
From: Kjetil Torgrim Homme <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 11 Aug 2004 01:06:10 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ALLSba068916; Tue, 10 Aug 2004 14:21:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ALLSGJ068915; Tue, 10 Aug 2004 14:21:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ALLMS6068901 for <[e-mail]>; Tue, 10 Aug 2004 14:21:22 -0700 (PDT) (envelope-from [e-mail])
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bue3c-0002S1-00 for <[e-mail]>; Tue, 10 Aug 2004 23:21:20 +0200
Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 10 Aug 2004 23:21:20 +0200
Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 10 Aug 2004 23:21:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Simon Josefsson <[e-mail]>
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
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
Cancel-Lock: sha1:SbDhJ5vWkyyQYEaY8pQ9bsM6OsY=
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo <[e-mail]> writes:

> <http://www.xmpp.org/ietf-logs/[e-mail]/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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AKI7V0064138; Tue, 10 Aug 2004 13:18:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AKI7I5064137; Tue, 10 Aug 2004 13:18:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AKI7bE064128 for <[e-mail]>; Tue, 10 Aug 2004 13:18:07 -0700 (PDT) (envelope-from [e-mail])
Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7AKI40R028637; Tue, 10 Aug 2004 13:18:05 -0700 (PDT)
Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id i7AKI4E06185; Tue, 10 Aug 2004 13:18:04 -0700 (PDT)
Received: from [129.153.12.231] (dhcp-uwcv01-12-231.West.Sun.COM [129.153.12.231]) by we-gotmail.red.iplanet.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Jul 26 2004)) with ESMTPSA id <[e-mail]>; Tue, 10 Aug 2004 13:18:04 -0700 (PDT)
Date: Tue, 10 Aug 2004 13:17:49 -0700
From: Kristin Hubner <[e-mail]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
In-reply-to: <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: Matthew Elvey <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>
> Hi Matthew,
>
> --On Tuesday, August 10, 2004 11:36 AM -0700 Matthew Elvey  
> <[e-mail]> 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/[e-mail]/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
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJNj53059396; Tue, 10 Aug 2004 12:23:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AJNjFO059395; Tue, 10 Aug 2004 12:23:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJNiAm059388 for <[e-mail]>; Tue, 10 Aug 2004 12:23:45 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7AJNf96017798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 Aug 2004 12:23:41 -0700
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i7AJNegS011954; Tue, 10 Aug 2004 12:23:40 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Matthew Elvey <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Tue, 10 Aug 2004 12:23:40 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matthew Elvey <[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJGcVl058642; Tue, 10 Aug 2004 12:16:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AJGcck058641; Tue, 10 Aug 2004 12:16:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJGb7l058633 for <[e-mail]>; Tue, 10 Aug 2004 12:16:38 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7AJ1lo3028425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2004 15:01:48 -0400
Date: Tue, 10 Aug 2004 15:16:36 -0400
From: Cyrus Daboo <[e-mail]>
To: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Matthew,

--On Tuesday, August 10, 2004 11:36 AM -0700 Matthew Elvey 
<[e-mail]> 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/[e-mail]/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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJ9X0C057427; Tue, 10 Aug 2004 12:09:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AJ9XbP057426; Tue, 10 Aug 2004 12:09:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJ9Wsg057418 for <[e-mail]>; Tue, 10 Aug 2004 12:09:33 -0700 (PDT) (envelope-from [e-mail])
Received: from isode.com (1Cust30.tnt5.lnd4.gbr.da.uu.net [62.188.134.30])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 10 Aug 2004 20:13:21 +0100
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 2004 19:22:14 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AIZ2cw054836; Tue, 10 Aug 2004 11:35:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AIZ1Ml054835; Tue, 10 Aug 2004 11:35:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AIZ1Jo054821 for <[e-mail]>; Tue, 10 Aug 2004 11:35:01 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: Jz5dOG7QA95uE0Rwtzk0sA 1092162901
Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id E3BAAC14610; Tue, 10 Aug 2004 14:35:00 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 2004 11:36:52 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 
> <[e-mail]> 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.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AFBC08027641; Tue, 10 Aug 2004 08:11:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AFBCCe027640; Tue, 10 Aug 2004 08:11:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AFBBkd027633 for <[e-mail]>; Tue, 10 Aug 2004 08:11:11 -0700 (PDT) (envelope-from [e-mail])
Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7AEuNo3022585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2004 10:56:23 -0400
Date: Tue, 10 Aug 2004 11:13:57 -0400
From: Cyrus Daboo <[e-mail]>
To: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Matthew,

--On Monday, August 09, 2004 10:46 PM -0700 Matthew Elvey 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A5iar2076515; Mon, 9 Aug 2004 22:44:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A5iawn076514; Mon, 9 Aug 2004 22:44:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A5iZ2N076504 for <[e-mail]>; Mon, 9 Aug 2004 22:44:35 -0700 (PDT) (envelope-from [e-mail])
X-Sasl-enc: 0j98UjHW8uHE1hPFT9IsYQ 1092116680
Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id B184FC14256; Tue, 10 Aug 2004 01:44:39 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 09 Aug 2004 22:46:40 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75NmiAE048308; Thu, 5 Aug 2004 16:48:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75Nmifs048307; Thu, 5 Aug 2004 16:48:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75NmhWZ048300 for <[e-mail]>; Thu, 5 Aug 2004 16:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: from opene-130-129-128-69.ietf60.ietf.org (opene-130-129-128-69.ietf60.ietf.org [130.129.128.69]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i75NYfo3005785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Aug 2004 19:34:42 -0400
Date: Thu, 05 Aug 2004 16:48:46 -0700
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: updated variables draft submitted
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kjetil,

--On Friday, August 6, 2004 1:37 AM +0200 Kjetil Torgrim Homme 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75NmPLo048279; Thu, 5 Aug 2004 16:48:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75NmP39048278; Thu, 5 Aug 2004 16:48:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75NmOTf048270 for <[e-mail]>; Thu, 5 Aug 2004 16:48:24 -0700 (PDT) (envelope-from [e-mail])
Received: from opene-130-129-128-69.ietf60.ietf.org (opene-130-129-128-69.ietf60.ietf.org [130.129.128.69]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i75NY9o3005772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Aug 2004 19:34:11 -0400
Date: Thu, 05 Aug 2004 16:48:14 -0700
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: updated variables draft submitted
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kjetil,

--On Friday, August 6, 2004 1:37 AM +0200 Kjetil Torgrim Homme 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Ne7Af047626; Thu, 5 Aug 2004 16:40:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75Ne7rl047625; Thu, 5 Aug 2004 16:40:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Ne6dI047612 for <[e-mail]>; Thu, 5 Aug 2004 16:40:06 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1BsrqC-0002GU-Ne for [e-mail]; Fri, 06 Aug 2004 01:40:08 +0200
Received: from [80.203.78.108] (helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Bsrq9-0002kM-1G for [e-mail]; Fri, 06 Aug 2004 01:40:05 +0200
Subject: updated variables draft submitted
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Fri, 06 Aug 2004 01:37:59 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75IqGct024728; Thu, 5 Aug 2004 11:52:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75IqGJc024727; Thu, 5 Aug 2004 11:52:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id i75IqFoq024716 for <[e-mail]>; Thu, 5 Aug 2004 11:52:15 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 80823 invoked by uid 101); 5 Aug 2004 14:52:17 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 5 Aug 2004 14:52:17 -0400
To: [e-mail]
Cc: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: Three more comments about the vacation draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Aug 04, 2004 at 09:48:56AM -0700, [e-mail] 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-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75G5vuD010785; Thu, 5 Aug 2004 09:05:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75G5v5K010784; Thu, 5 Aug 2004 09:05:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75G5ujF010778 for <[e-mail]>; Thu, 5 Aug 2004 09:05:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 05 Aug 2004 09:05:58 -0700 (PDT)
Date: Thu, 05 Aug 2004 09:05:23 -0700 (PDT)
From: [e-mail]
Subject: Re: variables and relational interaction
In-reply-to: "Your message dated Thu, 05 Aug 2004 16:32:55 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75EYl3t002668; Thu, 5 Aug 2004 07:34:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75EYlQJ002666; Thu, 5 Aug 2004 07:34:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75EYjnZ002647 for <[e-mail]>; Thu, 5 Aug 2004 07:34:46 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 05 Aug 2004 07:34:44 -0700 (PDT)
Date: Thu, 05 Aug 2004 07:34:20 -0700 (PDT)
From: [e-mail]
Subject: Re: variables extension redux
In-reply-to: "Your message dated Thu, 05 Aug 2004 16:04:06 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75EX0t8002512; Thu, 5 Aug 2004 07:33:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75EX0Uv002511; Thu, 5 Aug 2004 07:33:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75EWxMk002476 for <[e-mail]>; Thu, 5 Aug 2004 07:33:00 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1BsjIg-0000b1-OG for [e-mail]; Thu, 05 Aug 2004 16:32:58 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BsjIe-0003pr-Gi for [e-mail]; Thu, 05 Aug 2004 16:32:56 +0200
Subject: variables and relational interaction
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Thu, 05 Aug 2004 16:32:55 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75E4LbM099959; Thu, 5 Aug 2004 07:04:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75E4LJ1099958; Thu, 5 Aug 2004 07:04:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75E4Kxe099950 for <[e-mail]>; Thu, 5 Aug 2004 07:04:20 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1Bsiqv-0002Y9-BU for [e-mail]; Thu, 05 Aug 2004 16:04:17 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Bsiqs-0001OU-Oy for [e-mail]; Thu, 05 Aug 2004 16:04:15 +0200
Subject: Re: variables extension redux
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 05 Aug 2004 16:04:06 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75BPiYF087145; Thu, 5 Aug 2004 04:25:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75BPig6087144; Thu, 5 Aug 2004 04:25:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75BPh57087022 for <[e-mail]>; Thu, 5 Aug 2004 04:25:43 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout1.freenet.de with asmtp (Exim 4.41) id 1BsgNL-0007ud-Kp for [e-mail]; Thu, 05 Aug 2004 13:25:35 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx4.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BsgNL-0005di-JC for [e-mail]; Thu, 05 Aug 2004 13:25:35 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #27) id 1BsgNL-0005S9-AE for [e-mail]; Thu, 05 Aug 2004 13:25:35 +0200
To: [e-mail]
Subject: Re: Three more comments about the vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 05 Aug 2004 13:25:35 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Iji45005415; Wed, 4 Aug 2004 11:45:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74Iji94005409; Wed, 4 Aug 2004 11:45:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Ijhqb005402 for <[e-mail]>; Wed, 4 Aug 2004 11:45:44 -0700 (PDT) (envelope-from [e-mail])
Received: from isode.com (opene-130-129-128-164.ietf60.ietf.org [130.129.128.164])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 4 Aug 2004 19:49:11 +0100
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 2004 19:45:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: Sieve lunch
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Where are you people? I've lost you.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HK8Ce098393; Wed, 4 Aug 2004 10:20:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74HK83q098392; Wed, 4 Aug 2004 10:20:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74HK7XP098386 for <[e-mail]>; Wed, 4 Aug 2004 10:20:08 -0700 (PDT) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i74HK2mf017518 for <[e-mail]>; Wed, 4 Aug 2004 12:20:02 -0500
Received: from [135.210.28.89] (unknown[135.210.28.89](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040804172007gw1002eveee> (Authid: tony); Wed, 4 Aug 2004 17:20:07 +0000
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 2004 13:19:59 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Three more comments about the vacation draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I like Auto:.

	Tony Hansen
	[e-mail]

[e-mail] 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GopDt095081; Wed, 4 Aug 2004 09:50:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74Gop2T095080; Wed, 4 Aug 2004 09:50:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Goofm095074 for <[e-mail]>; Wed, 4 Aug 2004 09:50:50 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 04 Aug 2004 09:50:53 -0700 (PDT)
Date: Wed, 04 Aug 2004 09:48:56 -0700 (PDT)
From: [e-mail]
Subject: Re: Three more comments about the vacation draft
In-reply-to: "Your message dated Tue, 03 Aug 2004 21:07:22 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Tue, 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74FsacT090654; Wed, 4 Aug 2004 08:54:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74FsaeS090653; Wed, 4 Aug 2004 08:54:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74FsZ27090647 for <[e-mail]>; Wed, 4 Aug 2004 08:54:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 04 Aug 2004 08:54:37 -0700 (PDT)
Date: Wed, 04 Aug 2004 08:50:20 -0700 (PDT)
From: [e-mail]
Subject: Re: variables extension redux
In-reply-to: "Your message dated Wed, 04 Aug 2004 10:13:36 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On tir, 2004-08-03 at 10:51 -0700, [e-mail] 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Flx1F089635; Wed, 4 Aug 2004 08:47:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74FlxnF089634; Wed, 4 Aug 2004 08:47:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Flujf089626 for <[e-mail]>; Wed, 4 Aug 2004 08:47:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 04 Aug 2004 08:47:54 -0700 (PDT)
Date: Wed, 04 Aug 2004 08:47:36 -0700 (PDT)
From: [e-mail]
Subject: Re: Three more comments about the vacation draft
In-reply-to: "Your message dated Wed, 04 Aug 2004 11:41:24 +0200" <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i749fcD6044854; Wed, 4 Aug 2004 02:41:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i749fcTr044853; Wed, 4 Aug 2004 02:41:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i749fbWR044793 for <[e-mail]>; Wed, 4 Aug 2004 02:41:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout2.freenet.de with asmtp (Exim 4.41) id 1BsIGy-0001bM-Ps for [e-mail]; Wed, 04 Aug 2004 11:41:24 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BsIGy-0004wJ-OP for [e-mail]; Wed, 04 Aug 2004 11:41:24 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #16) id 1BsIGy-0005k2-GS for [e-mail]; Wed, 04 Aug 2004 11:41:24 +0200
To: [e-mail]
Subject: Re: Three more comments about the vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 04 Aug 2004 11:41:24 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i748Fgxd014938; Wed, 4 Aug 2004 01:15:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i748FgPg014937; Wed, 4 Aug 2004 01:15:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i748Ff5H014913 for <[e-mail]>; Wed, 4 Aug 2004 01:15:42 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.34) id 1BsGvy-0001lA-SN; Wed, 04 Aug 2004 10:15:39 +0200
Received: from [80.203.78.108] (helo=chico.njus.no) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BsGvs-0003Bh-8d; Wed, 04 Aug 2004 10:15:32 +0200
Subject: Re: variables extension redux
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 04 Aug 2004 10:13:36 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=0, required 12)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On tir, 2004-08-03 at 10:51 -0700, [e-mail] 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740M9Y8014770; Tue, 3 Aug 2004 17:22:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i740M9DR014769; Tue, 3 Aug 2004 17:22:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740M7M7014762 for <[e-mail]>; Tue, 3 Aug 2004 17:22:08 -0700 (PDT) (envelope-from [e-mail])
Received: from opene-130-129-130-152.ietf60.ietf.org (opene-130-129-130-152.ietf60.ietf.org [130.129.130.152]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7408Io3016827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Aug 2004 20:08:22 -0400
Date: Tue, 03 Aug 2004 17:22:05 -0700
From: Cyrus Daboo <[e-mail]>
To: Tony Hansen <[e-mail]>
cc: IETF MTA Filters List <[e-mail]>
Subject: Re: Lunch-BOF reminder
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Tony,

--On Tuesday, August 3, 2004 8:11 PM -0400 Tony Hansen <[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740Bp6B013814; Tue, 3 Aug 2004 17:11:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i740Bpwh013813; Tue, 3 Aug 2004 17:11:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740BoC0013805 for <[e-mail]>; Tue, 3 Aug 2004 17:11:50 -0700 (PDT) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i740BoRv020928 for <[e-mail]>; Tue, 3 Aug 2004 20:11:50 -0400
Received: from [135.210.112.121] (unknown[135.210.112.121](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040804001155gw1002euvte> (Authid: tony); Wed, 4 Aug 2004 00:11:56 +0000
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 2004 20:11:45 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: Lunch-BOF reminder
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

	Tony Hansen
	[e-mail]

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 [e-mail]
> 
> We are on Pacific Standard Time (-0700) here in San Diego.
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7404lNc013389; Tue, 3 Aug 2004 17:04:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7404lOx013388; Tue, 3 Aug 2004 17:04:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7404kM8013382 for <[e-mail]>; Tue, 3 Aug 2004 17:04:47 -0700 (PDT) (envelope-from [e-mail])
Received: from opene-130-129-130-152.ietf60.ietf.org (opene-130-129-130-152.ietf60.ietf.org [130.129.130.152]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i73Novo3016387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 3 Aug 2004 19:51:02 -0400
Date: Tue, 03 Aug 2004 17:04:45 -0700
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Lunch-BOF reminder
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 [e-mail]

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

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73J7aw0090629; Tue, 3 Aug 2004 12:07:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73J7aGM090628; Tue, 3 Aug 2004 12:07:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73J7Z8V090614 for <[e-mail]>; Tue, 3 Aug 2004 12:07:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1Bs4dK-0000e7-Ej; Tue, 03 Aug 2004 21:07:34 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Bs4dG-0006uV-JJ; Tue, 03 Aug 2004 21:07:30 +0200
Subject: Re: Three more comments about the vacation draft
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 03 Aug 2004 21:07:22 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.92 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.609, required 12, NO_FORMS 1.34, REMOVE_SUBJ 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73HxlxE084143; Tue, 3 Aug 2004 10:59:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73HxlZI084142; Tue, 3 Aug 2004 10:59:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73HxHdG084110 for <[e-mail]>; Tue, 3 Aug 2004 10:59:17 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 03 Aug 2004 10:59:20 -0700 (PDT)
Date: Tue, 03 Aug 2004 10:51:47 -0700 (PDT)
From: [e-mail]
Subject: Re: variables extension redux
In-reply-to: "Your message dated Sat, 31 Jul 2004 19:21:39 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73HdOMR082259; Tue, 3 Aug 2004 10:39:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73HdOfU082258; Tue, 3 Aug 2004 10:39:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73HdNsj082252 for <[e-mail]>; Tue, 3 Aug 2004 10:39:24 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 03 Aug 2004 10:39:26 -0700 (PDT)
Date: Tue, 03 Aug 2004 10:37:53 -0700 (PDT)
From: [e-mail]
Subject: Re: Three more comments about the vacation draft
In-reply-to: "Your message dated Tue, 03 Aug 2004 09:53:53 -0700 (PDT)" <[e-mail]>
To: [e-mail]
Cc: Michael Haardt <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73H10D5079118; Tue, 3 Aug 2004 10:01:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73H10Sd079117; Tue, 3 Aug 2004 10:01:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73H0xkD079106 for <[e-mail]>; Tue, 3 Aug 2004 10:00:59 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 03 Aug 2004 10:01:02 -0700 (PDT)
Date: Tue, 03 Aug 2004 09:53:53 -0700 (PDT)
From: [e-mail]
Subject: Re: Three more comments about the vacation draft
In-reply-to: "Your message dated Tue, 03 Aug 2004 17:00:44 +0200" <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73F0kMC070156; Tue, 3 Aug 2004 08:00:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73F0kj7070155; Tue, 3 Aug 2004 08:00:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73F0jlg070147 for <[e-mail]>; Tue, 3 Aug 2004 08:00:45 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with asmtp (Exim 4.41) id 1Bs0mT-0002RS-8M for [e-mail]; Tue, 03 Aug 2004 17:00:45 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1Bs0mT-0003aJ-7A for [e-mail]; Tue, 03 Aug 2004 17:00:45 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #16) id 1Bs0mS-0003xR-N1 for [e-mail]; Tue, 03 Aug 2004 17:00:44 +0200
Date: Tue, 3 Aug 2004 17:00:44 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Three more comments about the vacation draft
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Avtet049944; Tue, 3 Aug 2004 03:57:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Avt5L049943; Tue, 3 Aug 2004 03:57:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Avs1P049937 for <[e-mail]>; Tue, 3 Aug 2004 03:57:55 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout1.freenet.de with asmtp (Exim 4.41) id 1BrwoD-0000S3-4E for [e-mail]; Tue, 03 Aug 2004 12:46:17 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BrwoD-0001h4-0i for [e-mail]; Tue, 03 Aug 2004 12:46:17 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #11) id 1BrwoC-0002yz-NL for [e-mail]; Tue, 03 Aug 2004 12:46:16 +0200
To: [e-mail]
Subject: Re: Vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Tue, 03 Aug 2004 12:46:16 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73AbIEi046694; Tue, 3 Aug 2004 03:37:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73AbIHM046693; Tue, 3 Aug 2004 03:37:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73AbDpm046624 for <[e-mail]>; Tue, 3 Aug 2004 03:37:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout1.freenet.de with asmtp (Exim 4.41) id 1BrwfN-0000Yu-F5 for [e-mail]; Tue, 03 Aug 2004 12:37:09 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BrwfN-0002Dm-Dj for [e-mail]; Tue, 03 Aug 2004 12:37:09 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #11) id 1BrwfM-0002xm-VQ for [e-mail]; Tue, 03 Aug 2004 12:37:08 +0200
To: [e-mail]
Subject: Re: Vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Tue, 03 Aug 2004 12:37:08 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KtAxD089956; Mon, 2 Aug 2004 13:55:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72KtA2V089955; Mon, 2 Aug 2004 13:55:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.apptran.com (adsl-64-164-137-105.dsl.snfc21.pacbell.net [64.164.137.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Kt9wv089948 for <[e-mail]>; Mon, 2 Aug 2004 13:55:09 -0700 (PDT) (envelope-from [e-mail])
Received: from psaux.com (linux5.apptran.com [192.168.1.157] (may be forged)) by mail.apptran.com (8.12.8/8.12.8) with ESMTP id i72Kt2B0008158; Mon, 2 Aug 2004 13:55:03 -0700
Message-ID: <[e-mail]>
Date: Mon, 02 Aug 2004 13:55:02 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Vacation draft
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:
>>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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72HCvUt071091; Mon, 2 Aug 2004 10:12:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72HCvBt071090; Mon, 2 Aug 2004 10:12:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72HCu6r071084 for <[e-mail]>; Mon, 2 Aug 2004 10:12:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 02 Aug 2004 10:12:58 -0700 (PDT)
Date: Mon, 02 Aug 2004 10:05:50 -0700 (PDT)
From: [e-mail]
Subject: Re: Specification of ":mime" in vacation extension
In-reply-to: "Your message dated Mon, 02 Aug 2004 13:26:17 +0200" <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72GlAZp069335; Mon, 2 Aug 2004 09:47:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72GlAt8069334; Mon, 2 Aug 2004 09:47:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Gl5rt069326 for <[e-mail]>; Mon, 2 Aug 2004 09:47:09 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 02 Aug 2004 09:47:07 -0700 (PDT)
Date: Mon, 02 Aug 2004 09:36:02 -0700 (PDT)
From: [e-mail]
Subject: Re: Vacation draft
In-reply-to: "Your message dated Mon, 02 Aug 2004 17:02:01 +0200" <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72F4nUA062722; Mon, 2 Aug 2004 08:04:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72F4nL3062721; Mon, 2 Aug 2004 08:04:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72F4mLG062713 for <[e-mail]>; Mon, 2 Aug 2004 08:04:48 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 02 Aug 2004 08:04:47 -0700 (PDT)
Date: Mon, 02 Aug 2004 07:56:28 -0700 (PDT)
From: [e-mail]
Subject: Re: Vacation draft
In-reply-to: "Your message dated Mon, 02 Aug 2004 15:37:24 +0200" <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Michael Haardt <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72F29MQ062580; Mon, 2 Aug 2004 08:02:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72F29NB062579; Mon, 2 Aug 2004 08:02:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72F28iM062568 for <[e-mail]>; Mon, 2 Aug 2004 08:02:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout0.freenet.de with asmtp (Exim 4.41) id 1BreK9-0005wI-K3 for [e-mail]; Mon, 02 Aug 2004 17:02:01 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx4.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BreK9-0005BS-Ga for [e-mail]; Mon, 02 Aug 2004 17:02:01 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #11) id 1BreK9-0000v4-0I for [e-mail]; Mon, 02 Aug 2004 17:02:01 +0200
To: [e-mail]
Subject: Re: Vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Mon, 02 Aug 2004 17:02:01 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DcKr5057023; Mon, 2 Aug 2004 06:38:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72DcKdo057022; Mon, 2 Aug 2004 06:38:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DcJ7m057015 for <[e-mail]>; Mon, 2 Aug 2004 06:38:19 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.34) id 1Brd17-000392-W6; Mon, 02 Aug 2004 15:38:18 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Brd15-0007Vd-EF; Mon, 02 Aug 2004 15:38:15 +0200
Subject: Re: Vacation draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Mon, 02 Aug 2004 15:37:24 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72CQYWt052343; Mon, 2 Aug 2004 05:26:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72CQYG4052342; Mon, 2 Aug 2004 05:26:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72CQXX0052334 for <[e-mail]>; Mon, 2 Aug 2004 05:26:33 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with asmtp (Exim 4.41) id 1Brbtg-0005FI-6i for [e-mail]; Mon, 02 Aug 2004 14:26:32 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1Brbtg-000556-4Y for [e-mail]; Mon, 02 Aug 2004 14:26:32 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #11) id 1Brbtf-0000a4-Ma for [e-mail]; Mon, 02 Aug 2004 14:26:31 +0200
To: [e-mail]
Subject: Re: Vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Mon, 02 Aug 2004 14:26:31 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72C6Vc7050991; Mon, 2 Aug 2004 05:06:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72C6VlY050990; Mon, 2 Aug 2004 05:06:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72C6U1B050978 for <[e-mail]>; Mon, 2 Aug 2004 05:06:30 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1BrbaE-0002Gv-KJ; Mon, 02 Aug 2004 14:06:26 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by smtp.uio.no with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Brba6-0001f1-JC; Mon, 02 Aug 2004 14:06:18 +0200
Subject: Re: Vacation draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Mon, 02 Aug 2004 14:06:12 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72BQHSl046772; Mon, 2 Aug 2004 04:26:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72BQHns046771; Mon, 2 Aug 2004 04:26:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72BQGlg046765 for <[e-mail]>; Mon, 2 Aug 2004 04:26:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout2.freenet.de with asmtp (Exim 4.41) id 1BraxN-0008GP-Cy for [e-mail]; Mon, 02 Aug 2004 13:26:17 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx4.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BraxN-0003LJ-Aa for [e-mail]; Mon, 02 Aug 2004 13:26:17 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #11) id 1BraxN-0000Jg-1m for [e-mail]; Mon, 02 Aug 2004 13:26:17 +0200
To: [e-mail]
Subject: Specification of ":mime" in vacation extension
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Mon, 02 Aug 2004 13:26:17 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72BJL7T046406; Mon, 2 Aug 2004 04:19:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72BJLDJ046405; Mon, 2 Aug 2004 04:19:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72BJJkD046399 for <[e-mail]>; Mon, 2 Aug 2004 04:19:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout2.freenet.de with asmtp (Exim 4.41) id 1Braqc-0006Bi-6J for [e-mail]; Mon, 02 Aug 2004 13:19:18 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1Braqc-0000K5-54 for [e-mail]; Mon, 02 Aug 2004 13:19:18 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.41 #11) id 1Braqb-0000IN-Mv for [e-mail]; Mon, 02 Aug 2004 13:19:17 +0200
To: [e-mail]
Subject: Re: Vacation draft
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Mon, 02 Aug 2004 13:19:17 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i724GEvJ005950; Sun, 1 Aug 2004 21:16:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i724GEdM005949; Sun, 1 Aug 2004 21:16:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eddie.psaux.com (eddie.psaux.com [66.92.250.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i724GBKr005941 for <[e-mail]>; Sun, 1 Aug 2004 21:16:11 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.3] (krikkit.psaux.com [66.92.250.136]) by eddie.psaux.com (Postfix) with ESMTP id 3DAB523CB2; Sun,  1 Aug 2004 21:16:19 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 01 Aug 2004 21:14:18 -0700
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: Vacation draft
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

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