ietf-mta-filters
[Top] [All Lists]

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

2005-05-10 12:23:38

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 <michael(_dot_)haardt(_at_)freenet-ag(_dot_)de> writes:
...
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.

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.


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.

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.


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.

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
generating an error instead of ignoring the header field in order to
ease script debugging, which fits in the common picture of Sieve.

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

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


<Prev in Thread] Current Thread [Next in Thread>