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

From: Randall Gellens <[email-masked]>
Date: Tue, 1 Aug 2006 16:26:35 -0700

(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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Aug 2006 19:18:44 +0100

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

> be "updates the definition".

Fixed.

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

Changed.

>    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 

Fixed.

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

Fixed.

> should be "When the Sieve engine is running inside the MUA".

Fixed.

> "MTAs and MDAs SHOULD NOT".

Added.

> "reject at the protocol level".

Fixed.

> example, if both vacation and reject are attempted, do the reject and 

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 11:57:32 -0700

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

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 13 Aug 2006 13:27:57 +0100

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 

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.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Aug 2006 13:55:04 +0100

Randall Gellens wrote:

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Aug 2006 21:29:02 +0100

---

From: Randall Gellens <[email-masked]>
Date: Tue, 22 Aug 2006 15:42:19 -0700

> "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)?
>
> 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?

-------------- Randomly-selected tag: ---------------
Get your facts first, and then you can distort them as much as you please.
--Mark Twain

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Aug 2006 10:27:30 +0100

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

Date: Wed, 23 Aug 2006 10:27:30 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Sender: [email-masked]

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

Date: Tue, 22 Aug 2006 15:42:19 -0700
To: Alexey Melnikov <[email-masked]>, Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Cc: Matthew Elvey <[email-masked]>, [email-masked]
Sender: [email-masked]

Thanks.

-------------- Randomly-selected tag: ---------------

Date: Tue, 22 Aug 2006 15:45:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: managesieve and require
Sender: [email-masked]

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.

Date: Tue, 22 Aug 2006 16:29:33 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: managesieve and require
Sender: [email-masked]

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

Date: Tue, 22 Aug 2006 10:59:33 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Arnt Gulbrandsen <[email-masked]>
Subject: Re: Sieve reject action and environment test extension
Sender: [email-masked]

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

Date: Tue, 22 Aug 2006 10:49:18 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Sieve reject action and environment test extension
Sender: [email-masked]

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.

Date: Tue, 22 Aug 2006 11:15:44 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Sieve reject action and environment test extension
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 21 Aug 2006 21:40:22 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Sieve reject action and environment test extension
Sender: [email-masked]

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.

Date: Mon, 21 Aug 2006 21:29:02 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Sender: [email-masked]

Date: Mon, 21 Aug 2006 21:04:39 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Escaping non-UTF-8 in Sieve scripts: part of 3028bis or separate?
Sender: [email-masked]

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

Date: Mon, 21 Aug 2006 21:03:09 +0100
From: Alexey Melnikov <[email-masked]>
To: undisclosed-recipients:;
Subject: Escaping non-UTF-8 in Sieve scripts: part of 3028bis or separate?
Sender: [email-masked]

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

Date: Mon, 14 Aug 2006 13:55:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Sender: [email-masked]

Date: Sun, 13 Aug 2006 13:27:57 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Sender: [email-masked]

Date: Fri, 11 Aug 2006 12:39:39 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: OT: Are mailto URI argument names caseful?
Sender: [email-masked]

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=[email-masked]&TO=[email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-3028bis-09.txt 
Date: Mon, 07 Aug 2006 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve: 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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-body-04.txt 
Date: Mon, 07 Aug 2006 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve Email Filtering: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-06.txt 
Date: Mon, 07 Aug 2006 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 07 Aug 2006 15:01:01 +0200
To: [email-masked]
Subject: OT: Are mailto URI argument names caseful?
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

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=[email-masked]&TO=[email-masked]

Using caseful names, the message would go to [email-masked], 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 [email-masked] 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

Date: Mon, 7 Aug 2006 04:47:43 -0700
From: Philip Guenther <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
cc: [email-masked]
Subject: Re: draft-ietf-sieve-3028bis-08.txt
Sender: [email-masked]

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

Cc: Philip Guenther <[email-masked]>, [email-masked]
To: Kjetil Torgrim Homme <[email-masked]>
Date: Sun, 06 Aug 2006 20:51:08 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Multiple tagged arguments with the same tag?
Sender: [email-masked]

> 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

Subject: Re: Multiple tagged arguments with the same tag?
From: Kjetil Torgrim Homme <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked]
Date: Mon, 07 Aug 2006 01:19:08 +0200
Sender: [email-masked]

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.

Date: Sun, 6 Aug 2006 16:06:31 -0700
From: Philip Guenther <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
cc: [email-masked]
Subject: Re: Multiple tagged arguments with the same tag?
Sender: [email-masked]

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

Date: Wed, 2 Aug 2006 11:57:32 -0700
To: Alexey Melnikov <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Cc: Matthew Elvey <[email-masked]>, [email-masked]
Sender: [email-masked]

-------------- Randomly-selected tag: ---------------

Date: Wed, 02 Aug 2006 19:18:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Randall Gellens <[email-masked]>
CC: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-sieve-refuse-reject-02
Sender: [email-masked]

Fixed.

Changed.

Fixed.

Fixed.

Fixed.

Fixed.

Added.

Fixed.

Date: Tue, 1 Aug 2006 18:49:16 -0700
To: Alexey Melnikov <[email-masked]>, Matthew Elvey <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Review of draft-ietf-sieve-refuse-reject-03
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Tue, 1 Aug 2006 16:26:35 -0700
To: Alexey Melnikov <[email-masked]>, Matthew Elvey <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Review of draft-ietf-sieve-refuse-reject-02
Cc: [email-masked]
Sender: [email-masked]

Old:

New:

-------------- Randomly-selected tag: ---------------

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-refuse-reject-03.txt 
Date: Mon, 31 Jul 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--