I would like to ask all people who commented on the document earlier to
review if their comments were addressed. If there are no comments on
the
document before March 21st, I would recommend its publication.
4.1. Test "header"
- The "header" test is extended with the addition of a new ":mime"
- tagged argument and its associated options.
+ The "header" test is extended with the addition of new ":mime"
+ and ":anychild" tagged arguments and their associated options.
I guess this doesn't have to be the case, but I think it would make sense to
use header :anychild without a :mime argument in order to test header of
attached rfc2822 messages, or indeed to test the Content-Type headers of
child body parts as unparsed strings. It seems clear if you use :anychild,
then you are asking for the mime structure to be evaluated. I think this is
actually implied anyway when it goes on to say:
When used inside the context of a "for_every_part" iterator, and with
an ":anychild" tagged argument, the "header" test will examine the
current MIME part context and all it's nested MIME body parts,
returning true if any of them satisfies the test.
:param parses the header looking for MIME parameters in the header.
The supplied string-list lists the names of any parameters to be
- tested. If any one named parameter value matches the test string
- value, the test will return true.
+ tested. If any one named parameter value matches any of the test
+ string values, the test will return true.
4.2. Test "address"
- The "address" test is extended with the addition of a new ":mime"
- tagged argument, which takes a number of other arguments.
+ The "address" test is extended with the addition of new ":mime"
+ and ":anychild" tagged arguments and their associated options.
4.3. Test "exists"
- The "exists" test is extended with the addition of a new ":mime"
- tagged argument, which takes one other argument.
+ The "exists" test is extended with the addition of new ":mime"
+ and ":anychild" tagged arguments.
5. Action Replace
Should we also preserve some trace fields? I'd have thought typically
replace would be used to remove malicious content, in which case would it
not be helpful to at least have some way of knowing where the message came
from that produced the butchered message? I'd suggest:
- If the entire message is being replaced, a ":subject" parameter
+ If the entire message is being replaced, the optional ":subject"
parameter
specifies a subject line to attach to the message that is generated.
UTF-8 characters can be used in the string argument; implementations
MUST convert the string to [RFC2047] encoded words if and only if
non-ASCII characters are present. Implementations MUST preserve the
previous Subject header as an Original-Subject header.
If the entire message is being replaced, a ":from" parameter may be
used to specify an alternate address to use in the From field of the
message that is generated. The string must specify a valid [RFC2822]
mailbox-list. Implementations SHOULD check the syntax and generate
an error when a syntactically invalid ":from" parameter is specified.
Implementations MAY also impose restrictions on what addresses can be
specified in a ":from" parameter; it is suggested that values that
fail such a validity check simply be ignored rather than causing the
replace action to fail. Implementations MUST preserve the previous
From header as an Original-From header.
+ Implementations MUST preserve all other header fields from the original
+ message with the exception of those relating to the MIME structure which
+ will need to be replaced.
Although I do note that the security section does at least indicate that
replace creates an entirely new message, so I'm sorry if we covered this
before and I just forgot.
6. Action Enclose
If multiple "enclose" actions are executed by a script, only the text
- specified on the last one is used when creating the enclosed message.
+ specified on the last one is used when creating the enclosed message,
+ the message in this case would not be enclosed multiple times.
This action does not affect messages that are forwarded via a
- "redirect" action.
+ "redirect" action, rather the unenclosed message would be what was
+ redirected.
Specifically, the original message becomes a multipart/mixed message
with two parts: a text/plain portion with the string argument as its
body, and a message/rfc822 portion with the original message
enclosed. The Content-Type: header field becomes multipart/mixed.
- The Subject: header is specified by the :subject argument. Any
+ The optional Subject: header is specified by the :subject argument,
+ if not present the subject will be taken from the enclosed message. Any
headers specified by :headers are copied from the old message into
the new message. If not specified by :headers, Date: and From:
headers should be synthesized to reflect the current date and the
user running the Sieve action.
7. Action extract_text
If extract_text is used outside the context of a "for_every_part"
loop, the action will set the variable identified by varname to the
empty string.
I suggest the above SHOULD be a compilation error, otherwise it should
return the empty string.
Cheers
Nigel