Re: Review of draft-ietf-sieve-refuse-reject-02

[Alexey Melnikov <[e-mail]>]

Randall Gellens wrote:

>>>  (6) What is the rational for item 1 on the action list in Section 
>>> 3.1 (as opposed to rejecting even if the MAIL FROM is null)?
>>
>> You have a point. If protocol level rejection is available, the 
>> recipient might just reject the message. For DSNs/MDNs, the server 
>> just "MUST NOT generate" them, right?
>
> I meant, why require that messages with a null MAIL FROM be accepted 
> and discarded?  Why not just fail the transaction?

I think I understood you and we are talking about the same thing. I will 
do the change.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7N9SToj078975; Wed, 23 Aug 2006 02:28:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7N9STO6078974; Wed, 23 Aug 2006 02:28:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7N9SOsm078963 for <[e-mail]>; Wed, 23 Aug 2006 02:28:26 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 23 Aug 2006 10:28:10 +0100
Message-ID: <[e-mail]>
Date: Wed, 23 Aug 2006 10:27:30 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Randall Gellens <[e-mail]>
CC: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
References: <p0630000cc0ec03ea5a83@[192.168.1.13]> <[e-mail]> <p06240501c11136fca041@[loud.qualcomm.com]>
In-Reply-To: <p06240501c11136fca041@[loud.qualcomm.com]>
MIME-version: 1.0
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>

Randall Gellens wrote:

>>>  (6) What is the rational for item 1 on the action list in Section 
>>> 3.1 (as opposed to rejecting even if the MAIL FROM is null)?
>>
>> You have a point. If protocol level rejection is available, the 
>> recipient might just reject the message. For DSNs/MDNs, the server 
>> just "MUST NOT generate" them, right?
>
> I meant, why require that messages with a null MAIL FROM be accepted 
> and discarded?  Why not just fail the transaction?

I think I understood you and we are talking about the same thing. I will 
do the change.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7MMh7hN051916; Tue, 22 Aug 2006 15:43:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7MMh7Lf051915; Tue, 22 Aug 2006 15:43:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7MMh3Wg051880 for <[e-mail]>; Tue, 22 Aug 2006 15:43:06 -0700 (MST) (envelope-from [e-mail])
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7MMgqdU015448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2006 15:42:52 -0700
Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7MMgow9001430; Tue, 22 Aug 2006 15:42:51 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06240501c11136fca041@[loud.qualcomm.com]>
In-Reply-To: <[e-mail]>
References: <p0630000cc0ec03ea5a83@[192.168.1.13]> <[e-mail]>
X-Mailer: Eudora for Mac OS X (dev alpha)
X-message-flag: Warning: Outlook in use.  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 22 Aug 2006 15:42:19 -0700
To: Alexey Melnikov <[e-mail]>, Randall Gellens <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Cc: Matthew Elvey <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
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>

At 9:29 PM +0100 8/21/06, Alexey Melnikov wrote:

>  Randall Gellens wrote:
>
>>  (1) The document should make clear in the Abstract that it is 
>> updating the existing "Reject" action.
>
>  Done. I've changed the first sentence of the Abstract to read:
>
>    This memo updates definition the SIEVE mail filtering language 
> "reject" extension, originally defined in RFC 3028.

Thanks.

>
>>  (2) I suggest adding "The message is rejected after end of data" 
>> to the end of the Abstract.
>
>  Do you mean after the DATA command? I don't think we should limit 
> reject to post-DATA case only, several people have expressed desire 
> to use it at RCPT TO: time.

 From reading the draft, my impression was that it was for use after 
end-of-data.  Perhaps instead of saying "The message is rejected 
after end of data", say "The intent is to reject messages during the 
SMTP transaction based on the message's characteristics, for example, 
its recipient(s) or its data."

>
>>  (6) What is the rational for item 1 on the action list in Section 
>> 3.1 (as opposed to rejecting even if the MAIL FROM is null)?
>
>  You have a point. If protocol level rejection is available, the 
> recipient might just reject the message. For DSNs/MDNs, the server 
> just "MUST NOT generate" them, right?

I meant, why require that messages with a null MAIL FROM be accepted 
and discarded?  Why not just fail the transaction?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Get your facts first, and then you can distort them as much as you please.
--Mark Twain



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7MEjuY3077151; Tue, 22 Aug 2006 07:45:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7MEjuUV077150; Tue, 22 Aug 2006 07:45:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7MEjpvo077110 for <[e-mail]>; Tue, 22 Aug 2006 07:45:55 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 15:45:45 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 15:45:06 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: managesieve and require
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>

Arnt Gulbrandsen wrote:

> Hi,
>
> are there any managesieve implementations around that'll flag an error 
> if a script uses extension x, but doesn't list x using "require"?

Yes, Cyrus/Isode does this.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7METbNl072656; Tue, 22 Aug 2006 07:29:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7METbLh072655; Tue, 22 Aug 2006 07:29:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7METYHT072621 for <[e-mail]>; Tue, 22 Aug 2006 07:29:37 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A7ADA4ADC3; Tue, 22 Aug 2006 16:29:33 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 22 Aug 2006 16:29:33 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: managesieve and require
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
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,

