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

From: Cyrus Daboo <[email-masked]>
Date: Mon, 14 Mar 2005 15:04:09 -0500

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-00.txt>

A two week working group last call of this document starts today and ends 
on 28th March 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, please 
send both co-chairs (or the list) an email to indicate you have looked at 
it. This will allow the chairs to gauge the scope of reviews of this 
document to aid in our determination on whether to send it to the IESG. 
Thanks.

-- 
Cyrus Daboo
SIEVE WG Co-chair

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Mar 2005 17:08:35 -0500

Cyrus Daboo wrote:
> A two week working group last call of this document starts today and 
> ends on 28th March 2005 at 6 pm EST.
> 

Section 4.1, paragraph 2, last phrase says "... and MUST NOT interpret 
or skip MIME headers of enclosed body parts."

I don't think that the intent was to have "MUST NOT" refer to "skip", 
but it reads that way.  I'd recommend that either "or skip" be removed 
(since not interpreting them seems to encompass ignoring them), or 
reword the entire phrase to something like:  "... and either MUST NOT 
interpret MIME headers of enclosed body parts or MUST ignore them entirely."

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Bob Johannessen <[email-masked]>
Date: Tue, 15 Mar 2005 03:55:45 +0100

> Please review this document and send issues to the list or direct to the

4.1 Body Transform ":raw"

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

Wouldn't it be more correct to say that it matches the string, or
even the character sequence "MAKE MONEY FAST"? Also I'm not sure I
understand what is meant by "a content-transfer-encoded body". It
*could* still match the character sequence in a quoted-printable
encoded body, couldn't it?

4.2 Body Transform ":content"

   MIME parts encoded in "quoted-printable" or "base64" content
   transfer encodings MUST be decoded to prior to the match.

I'm not a native English speaker, but the above sentence doesn't
make sense to me. Probably should say "..MUST be decoded prior to.."

   If an implementation does not support conversion of a given
   charset to  UTF-8, it MAY compare against the US-ASCII subset
   of the transfer-decoded character data instead.

Does the above rely on all current and future charsets having
a one-to-one mapping to US-ASCII for all characters with code
points 0-127? Is this a safe assumption? Is it even true of all
existing charsets? Maybe it would be better to explicitly
exclude all parts who can't be converted to UTF-8?

	Bob

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 17 Mar 2005 14:30:37 -0500

> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-00.txt>

Nitpick warning as always.

1. Introduction

   > This document reintroduces the "body" test as an extension,
   > and specifies it syntax and semantics.

"its",  not "it"

2. Conventions used.

   > Conventions for notations are as in [SIEVE] section 1.1, including
   > use of [KEYWORDS] and "Syntax:" label for the definition of action
   > and tagged arguments syntax.

I think labels are plural, so it ought to read "... labels for
definitions of ..."

   > The capability string associated with extension defined in this
   > document is "body".

"the extension"

	> # 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"]

   > 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?  Also, is it worth specifying
the recursion order?

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

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

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

"words" not "worlds"

5. Interaction with Other Sieve Extensions

   > Regular and wildcard expressions used with "body" are exempt
   > from the side effects described in [VARIABLES].  That is, they
   > do not set numbered variables ${1}, ${2}... to the input
   > values corresponding to wild card sequences in the matched
   > pattern.

I remember that this came up last fall, expressed this way:

  >  QUESTION: Is it okay to have body :matches and
  >  :regex scans not set variables?

and the (small) concensus was a "yes" answer to that question.  I took
that to mean that people thought it was OK for an implementation not to
set the numbered variables-- not that an implementation would be
prohibited from doing so.  This prohibition is unfriendly to
general-purpose match logic.  Also, if it is a prohibition, shouldn't
"MUST NOT" appear there?

Personally I think these match results could be very useful, but
understand if an implementation doesn't want to provide them.
However I'd want to allow an implementation to choose to do so.
(But see the comments on pragmatism below)

8. Acknowledgments

My name jumped out at me- if it's in there, it should be
spelled "Mallett"  :-)

General

