Tim Showalter wrote:
Hi. This draft has some of the changes folks have asked for. Notably
missing are the things Steve posted that I wasn't sure about, noted in
my previous message, and anything related to multiple fileinto.
A few typos and mostly minor comments.
Tony Hansen
tony(_at_)att(_dot_)com
===
All implementations MUST support the "i;octet" comparator (simply
compares octets) and the "i;ascii-casemap" comparator (which treats
uppercase and lowercase English characters in the same). If left
^^ as
unspecified, the default is "i;ascii-casemap".
===
Actions that do not affect delivery status can be used multiple times
and in any combination with each other. In the base draft, this
^^^^ these
actions are "fileinto" and "redirect".
===
As I was reading section 4, I kept wondering what the "require" string
was supposed to be for each of the optional commands. I suggest adding
that information to each section of an action that is optional.
Because some implementations cannot implement the reject command, it
is optional.
^^ The string to be used for the require command is "reject".
===
The "fileinto" action drops the message into a named folder.
Implementations SHOULD support fileinto, but in some environments
this may be impossible.
^^ The string to be used for the require command
is "fileinto".
===
The require action notes that a script makes use of an certain
extension. Such a declaration is required to use the extension, as
discussed in section 2.10.2. Multiple capabilities can be declared
^^^^^^ 2.10.5
with a single require.
===
Example: require ["fileinto", "envelope"];
^^^^^^^^ "reject".
What is "envelope" supposed to represent? The envelope test is not
optional, or if it is, it's not marked as such.
===
5.4. Test envelope
This section is written strictly in terms of SMTP. Other transfer protocols
do exist and should not be dismissed.
===
The "envelope" test is true if the specified part of the RFC-822
^^^^^^^ SMTP (or
equivalent)
envelope matches the specified key.
If an RFC were to be mentioned, it should be 821, not 822. Besides, the
SMTP protocol RFC821 is being rewritten, so refering to a particular RFC
is not recommended.
===
If one of the envelope-part strings is (case insensitive) "from",
then matching occurs against the FROM address used in the SMTP MAIL
command.
^^, or equivalent
If one of the envelope-part strings is (case insensitive) "to", then
matching occurs against the TO address used in the SMTP RCPT command
^^, or
equivalent,
that resulted in this message getting delivered to this user. Note
that only the most recent TO is avaliable.
===
The Test address and Test envelope sections need examples:
Example: if address :all "from" :is "tim(_at_)example(_dot_)com" {
discard;
}
Example: if envelope :all "from" :is "tim(_at_)example(_dot_)com" {
discard;
}
===
7. Transmission
The MIME type for a Sieve script is "application/sieve".
This needs the complete registration section from the MIME documents (RFC
2048). Suggested text follows:
Subject: Registration of MIME media type applicaton/sieve
MIME media type name: application
MIME subtype name: sieve
Required parameters: none
Optional parameters: none
Encoding considerations: Most sieve scripts will be textual, written in
UTF-8.
When non-7bit characters are used, quoted-printable would be
appropriate for transport
systems that require 7bit encoding.
Security considerations: Discussed in section 10 of RFC XXXX.
Interoperability considerations: Discussed in section 2.10.5 of RFC XXXX.
Published specification: RFC XXXX.
Applications which use this media type: sieve-enabled mail servers
Additional information:
Magic number(s):
File extension(s): .siv
Macintosh File Type Code(s):
Person & email address to contact for further information:
See the discussion list at ietf-mta-filters(_at_)imc(_dot_)org(_dot_)
Intended usage:
COMMON
Author/Change controller:
See Author information in RFC XXXX.