are there any managesieve implementations around that'll flag an error 
if a script uses extension x, but doesn't list x using "require"?

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7MA02rH001781; Tue, 22 Aug 2006 03:00:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7MA02Eh001780; Tue, 22 Aug 2006 03:00:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7MA019V001763 for <[e-mail]>; Tue, 22 Aug 2006 03:00:02 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 10:59:58 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 10:59:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Arnt Gulbrandsen <[e-mail]>
Subject: Re: Sieve reject action and environment test extension
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>

Arnt Gulbrandsen wrote:

>> So I would like to poll the WG regarding the following:
>>
>> 1). Does the WG has enough information to decide if this is a 
>> reasonable suggestion?
>
> Perhaps.
>
>> 2). If the answer to #1 is yes, does the WG want to delay publication 
>> of reject until after the environment extension is done, or is it Ok 
>> to submit it to IESG sooner?
>
> No.

Arnt clarified that he means "no, don't delay the reject document".



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7M9nqVf099086; Tue, 22 Aug 2006 02:49:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7M9nqeI099085; Tue, 22 Aug 2006 02:49:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7M9nnv0099070 for <[e-mail]>; Tue, 22 Aug 2006 02:49:51 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 10:49:44 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 10:49:18 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: Sieve reject action and environment test extension
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>

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> After thinking more about comments received regarding the reject 
>> draft, I would propose that instead of adding options to reject that 
>> would make it behave "do X if able to reject message over protocol 
>> and nothing otherwise" (originally proposed by Kejtil, if I am not 
>> mistaken), we should define proper Sieve environment test extension. 
>> The extension should define something for testing if Sieve engine is 
>> running in MTA/MDA, versa running in MDA.
>
> That's not equivalent. The equivalent would be "is sieve engine 
> running in MTA/MDA, and do all recipients of this invoke the reject 
> action?". 

Yes, I meant this. Actually both "can reject over protocol" and "running 
in MTA/MDA" can be interesting for Sieve scripts.

> That seems a little odd for an enviroment test extension. If course 
> it's possible to simplify a little and ask e.g. "is sieve engine 
> running in MTA/MDA, and is this a single-recipient message?" which 
> still seems out of scope for an environment test.

I think it is close enough. I would certainly not like to invent a new 
environment-like mechanism just for reject.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7M9dv6E095646; Tue, 22 Aug 2006 02:39:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7M9dviq095645; Tue, 22 Aug 2006 02:39:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7M9dtaY095628 for <[e-mail]>; Tue, 22 Aug 2006 02:39:57 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (unknown [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E2D384ADBB; Tue, 22 Aug 2006 11:15:49 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 22 Aug 2006 11:15:44 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Sieve reject action and environment test extension
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
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>

Alexey Melnikov writes:
> After thinking more about comments received regarding the reject 
> draft, I would propose that instead of adding options to reject that 
> would make it behave "do X if able to reject message over protocol 
> and nothing otherwise" (originally proposed by Kejtil, if I am not 
> mistaken), we should define proper Sieve environment test extension. 
> The extension should define something for testing if Sieve engine is 
> running in MTA/MDA, versa running in MDA.

That's not equivalent. The equivalent would be "is sieve engine running 
in MTA/MDA, and do all recipients of this invoke the reject action?". 
That seems a little odd for an enviroment test extension. If course 
it's possible to simplify a little and ask e.g. "is sieve engine 
running in MTA/MDA, and is this a single-recipient message?" which 
still seems out of scope for an environment test.

> So I would like to poll the WG regarding the following:
>
> 1). Does the WG has enough information to decide if this is a 
> reasonable suggestion?

Perhaps.

> 2). If the answer to #1 is yes, does the WG want to delay publication 
> of reject until after the environment extension is done, or is it Ok 
> to submit it to IESG sooner?

No.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7LKen9A004928; Mon, 21 Aug 2006 13:40:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7LKenjF004927; Mon, 21 Aug 2006 13:40:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7LKemDF004920 for <[e-mail]>; Mon, 21 Aug 2006 13:40:48 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 21:40:45 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 21:40:22 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Sieve reject action and environment test extension
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>

After thinking more about comments received regarding the reject draft, 
I would propose that instead of adding options to reject that would make 
it behave "do X if able to reject message over protocol and nothing 
otherwise" (originally proposed by Kejtil, if I am not mistaken), we 
should define proper Sieve environment test extension. The extension 
should define something for testing if Sieve engine is running in 
MTA/MDA, versa running in MDA.

So I would like to poll the WG regarding the following:

1). Does the WG has enough information to decide if this is a reasonable 
suggestion?
2). If the answer to #1 is yes, does the WG want to delay publication of 
reject until after the environment extension is done, or is it Ok to 
submit it to IESG sooner?

Alexey

