Subject: I-D ACTION:draft-ietf-sieve-3028bis-00.txt

From: [email-masked]
Date: Mon, 09 May 2005 15:55:06 -0400

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)	: P. Guenther
	Filename	: draft-ietf-sieve-3028bis-00.txt
	Pages		: 39
	Date		: 2005-5-9
	
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-00.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-00.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-00.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.

---

From: Michael Haardt <[email-masked]>
Date: Tue, 10 May 2005 14:45:29 +0200

I guess that means the discussion is opened.  Here are my relevant notes
on RFC 3028.

Undefined Test Results

Implementations that use C-style strings will only evaluate the first
test as true.

Subject: =?iso-8859-1?q?abc=00def

header :contains "Subject" ["abc"]
header :contains "Subject" ["def"]
header :matches "Subject" ["abc?def"]

Note that by considering Sieve to be a MUA, RFC 2047 can be interpreted
in a way that NUL characters truncating strings is allowed for Sieve
implementations, although not recommended.  It is further allowed to use
encoded NUL characters in headers, but that's not recommended either.
The above example shows why.  RFC 3028 should say something about this issue.

Strings Containing Header Names Or Envelope Elements

RFC 3028 does not specify what happens if a string denoting a header field
or envelope element does not contain a valid name, e.g. it contains a
colon for a header or it is not "from" or "to" for envelopes.  I suggest
generating an error instead of ignoring the header field in order to
ease script debugging, which fits in the common picture of Sieve.

Header Test With Invalid MIME Encoding In Header

Some MUAs process invalid base64 encoded data, generating junk.
Others ignore junk after seeing an equal sign in base64 encoded data.
RFC 2047 does not specify how to react in this case, other than stating
that a client must not forbid to process a message for that reason.
RFC 2045 specifies that invalid data should be ignored (appearantly
looking at end of line characters).  It also specifies that invalid data
may lead to rejecting messages containing them (and there it appears to
talk about true encoding violations), which is a clear contradiction to
ignoring them.

RFC 3028 does not specify how to process incorrect MIME words.  I suggest
to treat them literally, as I do if the word is correct, but its character
set can not be converted to UTF-8.

Address Test For Multiple Addresses Per Header

A header may contain multiple addresses.  RFC 3028 does not explicitly
specify how to deal with them, but since the "address" test checks if
anything matches anything else, matching one address suffices to
satify the condition.  That makes it impossible to test if a header
contains a certain set of addresses and no more, but it is more logical
than letting the test fail if the header contains an additional address
besides the one the test checks for.

String Arguments

There has been confusion if the string arguments to "require" are to be
matched case-sensitive or not.  I suggest to match them with
the match type ":is" (default, see section 2.7.1) and the comparator
"i;ascii-casemap" (default, see section 2.7.3).  The RFC defines the
command defaults clearly, so any different implementations violate RFC
3028.  The same is valid for comparator names, also specified as strings.

Michael

---

From: Philip Guenther <[email-masked]>
Date: Tue, 10 May 2005 12:23:22 -0700

FYI, I have already submitted rev -01 incorporating the changes
discussed in Minneapolis.  I didn't roll them into my resubmission of
-00 to avoid confusing people about what it contained.

Responding to your comments out of order...

Michael Haardt <[email-masked]> writes:
...
>besides the one the test checks for.

Cyrus had forwarded your comment on this to me some time ago, so -01
includes this sentence in section 5.1:
	Whether there are other addresses present in the header doesn't
	affect this test; this test does not provide any way to
	determine whether an address is the only address in a header.

>3028.  The same is valid for comparator names, also specified as strings.

Since "require" is not described as taking MATCH-TYPE or COMPARATOR
arguments, I don't see how the defaults of sections 2.7.1 and 2.7.3 can
be read as applying.  Whether comparator names are case-sensitive is up
to the draft defining the collation registry: if it says they are, then
both comparator strings *and* the string argument to "require" *must* be
treated as case-sensitive so that all comparator names can be
specified.

According to draft-newman-i18n-comparator-03.txt, collation names may
contain both uppercase and lowercase letters.  I see nothing in the
draft that would have them treated as case-insensitive.  Given that, I
don't see how sieve can specify those strings to be case-insensitive.

>colon for a header or it is not "from" or "to" for envelopes.

Look closer.  2.4.2.2p2:
	A header name never contains a colon.  The "From" header refers
	to a line beginning "From:" (or "From   :", etc.).  No header
	will match the string "From:" due to the trailing colon.

As for "envelope", I think the current phrasing ("If one of the
envelope-part strings...") could be read to imply that envelope-part
strings other than "from" and "to" are simply ignored.  However, that's
certainly not as clear as 2.4.2.2's statement for bogus header names.

(Indeed, I just checked and Sendmail's implementation gives a syntax
error on envelope-part strings other than "from" and "to".)

>I suggest

<editor-hat off>
I am opposed to reversing the existing statement in 2.4.2.2, as the
existing text is quite clear and unambiguous.

I am mildly in support of making it an error for envelope as a
clarification, but think more people should speak to the point.
<editor-hat on>

>Undefined Test Results
..
>The above example shows why.  RFC 3028 should say something about this issue.
...
>set can not be converted to UTF-8.

Hmm.  To paraphrase (and mangle) something that Dave Crocker said at the
meeting in Minneapolis: when there's a spec for something, it's a bad
idea to try to address general problems arising from it anywhere but in
that spec.  He was speaking then to the question of whether the
'vacation' draft should go into the issues around permitting users to
set the "From" on outgoing messages, noting that this is a general issue
for mail submission and that 'vacation' should not try to apply a
point-fix to the problem, though a security consideration pointing at
the submission RFC would be appropriate.

I think the same logic applies here.  The MIME RFCs describe the issues;
the sieve spec should simply include a security consideration on the
general points with a specific comment on how it's placement as a filter
may make these choices more critical than in a normal MUA, as they may
limit the user's ability to protect themselves from bad data.

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 May 2005 09:49:57 +0100

>	determine whether an address is the only address in a header.
I like that.

>don't see how sieve can specify those strings to be case-insensitive.
In this case I think it might be better to explicitly say that the 
require parameter is case-sensitive.

>existing text is quite clear and unambiguous.
<chair-hat off>I agree</chair-hat off>

>clarification, but think more people should speak to the point.
<chair-hat off>I agree</chair-hat off>