Below is a strawman Internet draft that describes the easiest,
most general form of "body" I could imagine -- a simple match
against the text of an e-mail message that is not the header,
without content-decoding of any sort. I plan to submit this
in earnest about a week from now, in time for Yokohama, and am
looking for initial comments.
My goal is not to create the catch-all of message body operations,
but just to arrive at a draft that has the simplest and/or most
common features of the "body" as actually implemented and used
so far.
There are multiple "body" implementations (I'm counting "x_body"
as one) out there; I don't know enough about their details, and
am interested in responses from people who have implemented
or used some form of "body" -- does this match the implementations
you know about, and if not, how do the implementations you know
differ from it?
Thanks!,
Jutta <jutta(_at_)sendmail(_dot_)com>
--
INTERNET DRAFT: Sieve -- "body" extension Jutta Degener
Document: draft-degener-sieve-body-00.txt Sendmail, Inc.
Expires: December 2002 June 2002
Sieve -- "body" extension
Status of this memo
This document is an Internet-Draft and is subject to all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document defines a new test for the Sieve language that
tests the occurrence of a string in the uninterpreted body
of an e-mail message.
1. Introduction
The "body" test, initially proposed for the [SIEVE] base document,
has later been removed from it because it was held to be too costly
to implement. Nevertheless, several server vendors have implemented
some form of the "body" command. This document describes a simple
version of such a command in the hopes of providing a common ground
for users and implementors of the existing practice.
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.
The capability string associated with extension defined in this
document is "body".
3. Test body
Syntax: "body" [COMPARATOR] [MATCH-TYPE] <key-list: string-list>
The body test matches text in the body of an e-mail message,
that is, anything following the first empty line after the header.
(The empty line itself, if present, is not considered to be part
of the body.)
For the purposes of this test, the actual MIME structure of the
body is irrelevant. The server MUST NOT remove transfer encoding
from the message.
(This is done in part to save work for the executing server,
in part to allow matches against syntactically incorrect
messages.)
If a message consists of a header only, not followed by an
empty line, all "body" tests fail, including that for an
empty string.
If a message consists of a header followed only by an empty
line with no body lines following it, the message is considered
to have an empty string as a body.
Example: require "body";
# ...
# filter out some "Sircam" virus messages
if body :contains "Hi! How are you?\nI send you this file" {
discard;
}
4. Interaction with Other Sieve Extensions
Any extension that extends the grammar for the COMPARATOR or
MATCH-TYPE nonterminals will also affect the implementation of
"body".
Especially when used in conjunction with a naive implementation of
[REGEX], the body extension can place a considerable load on a
system that may affect all users of the system.
5. Security Considerations
The system must be sized and restricted in such a manner that even
malicious use of body matching does not deny service to other users.
Matching strings in the body of an e-mail message may be more general
than the author of the sieve script intended. The strings may be
matched in headers of included messages; strings that are dangerous
only when used in enclosed MIME headers may be matched in text that
is in itself not dangerous, or discusses the very problem that the
script is attempting to defend against.
6. Acknowledgments
This document will be revised in part based on comments and
discussions which will take place on and off the SIEVE mailing list.
Thanks in advance for the help of those who will take the time to review
this draft and make suggestions.
7. Author's Address
Jutta Degener
Sendmail, Inc.
6425 Christie Ave, 4th Floor
Emeryville, CA 94608
Email: jutta(_at_)sendmail(_dot_)com
Appendices
Appendix A. References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[REGEX] Murchison, K., "Sieve -- Regular Expression Extension",
draft-murchison-sieve-regex-04.txt, August 2001.
[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
January 2001.
Appendix B. Full Copyright Statement
Copyright (C) The Internet Society 2002. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.