Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Apr 2005 18:08:15 +0100

Mark E. Mallett wrote:

>4.1 Body Transform ":raw"
>
>In the example:
>
>	> # This will match a message containing the words "MAKE MONEY FAST"
>	> # in body or MIME headers other than the outermost RFC 822 header,
>	> # but will not match a message containing the words in a
>	> # content-transfer-encoded body.
>
>the description is inexact.  Where it talks about "containing the words" I
>for one would get the idea that, well, the test is whether the body
>contains those words, rather than that string.  I realize that one should
>be reading this in the context of the document, but every little bit of
>precision helps.  Also, where it says it will not match in a
>content-transfer-encoded body, I beg to differ.  If the body is encoded
>quoted-printable, the string "MAKE MONEY FAST" will appear plain as day and
>should be matched in raw mode.
>
>[I see that Bob Johannessen also made the above comments, but this is
>already in my notes, so read this as "me too"]
>  
>
+1.

>4.2 Body Transform ":content"
>
>   > The search for MIME parts matching the :content specification is
>   > recursive and automatically descends into multipart and
>   > message/rfc822 MIME parts.  Once a MIME part has been identified
>   > as suitable for searching, only its direct contents are searched
>   > for the key strings.
>
>If a message contains more than one testable part, I assume that the
>"body" result is the OR of the tests of all of them, with a
>short-circuit exit.  i.e., first match causes the body test to end and
>return a true result, whereas a non-match causes the body test to
>contine on to the next candidate mime part.  This may seem obvious but
>it probably needs to be made explicit, no?
>
I tend to agree.

>Also, is it worth specifying the recursion order?
>  
>
I don't think so, as the result would be the same.

>   > For example, a document with "multipart" major content type only
>   > directly contains the text in its epilogue and prologue section;
>   > all the user-visible data inside it is directly contained in
>   > documents with MIME types other than multipart.
>
>I question the term "user-visible."  I'm a user, and the prolog and
>epilog stuff is always visible to me in my mail reader.  Maybe just
>say "other" ?
>  
>
I agree.

>   > MIME headers of the containing text MUST NOT be included in the
>   > data.
>
>Explicitly provides no way to test the header part of a mime part which,
>it seems to me, would be useful.
>  
>
My understanding is there would be a separate extension to deal with this.

>	> # Save any message with any text MIME part that contains the
>	> # worlds "missile" or "coordinates" in the "secrets" folder. 
>
>"words" not "worlds"
>
Alexey