P.S. If the answer to #2 is "delay reject until after the environment 
draft", then we need to push out the milestone for the reject.
But of course this should have no influence on answers to the 2 
questions mentioned above.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7LKTkXX002374; Mon, 21 Aug 2006 13:29:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7LKTkAj002373; Mon, 21 Aug 2006 13:29:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7LKThPm002357 for <[e-mail]>; Mon, 21 Aug 2006 13:29:44 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 21:29:26 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 21:29:02 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Randall Gellens <[e-mail]>
CC: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
References: <p0630000cc0ec03ea5a83@[192.168.1.13]>
In-Reply-To: <p0630000cc0ec03ea5a83@[192.168.1.13]>
MIME-version: 1.0
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>

Randall Gellens wrote:

> (1) The document should make clear in the Abstract that it is updating 
> the existing "Reject" action.

Done. I've changed the first sentence of the Abstract to read:

   This memo updates definition the SIEVE mail filtering language 
"reject" extension, originally defined in RFC 3028.

> (2) I suggest adding "The message is rejected after end of data" to 
> the end of the Abstract.

Do you mean after the DATA command? I don't think we should limit reject 
to post-DATA case only, several people have expressed desire to use it 
at RCPT TO: time.

> (6) What is the rational for item 1 on the action list in Section 3.1 
> (as opposed to rejecting even if the MAIL FROM is null)?

You have a point. If protocol level rejection is available, the 
recipient might just reject the message. For DSNs/MDNs, the server just 
"MUST NOT generate" them, right?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7LK54wF097037; Mon, 21 Aug 2006 13:05:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7LK53Av097036; Mon, 21 Aug 2006 13:05:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7LK52n0097029 for <[e-mail]>; Mon, 21 Aug 2006 13:05:03 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 21:05:00 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 21:04:39 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Escaping non-UTF-8 in Sieve scripts: part of 3028bis or separate?
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>

Resending, as the original message was by mistake only BCCed to the 
Sieve mailing list.
====

According to discussion that followed IETF in Montreal it seems that WG
members want to work on escape mechanism for characters in charsets
other than UTF-8.

I would like to measure WG consensus regarding:
1). if my statement above is true.
2). if the answer to #1 is Yes, then: should this be done as separate
draft or in 3028bis.
=======
Chair hat off (my personal preferences):
Yes, I think the WG should work on this, but I think this should not
delay 3028bis any longer. However I would like to see a proposal before
sending 3028bis to IESG.

Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7LK3aYT096756; Mon, 21 Aug 2006 13:03:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7LK3af1096755; Mon, 21 Aug 2006 13:03:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7LK3Xam096740 for <[e-mail]>; Mon, 21 Aug 2006 13:03:35 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 21:03:30 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 21:03:09 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: undisclosed-recipients:;
Subject: Escaping non-UTF-8 in Sieve scripts: part of 3028bis or separate?
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>

According to discussion that followed IETF in Montreal it seems that WG 
members want to work on escape mechanism for characters in charsets 
other than UTF-8.

I would like to measure WG consensus regarding:
1). if my statement above is true.
2). if the answer to #1 is Yes, then: should this be done as separate 
draft or in 3028bis.
=======
Chair hat off (my personal preferences):
Yes, I think the WG should work on this, but I think this should not 
delay 3028bis any longer. However I would like to see a proposal before 
sending 3028bis to IESG.

Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ECtN4c093433; Mon, 14 Aug 2006 05:55:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7ECtNjE093432; Mon, 14 Aug 2006 05:55:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ECtM6Z093416 for <[e-mail]>; Mon, 14 Aug 2006 05:55:22 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 14 Aug 2006 13:55:09 +0100
Message-ID: <[e-mail]>
Date: Mon, 14 Aug 2006 13:55:04 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Randall Gellens <[e-mail]>
CC: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
References: <p0630000cc0ec03ea5a83@[192.168.1.13]> <[e-mail]> <p06300001c0f6a5e124ee@[129.46.172.15]>
In-Reply-To: <p06300001c0f6a5e124ee@[129.46.172.15]>
MIME-version: 1.0
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>

Randall Gellens wrote:

> At 7:18 PM +0100 8/2/06, Alexey Melnikov wrote:
>
>>>  (13) In Section 3.2, should there be any discussion of priority, 
>>> for example, if both vacation and reject are attempted, do the 
>>> reject and not the vacation?
>>
>> reject and vacation are not allowed together, as per section 3.3.
>
> They are not allowed together, but what happens to a script that tries 
> it?  Is it a run-time error, or is one of the actions performed but 
> not the other?

When actions are incompatible, this always result in runtime error. Do 
you think 3028bis is unclear on this?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7EAL2oi002793; Mon, 14 Aug 2006 03:21:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7EAL27X002792; Mon, 14 Aug 2006 03:21:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7EAKv5n002728 for <[e-mail]>; Mon, 14 Aug 2006 03:21:01 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 14 Aug 2006 11:20:36 +0100
Message-ID: <[e-mail]>
Date: Sun, 13 Aug 2006 13:27:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Randall Gellens <[e-mail]>
CC: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
References: <p0630000cc0ec03ea5a83@[192.168.1.13]>
In-Reply-To: <p0630000cc0ec03ea5a83@[192.168.1.13]>
MIME-version: 1.0
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>

Randall Gellens wrote:

