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