Pragmatic/implementation limits?  The body test is easiest to implement
when the entire message, or at least the particular MIME part being
looked at (or its transform result) can be held in memory, but that
can't be guaranteed.  I would favor saying that an implementation may
limit the body test so that it operates against a practical initial
subpart of each mime part's data, as long as that is no less than some
number of bytes.  This may be controversial: does everyone plan on
implementing searches against non-memory-resident data, e.g. that 
must be buffered to disk?

Similarly, a script writer often just wants to see if there's something in
the first few lines of a message, and not needlessly test beyond that --
which, in fact, could yield a false positive.  I would like to see
option(s) that allow one to specify testing some initial subpart.  I
realize it's a bit late to bring that up, though.

If match results are not prohibited, another pragmatic limit would be
the size of such a result.  I would favor something that said this
rather than prohibited the match results from being saved.

Yours,
mm

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 28 Mar 2005 15:36:30 +0100

4.2 Body Transform ":content"
MIME parts encoded in "quoted-printable" or "base64" content
-   transfer encodings MUST be decoded to prior to the match.
+   transfer encodings MUST be decoded prior to the match.

I don't think this is terribly clear.  For one thing I think it implies you can't have nested multipart messages, which you can (send an attachment with alternative content type).  I think it may be best illustrated using an example.  I suggest:

   For example, suppose we have the following message:

     From: Whomever
     To: Someone
     Date: Whenever
     Subject: whatever
     Content-Type: multipart/alternative; boundary=1234

     This is a multi-part message in MIME format.

     --1234
     Content-Type: text/plain; charset="us-ascii"

     Hello

     --1234
     Content-Type: text/html; charset="us-ascii"

     <html><body>Hello</body></html>

     --1234--

   If the body test was used with :content specification "multipart", then we would 
   find the string "This is a multi-part message", but we would not find "Hello", as 
   Hello is in the direct contents of the text/plain and text/html body parts, but only 
   indirectly in the content of the multipart/alternative body part.

4.2 Body Transform ":content"
-   charset to  UTF-8, it MAY compare against the US-ASCII subset
+  charset to UTF-8, it MAY compare against the US-ASCII subset

7. Security Considerations
I suggest:
-   replacement for a virus or spam filtering system.
+  replacement for a spam, virus or other security related filtering system.

I'd also suggest:
-   pattern.  However, variable references in the pattern string
-   are evaluated as described in the draft, if the extension
-   is present.
+   pattern.  However, if the extension is present, variable 
+   references in the pattern string are evaluated as described 
+   in the draft.

Nigel

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 28 Mar 2005 14:29:50 -0500

Hi Nigel,

--On March 28, 2005 15:36:30 +0100 Nigel Swinson 
<[email-masked]> wrote:

> I don't think this is terribly clear.  For one thing I think it implies
> you can't have nested multipart messages, which you can (send an
> attachment with alternative content type).  I think it may be best
> illustrated using an example.  I suggest:
>
>    If the body test was used with :content specification "multipart",
> then we would     find the string "This is a multi-part message", but we
> would not find "Hello", as     Hello is in the direct contents of the
> text/plain and text/html body parts, but only     indirectly in the
> content of the multipart/alternative body part.

How about using an example like the following for extra clarification 
(copying the approach from rfc2015 PGP/MIME):

----

Example:

       From: Whomever
       To: Someone
       Date: Whenever
       Subject: whatever

&      This is a multi-part message in MIME format.
&
       --1234
       Content-Type: text/plain; charset="us-ascii"

$      Hello
$
       --1234

%      <html><body>Hello</body></html>
%
       --1234--
&
&      This is the end of the MIME multipart.

In the above example, the '&', '$' and '%' characters at the start of a 
line are used to illustrate what portions of the example message are used 
in tests:

- the lines starting with '&' are the ones that are tested when a 'body 
:content "multipart/alternative" :contains "MIME"' test is executed.

- the lines starting with '$' are the ones that are tested when a 'body 
:content "text/plain" :contains "Hello"' test is executed.

- the lines starting with '%' are the ones that are tested when a 'body 
:content "text/html" :contains "Hello"' test is executed.

- the lines starting with '$' or '%' are the ones that are tested when a 
'body :content "text" :contains "Hello"' test is executed.

----

-- 
Cyrus Daboo

---

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 29 Mar 2005 12:00:40 +0100

> (copying the approach from rfc2015 PGP/MIME):

Yeah sounds fine to me :o)