> (1) The document should make clear in the Abstract that it is updating 
> the existing "Reject" action.

Done. I've changed the first sentence of the Abstract to read:

   This memo updates definition the SIEVE mail filtering language 
"reject" extension, originally defined in RFC 3028.

> (2) I suggest adding "The message is rejected after end of data" to 
> the end of the Abstract.

Do you mean after the DATA command? I don't think we should limit reject 
to post-DATA case only, several people have expressed desire to use it 
at RCPT TO: time.

> (6) What is the rational for item 1 on the action list in Section 3.1 
> (as opposed to rejecting even if the MAIL FROM is null)?

You have a point. If protocol level rejection is available, the 
recipient might just reject the message. For DSNs/MDNs, the server just 
"MUST NOT generate" them, right?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7BAdhSL000421; Fri, 11 Aug 2006 03:39:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7BAdh0B000420; Fri, 11 Aug 2006 03:39:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7BAdfhl000391 for <[e-mail]>; Fri, 11 Aug 2006 03:39:42 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1GBUQW-0006iQ-As for [e-mail]; Fri, 11 Aug 2006 12:39:40 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62 #2) id 1GBUQW-0005Ke-9W for [e-mail]; Fri, 11 Aug 2006 12:39:40 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GBUQW-0000o4-0B for [e-mail]; Fri, 11 Aug 2006 12:39:40 +0200
Date: Fri, 11 Aug 2006 12:39:39 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: OT: Are mailto URI argument names caseful?
Message-ID: <[e-mail]>
References: <[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.5.6i
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,

recently I asked concerning the case of arguments to mailto URIs and
promised to summarise.  Thanks a lot for all answers!

Everybody agrees that the hname part of the argument should be case
insensitive.

RFC 2822 does not state that fact explicitly, but says all character
literals given as quoted strings are case-insensitive.  It proceeds
to specify all field names and header fields as quoted strings.  As a
result, field names don't have to be case insensitive as such, but all
field names within the scope of RFC 2822 are for sure and I never heard
of a field specified differently.

By now I got a late answer from the authors of the draft, acknowledging
the field names used in the draft are meant to be case insensitive.
I suggested to state it explicitly nevertheless, because the draft
also uses the special string "body", which is not (yet) a registered
field name.

I asked:

> Who will get a message resulting from the URI below and how will it
> look like?

> mailto:?to=[e-mail]&TO=[e-mail]

The answer is: The message will go to both recipients and it will contain
one "To:" field, listing both.  The implementation is obviously free to
change the field name case and add a space after the colon, a fact that
should be specified clearly, too.

Sometimes things just work the way you expect them to. :-)

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77JoCN5029487; Mon, 7 Aug 2006 12:50:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k77JoC6H029484; Mon, 7 Aug 2006 12:50:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77Jo9QY029411 for <[e-mail]>; Mon, 7 Aug 2006 12:50:11 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8595832884; Mon,  7 Aug 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAB6w-0006Gv-Dw; Mon, 07 Aug 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-3028bis-09.txt 
Message-Id: <[e-mail]>
Date: Mon, 07 Aug 2006 15:50:02 -0400
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>

--NextPart

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

	Title		: Sieve: An Email Filtering Language
	Author(s)	: T. Showalter, P. Guenther
	Filename	: draft-ietf-sieve-3028bis-09.txt
	Pages		: 40
	Date		: 2006-8-7
	
This document describes a language for filtering email messages at
time of final delivery.  It is designed to be implementable on either
a mail client or mail server.  It is meant to be extensible, simple,
and independent of access protocol, mail architecture, and operating
system.  It is suitable for running on a mail server where users may
not be allowed to execute arbitrary programs, such as on black box
Internet Message Access Protocol (IMAP) servers, as it has no
variables, loops, or ability to shell out to external programs.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-3028bis-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-3028bis-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-3028bis-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-3028bis-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77JoCeN029486; Mon, 7 Aug 2006 12:50:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k77JoCP3029483; Mon, 7 Aug 2006 12:50:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77Jo9T9029410 for <[e-mail]>; Mon, 7 Aug 2006 12:50:11 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4992E32867; Mon,  7 Aug 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAB6w-0006GR-4o; Mon, 07 Aug 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-body-04.txt 
Message-Id: <[e-mail]>
Date: Mon, 07 Aug 2006 15:50:02 -0400
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>

--NextPart

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

	Title		: Sieve Email Filtering: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-04.txt
	Pages		: 12
	Date		: 2006-8-7
	
This document defines a new primitive for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-body-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-body-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-body-04.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77JoAEq029455; Mon, 7 Aug 2006 12:50:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k77JoAZZ029454; Mon, 7 Aug 2006 12:50:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77Jo76f029409 for <[e-mail]>; Mon, 7 Aug 2006 12:50:09 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3E24C26E1E; Mon,  7 Aug 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAB6w-0006GO-42; Mon, 07 Aug 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-editheader-06.txt 
Message-Id: <[e-mail]>
Date: Mon, 07 Aug 2006 15:50:02 -0400
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>

--NextPart

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

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-06.txt
	Pages		: 9
	Date		: 2006-8-7
	
