ietf-mta-filters
[Top] [All Lists]

Re: I-D ACTION:draft-hansen-sieve-loop-01.txt]

2005-11-03 08:25:59

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
<Prev in Thread] Current Thread [Next in Thread>