I'm glad to see you've merged the loop/mime I-drafts (as I'd recommended)
:o) A little surprised that you've stuck with the "sieve-loop" rather than
the "sieve-mime" as it seems like it's extensions targetted at mime more
than it is to looping. Along these lines I'd suggest:
- Sieve Extensions: MIME Bodypart Iteration, MIME Tests, Replacement and
- Enclosure
+ Sieve Extensions: MIME Tests, MIME Bodypart Iteration, Replacement and
+ Enclosure
2 Sieve Loops
I can see that this makes perfect sense when used with replace and am glad
to see you've included "break" which I completely missed on my first scan.
Is it worth being a little more explicit when describing the behaviour of
other tests like header/address/size within a for.every.part test? This
could probably done purely by extended example.
3 Test "mime"
I like this test, but my earlier comments from 2004 still stand
(http://www.imc.org/ietf-mta-filters/mail-archive/msg01723.html). I think a
header part sepecifier like this would still be of value:
Syntax: header [HEADER-PART] [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
HEADER-PART: ":value" / ":parameter" <param-names: string-list>
However having a mime test specifically targetted at looking at mime headers
won't prevent a HEADER-PART, so I guess I can't have a strong objection.
You say:
If used within the context of a "for.every.part" iterator, the "mime"
test will examine the headers associated with the current MIME part
context.
If used outside the context of a "for.every.part" iterator, the
"mime" test will examine all MIME body parts and return true if any
of them satisfies the test.
While I'm glad you've provided the facility to easily look for attachments
of the given type without using for.every.part, this wasn't the behaviour I
was expecting and I think it's too quirky. What if i find an attachment of
type rfc822 (think of multipart/digest), and then I'd want to recursively
look through all the attachments of just that attached message? I would
much rather the mime test just look at the current body part context, and we
provide a switch which asks for the test to apply to all the child body
parts too where relevant. This switch then also makes sense when used with
other tests like header, exists, size, address. Something like:
mime :recursive :type :is "image"
Or:
mime :anybodypart :type :is "image"
header :anybodypart :contains "Subject" "important"
4 Action Replace
When used in the context of a "for.every.part" loop, the MIME part to
be replaced is the "current" MIME part. If the current MIME context
is a multipart MIME part, the entire multipart MIME part is replaced.
(Replacing a non-multipart MIME part within a "for.every.part" loop
context does not alter the overall message structure.)
I think I know what you are trying to get at with the bit in (), but I don't
actually understand what you have said. I suggest just dropping the () bit,
as I don't think it's necessary.
I think we should say "The replace action happens immediately, and therefore
when used inside a for.every.part loop will affect the iteration of that
loop and all subsequent tests in this script". Much in the same way as is
done in the edit header extension.
5 Action Enclose
Need an example of the :headers argument in use.
This enclose action
takes precedance over all other message modifications, such as
"replace". If multiple "enclose" actions are executed by a script,
only the text specified on the last one is used when creating the
enclosed message.
I find the above quite confusing. Perhaps you could say something like "The
enclose action MUST NOT happen immediately, but rather be delayed until we
have finished processing the script". If we then have replace happen
immediately, there's no clash between enclose/replace as one happens
immediately, and the other at the end of the script.
However enclose currently doesn't seem to allow us to enclose attached
messages, it just wraps the entire message. Do we want it to support
enclosing attached rfc822 content? Again I'm thinking of multipart/digest
or just forwarded rfc822 content.
This action does not affect messages that are
forwarded via a "redirect" action.
I don't like the last sentence very much at all. It implies I need to
forward before I modify, which means I'll likely end up with two copies of
the message which sounds like an awkward issue to deal with and I'm not sure
it's the right behaviour anyway. If I read a script that had a
replace/enclose as well as a redirect, then I'd expect that the redirected
message to have the replace/enclose action included. Is it not most likely
we'd be using enclose/replace for security/moderation reasons, so why
wouldn't we want this to apply for redirected mail?
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
headers specified by :headers are copied from the old message into
the new message.
Might I suggest that we copy all the headers by default, including the
subject? If we don't are we not then at risk of creating mail loops etc and
also breaking the threading of messages due to the altered subject
line/references/message-id? That means we don't need the :headers/:subject
arguments at all :o)
Nigel