This document defines two new actions for the "Sieve" email
   filtering language that add and delete email header fields.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-editheader-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-editheader-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-editheader-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-editheader-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77D1ATw005204; Mon, 7 Aug 2006 06:01:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k77D1AOm005203; Mon, 7 Aug 2006 06:01:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77D17re005182 for <[e-mail]>; Mon, 7 Aug 2006 06:01:09 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1GA4j9-00036L-Vo for [e-mail]; Mon, 07 Aug 2006 15:01:03 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62 #2) id 1GA4j9-0001y4-Us for [e-mail]; Mon, 07 Aug 2006 15:01:03 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GA4j7-0004Sw-AN for [e-mail]; Mon, 07 Aug 2006 15:01:01 +0200
Date: Mon, 07 Aug 2006 15:01:01 +0200
To: [e-mail]
Subject: OT: Are mailto URI argument names caseful?
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[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,

I am currently working on mailto notifications (so I am not entirely
off-topic;) and came accross a problem:

Are argument hnames in the query part of mailto URIs caseful?

RFC 2368 does not tell if the argument hnames resulting from splitting
the query part into pieces are caseful or not.  Neither does
draft-duerst-mailto-bis-02.  I did not get a response from asking the
authors.

In general, RFCs describing specific schemes must state if anything
is to be considered caseless.  Nothing is said -> caseful.

Hnames are caseless -> caseless.

Who will get a message resulting from the URI below and how will it
look like?

mailto:?to=[e-mail]&TO=[e-mail]

Using caseful names, the message would go to [e-mail], but
listing both recipients in the header, in case the client trusts the
message.  In case it does not and allows only safe headers, the message
would go to [e-mail] and only listing that address in the header.

Any hints towards references I overlooked will be appreciated.
Please respond by private mail and I will summarise.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77Blvos080166; Mon, 7 Aug 2006 04:47:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k77Blvuh080165; Mon, 7 Aug 2006 04:47:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77BluGF080159 for <[e-mail]>; Mon, 7 Aug 2006 04:47:57 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k77BlhBZ031371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Aug 2006 04:47:44 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k77BlhBZ031371
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1154951269; bh=/tqgjN+Rb11WFtwz31JfA+e9ryc=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=frLPNMmLeMuqOB0Z F4akHbVMAUK1KsP2Ye1NxWGWBPn2US7t1tFg+95/oWQ4G/okJ/5WI587P8ogOC9gac2 vUL93PJhnaUsWKC6CbPL9LFk+d9N3Om0BoDYg91Oy70NfEUesOuyWWiosl1rGNjztle AXPfvsC6iBec4H7ds83bE=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k77BlhBZ031371
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=IpjaVDZPIBPP5+i4whycvrMs8Ut1ilkfG7nTuhTtZY+X9QZVAfNY1CJXWaLDdWAJg lWUIOMKTum0uHDgLxoZlKkW/xw/DCx6TyCyPDdb1HhmHvYs3mkRZy/pFGloTTWwmI6L 00NrjcJU2JFSqrHbbvsuQcKSgxyWiwxBjqVqEgM=
Date: Mon, 7 Aug 2006 04:47:43 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
cc: [e-mail]
Subject: Re: draft-ietf-sieve-3028bis-08.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[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>

On Tue, 25 Jul 2006, Kjetil Torgrim Homme wrote:
> On Tue, 2006-07-25 at 07:46 -0700, Philip Guenther wrote:
...
>>    to US-ASCII characters.  Strings and comments may contain octets
>>    outside the US-ASCII range.  Specifically, they will normally be in
>>    UTF-8, as specified in [UTF-8].  NUL (US-ASCII 0) is never permitted
>>    in scripts, while CR and LF can only appear as the CRLF line ending.
>
> "normally" isn't good if you can't know if your script is normal or not.

...thus the text I added to 2.4.2 giving examples of when a script might 
include non-UTF-8 text.  Given the exact cases mentioned, I think 
"normally" is a reasonable word to use.  Other email RFCs (1894, 2822, 
3463, 3834, 3898) certainly haven't had problems with using it to describe 
situations where a strict rule can't be drawn but setting the reader's 
expectations is useful.


> I suggest you rephrase it as "Strings and comments may sometimes have a
> different encoding than UTF-8, so for consistent behaviour across
> implementations, it is recommended to avoid non US-ASCII".  (yes, tongue
> is firmly in cheek.)

But that's not what we're saying.  We expect consistent handling of these 
strings across implementations.  Thus the "MUST accept" in 2.4.2.


> speaking of CRLF, I'd like a clarification of multi-line strings in
> section 2.4.2 (some of its text duplicates the above, I'm not sure
> that's good).  something like:
>
>   Any CRLF before the final period are considered part of the string.

How about "The CRLF before the final period is considered part of the 
string.", inserted into the penultimate paragraph of section 2.4.2?


> to make it a little more clear that implementations should NOT change
> the CRLF into its local line delimiter sequence.

I don't understand what this has to do with the text you suggested.  Could 
you clarify what behavior you think the document should require or ban?


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k773pVtq022213; Sun, 6 Aug 2006 20:51:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k773pVfP022211; Sun, 6 Aug 2006 20:51:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k773pQfv022181 for <[e-mail]>; Sun, 6 Aug 2006 20:51:30 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 6 Aug 2006 20:51:21 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1154922680; h=Date: 	 From:Subject:MIME-version:Content-type; b=H2pqgmELKOxkYAAc71S44osxl 8tmTT00xjRNZ+Ok/JXuVoZ4/3+qWBe9Dcs2rrY/YHz2UvN8rExXHAPUncI1uQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 06 Aug 2006 20:51:17 -0700 (PDT)
Cc: Philip Guenther <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 06 Aug 2006 20:51:08 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Multiple tagged arguments with the same tag?
In-reply-to: "Your message dated Mon, 07 Aug 2006 01:19:08 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[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 Sun, 2006-08-06 at 16:06 -0700, Philip Guenther wrote:
> > On Tue, 25 Jul 2006, Kjetil Torgrim Homme wrote:
> > ...
> > > okay.  the current draft also says "These next tokens [after the tagged
> > > argument] may be numbers or strings but they are never blocks."  this
> > > seems to imply string lists are allowed, but it's not quite clear to me.
> >
> > For the next revision, I've changed section 2.4 to include string lists as
> > literal data and 2.6.2p2 to say "These next tokens may be literal data but
> > they are never blocks."
> >
> > I believe that captures the intent of this discussion, no?

> sounds good to me, thanks!

Me too.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k76NJduS030824; Sun, 6 Aug 2006 16:19:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k76NJdtL030823; Sun, 6 Aug 2006 16:19:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k76NJPZa030787 for <[e-mail]>; Sun, 6 Aug 2006 16:19:38 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1G9rty-0000Vw-6O; Mon, 07 Aug 2006 01:19:22 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G9rtq-0004Ac-6Z; Mon, 07 Aug 2006 01:19:14 +0200
Subject: Re: Multiple tagged arguments with the same tag?
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 07 Aug 2006 01:19:08 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.859, required 12, autolearn=disabled, AWL 0.14, 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 Sun, 2006-08-06 at 16:06 -0700, Philip Guenther wrote:
> On Tue, 25 Jul 2006, Kjetil Torgrim Homme wrote:
> ...
> > okay.  the current draft also says "These next tokens [after the tagged
> > argument] may be numbers or strings but they are never blocks."  this
> > seems to imply string lists are allowed, but it's not quite clear to me.
> 
> For the next revision, I've changed section 2.4 to include string lists as 
> literal data and 2.6.2p2 to say "These next tokens may be literal data but 
> they are never blocks."
> 
> I believe that captures the intent of this discussion, no?

sounds good to me, thanks!
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k76N6gGp027258; Sun, 6 Aug 2006 16:06:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k76N6gYj027257; Sun, 6 Aug 2006 16:06:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k76N6dNX027245 for <[e-mail]>; Sun, 6 Aug 2006 16:06:40 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k76N6VI3030444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Aug 2006 16:06:32 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k76N6VI3030444
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1154905593; bh=hEDakbGi3U0NAuobOaUOmDvqTps=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=Dxpakqd0wrFhFIG7 j3Jj5X/vhJFs1BJ6PhxXoAYBfi3ar6+mBUOUuJgndPeYQK89MPKpu7CSx9UVSv9NHxR pZ9D9Xiitp+m59q80aRq6PAIHmaj49BGIkSLuIJFcNZKdCAhFodTfc+SRLLk5SKVUop AfVGfyZf4+qVL55PqCMbs=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k76N6VI3030444
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=tYgXafjROcSkVAFCn2/MpQwJdkye2A0v4mL73aci/5trNv7ydz4jhRMeFV8WXqSQG 2+xrXUjyBM/d2DbyOY/1rVdPgAIuMQH3wQ6CNHm40g4I70qI3IoGOE45tiZ2ipd8stt YDW6kPYCLsddsSU/3R+4yvaqu2eYXf0qiedBXAY=
Date: Sun, 6 Aug 2006 16:06:31 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
cc: [e-mail]
Subject: Re: Multiple tagged arguments with the same tag?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[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>

On Tue, 25 Jul 2006, Kjetil Torgrim Homme wrote:
...
> okay.  the current draft also says "These next tokens [after the tagged
> argument] may be numbers or strings but they are never blocks."  this
> seems to imply string lists are allowed, but it's not quite clear to me.

For the next revision, I've changed section 2.4 to include string lists as 
literal data and 2.6.2p2 to say "These next tokens may be literal data but 
they are never blocks."

I believe that captures the intent of this discussion, no?


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k72Ivvvp031213; Wed, 2 Aug 2006 11:57:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k72Ivvff031212; Wed, 2 Aug 2006 11:57:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k72IvsNe031183 for <[e-mail]>; Wed, 2 Aug 2006 11:57:57 -0700 (MST) (envelope-from [e-mail])
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k72IvlNx027266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 11:57:48 -0700
Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72IvaHS012197; Wed, 2 Aug 2006 11:57:43 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300001c0f6a5e124ee@[129.46.172.15]>
In-Reply-To: <[e-mail]>
References: <p0630000cc0ec03ea5a83@[192.168.1.13]> <[e-mail]>
X-Mailer: Eudora for Mac OS X (dev alpha)
X-message-flag: Warning: Outlook in use.  Upgrade to Eudora: <http://www.eudora.com>
Date: Wed, 2 Aug 2006 11:57:32 -0700
To: Alexey Melnikov <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Cc: Matthew Elvey <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
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>

At 7:18 PM +0100 8/2/06, Alexey Melnikov wrote:

>>  (13) In Section 3.2, should there be any discussion of priority, 
>> for example, if both vacation and reject are attempted, do the 
>> reject and not the vacation?
>
>  reject and vacation are not allowed together, as per section 3.3.

They are not allowed together, but what happens to a script that 
tries it?  Is it a run-time error, or is one of the actions performed 
but not the other?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
It is the business of the future to be dangerous.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k72IJnEs023911; Wed, 2 Aug 2006 11:19:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k72IJngE023910; Wed, 2 Aug 2006 11:19:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k72IJmnl023903 for <[e-mail]>; Wed, 2 Aug 2006 11:19:49 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 2 Aug 2006 19:19:05 +0100
Message-ID: <[e-mail]>
Date: Wed, 02 Aug 2006 19:18:44 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Randall Gellens <[e-mail]>
CC: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
References: <p0630000cc0ec03ea5a83@[192.168.1.13]>
In-Reply-To: <p0630000cc0ec03ea5a83@[192.168.1.13]>
MIME-version: 1.0
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>

Randy, thank you for the comments! I am replying to the easy comments 
first...

Randall Gellens wrote:

> (3) Typo in Abstract and also Section 1: "updates definition" should 
> be "updates the definition".

Fixed.

> (4) Suggested change in Section 1: change "sometimes preferable" to 
> "generally preferable".

Changed.

> (5) Typos (grammatical errors) in Section 3.1:
>
> Old:
>    How message is refused depends
>    on capabilities of mail component (MUA, MDA or MTA) executing the
>    Sieve script. The Sieve interpreter must do one of the following
>    actions, as detailed by the following priority table (items listed
>    earlier take precedence). Note that if action can not be taken or
>    fails, the interpreter should try the next item in the list:
>
> New:
>    How a message is refused depends
>    on the capabilities of the mail component (MUA, MDA or MTA) 
> executing the
>    Sieve script. The Sieve interpreter must do one of the following
>    actions, as detailed by the following priority table (items listed
>    earlier take precedence). Note that if an action can not be taken or
>    fails, the interpreter should try the next item in the list:

Fixed.

> (7) Typo in Section 3.1.1: "at SMTP/LMTP level" should be "at the 
> SMTP/LMTP level".

Fixed.

> (8) My suggestion for the open issue in 3.1.1 would be to require 
> ASCII, since it is the most interoperable.  A future extension can 
> permit UTF-8 after wider deployment of EAI extensions.  That means 
> Sieve should enforce ASCII in the use of 'Reject'.  Replacing UTF-8 
> with "?" is a kludge that is likely to confuse users and lead to 
> undesirable results.  Making it a syntax error seems the way to go, as 
> users will be immediately notified, and clients that generate Sieve 
> scripts can guide users.
>
> (9) Typo in Section 3.1.1: "delay immediate sending" should be "delay 
> immediately sending".

Fixed.

> (10) Typo in Section 3.1.3: "When Sieve engine is running inside MUA" 
> should be "When the Sieve engine is running inside the MUA".

Fixed.

> (11) Missing blank line in Section 3.1.3, before sentence starting 
> "MTAs and MDAs SHOULD NOT".

Added.

> (12) Typo in Section 3.1.3: "reject at protocol level" should be 
> "reject at the protocol level".

Fixed.

> (13) In Section 3.2, should there be any discussion of priority, for 
> example, if both vacation and reject are attempted, do the reject and 
> not the vacation?

reject and vacation are not allowed together, as per section 3.3.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k721nXW2032006; Tue, 1 Aug 2006 18:49:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k721nXqq032005; Tue, 1 Aug 2006 18:49:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k721nT9Q031972 for <[e-mail]>; Tue, 1 Aug 2006 18:49:32 -0700 (MST) (envelope-from [e-mail])
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k721nNXK025328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2006 18:49:23 -0700
Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k721nLld023985; Tue, 1 Aug 2006 18:49:22 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630000dc0f5b3b5579e@[129.46.172.15]>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 1 Aug 2006 18:49:16 -0700
To: Alexey Melnikov <[e-mail]>, Matthew Elvey <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Review of draft-ietf-sieve-refuse-reject-03
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
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>

My comments on -02 apply to -03, with one extra:

Is the exacttext option worth it?  It seems to be adding a lot of 
complexity for fairly small gain.  I understand users wanting to put 
reject reasons in their native language.  However, the intent of this 
draft is that reject will operate at the SMTP level wherever 
possible.  Hence, the reject reason should be very short and must be 
usable in an SMTP response.  Use of ASCII is best for 
interoperability.  Use of UTF-8 will only work when EAI extensions 
are also being used, or when MDNs are being generated instead of SMTP 
protocol responses.  Since EAI is new, I don't think we want to rely 
on it.  And the intent is to get away from MDNs.  Hence, we should 
encourage brevity and mandate ASCII.

Once EAI extensions are deployed we can extend reject to permit UTF-8.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There are two ways to write error-free programs;
only the third one works.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k71NToPL004358; Tue, 1 Aug 2006 16:29:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k71NToah004356; Tue, 1 Aug 2006 16:29:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k71NTiJv004296 for <[e-mail]>; Tue, 1 Aug 2006 16:29:49 -0700 (MST) (envelope-from [e-mail])
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k71NTbmO004382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2006 16:29:38 -0700
Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k71NTZdq014941; Tue, 1 Aug 2006 16:29:36 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630000cc0ec03ea5a83@[192.168.1.13]>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 1 Aug 2006 16:26:35 -0700
To: Alexey Melnikov <[e-mail]>, Matthew Elvey <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Review of draft-ietf-sieve-refuse-reject-02
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
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) The document should make clear in the Abstract that it is 
updating the existing "Reject" action.

(2) I suggest adding "The message is rejected after end of data" to 
the end of the Abstract.

(3) Typo in Abstract and also Section 1: "updates definition" should 
be "updates the definition".

(4) Suggested change in Section 1: change "sometimes preferable" to 
"generally preferable".

(5) Typos (grammatical errors) in Section 3.1:

Old:
    How message is refused depends
    on capabilities of mail component (MUA, MDA or MTA) executing the
    Sieve script. The Sieve interpreter must do one of the following
    actions, as detailed by the following priority table (items listed
    earlier take precedence). Note that if action can not be taken or
    fails, the interpreter should try the next item in the list:

New:
    How a message is refused depends
    on the capabilities of the mail component (MUA, MDA or MTA) executing the
    Sieve script. The Sieve interpreter must do one of the following
    actions, as detailed by the following priority table (items listed
    earlier take precedence). Note that if an action can not be taken or
    fails, the interpreter should try the next item in the list:

(6) What is the rational for item 1 on the action list in Section 3.1 
(as opposed to rejecting even if the MAIL FROM is null)?

(7) Typo in Section 3.1.1: "at SMTP/LMTP level" should be "at the 
SMTP/LMTP level".

(8) My suggestion for the open issue in 3.1.1 would be to require 
ASCII, since it is the most interoperable.  A future extension can 
permit UTF-8 after wider deployment of EAI extensions.  That means 
Sieve should enforce ASCII in the use of 'Reject'.  Replacing UTF-8 
with "?" is a kludge that is likely to confuse users and lead to 
undesirable results.  Making it a syntax error seems the way to go, 
as users will be immediately notified, and clients that generate 
Sieve scripts can guide users.

(9) Typo in Section 3.1.1: "delay immediate sending" should be "delay 
immediately sending".

(10) Typo in Section 3.1.3: "When Sieve engine is running inside MUA" 
should be "When the Sieve engine is running inside the MUA".

(11) Missing blank line in Section 3.1.3, before sentence starting 
"MTAs and MDAs SHOULD NOT".

(12) Typo in Section 3.1.3: "reject at protocol level" should be 
"reject at the protocol level".

(13) In Section 3.2, should there be any discussion of priority, for 
example, if both vacation and reject are attempted, do the reject and 
not the vacation?





-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Premature optimization is the root of all evil
                              --C. A. R. Hoare



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k71FYHSC011878; Tue, 1 Aug 2006 08:34:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k71FYH4H011877; Tue, 1 Aug 2006 08:34:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k71FYEeX011835 for <[e-mail]>; Tue, 1 Aug 2006 08:34:17 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7FAED32871; Tue,  1 Aug 2006 15:34:09 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G7dm5-0007Yh-PI; Mon, 31 Jul 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-refuse-reject-03.txt 
Message-Id: <[e-mail]>
Date: Mon, 31 Jul 2006 15:50:01 -0400
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>

--NextPart

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

	Title		: The SIEVE mail filtering language - reject extension
	Author(s)	: M. Elvey, A. Melnikov
	Filename	: draft-ietf-sieve-refuse-reject-03.txt
	Pages		: 0
	Date		: 2006-7-31
	
This memo defines the SIEVE mail filtering language (RFC
   <<3028bis>>) "reject" extension.
   
   A Joe-job is a spam run forged to appear as though it came from an
   innocent party, who is then generally flooded by the bounces,
   Message Disposition Notifications (MDNs) and messages with
   complaints.  The original Sieve "reject" action defined in RFC 3028
   required use of MDNs for rejecting messages, thus contributing to
   the flood of Joe-job spam to victims of Joe-jobs.  This document
   updates definition of "reject" to require rejecting messages during
   the SMTP transaction (instead of accepting them and then sending
   MDNs back to the alleged sender) wherever possible, thereby
   reducing the problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-refuse-reject-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-refuse-reject-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-refuse-reject-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-refuse-reject-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--