Subject: draft-ietf-sieve-3028bis-09

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 6 Dec 2006 14:45:51 -0500

Hi,

I was going over 3028bis-09 last night for a reread, and had a few
observations.  I realize that it's way past last call on this, and also
that one can never completely win (since things can be found on any new
reading.)  Then again, there have been comments since the drop-dead date
(like the non-negative vs positive numbers thing), and then again again,
I have these notes and nowhere to put them (that's not a setup line).

Ignore at will..

> 2.4.2.2. Headers
 ...
>    Similarly, synactically invalid header names cause the same result as

"synactically" should be "syntactically"

> 2.8.     Blocks
> 
>    Blocks are sets of commands enclosed within curly braces and supplied
>    as the final argument to a command.  Such a command is a control
>    structure: when executed it has control over the number of times the
>    commands in the block are executed.  and how

".  and how" ?  (dangling words)

> 3.3.     Control Stop
> 
>    Usage:   stop
> 
>    The "stop" action ends all processing.  If no actions have been
>    executed, then the keep action is taken.

While that's correct, it's not really inclusive enough.  I think the
point is that the implicit keep should still be taken if it is
outstanding-- NOT just subject to whether or not any actions have been
taken.   i.e., "If the implicit keep has not been cancelled, it is
taken."

> 4.2.     Action redirect
> 
>    Usage:   redirect <address: string>
> 
>    The "redirect" action is used to send the message to another user at
>    a supplied address, as a mail forwarding feature does.  The
>    "redirect" action makes no changes to the message body or existing
>    headers, but it may add new headers.  The "redirect" modifies the
>    envelope recipient.

a) 'The "redirect" action modifies' rather than 'The "redirect" modifies'.
(or remove the quotes, i.e. 'The redirect modifies'.)

b) I know what the writer meant, but I don't think it's clear.  The
action doesn't really modify the envelope recipient.  i.e., a subsequent
test of 'envelope "to"' should still show the original envelope
recipient.  The text says to me that it won't.  I think what's meant is
that a new message is created which has a new envelope recipient.

> 4.3.     Action keep

I wonder if this oughtn't say that it cancels the implicit keep.

> 5.1.     Test address
 ...
>    Internet email addresses [IMAIL] have the somewhat awkward
>    characteristic that the local-part to the left of the at-sign is
>    considered case sensitive, and the domain-part to the right of the
>    at-sign is case insensitive.  The "address" command does not deal
>    with this itself, but provides the ADDRESS-PART argument for allowing
>    users to deal with it.

I note that this has the same issue as with the mime type test: one
can't do a test of both parts of an address separately since one can't
guarantee that the parts came from the same address.  That is, there
really isn't anything here (without, say, variables) that allows users
to deal with it, except for the case where there is only one address.
I guess I would just put a period after "itself" and remove the rest of
the sentence.

> 5.4.     Test envelope

This section does not say that it requires "envelope" capability.  It is
implied in the example, but not stated.

> 9.      Extended Example

>             # If message header does not contain my address,
>             # it's from a list.

Comment doesn't match code.  Leftover from previous edit?
(has been mentioned before)

>             # Move all other (non-company) mail to "personal"
>             # mailbox.

ditto... 

> 10.     Security Considerations

>    Implementations SHOULD take measures to prevent languages from
>    looping.

I think it means "messages" not "languages"

Yours with apologies,
-mm-

---

From: "Aaron Stone" <[email-masked]>
Date: Wed, 6 Dec 2006 21:16:00 -0000

> that a new message is created which has a new envelope recipient.

I thought a couple of clarifying sentences were added. I've copied the
fully section from 3028bis-09 here:

4.2.     Action redirect

   The redirect command performs an MTA-style "forward"--that is, what
   you get from a .forward file using sendmail under UNIX.  The address
   on the [SMTP] envelope is replaced with the one on the redirect
   command and the message is sent back out.  (This is not an MUA-style
   forward, which creates a new message with a different sender and
   message ID, wrapping the old message in a new one.)

>>> I still think the casual reference to sendmail should be removed, and a more explicit explanation of what it means to forward mail should be given. I believe it was Ned who replied to me a while ago that there isn't really a "Best Practices of MTA Forwarding" document in existence. Casually referencing what is becoming increasingly archaic unix software behavior isn't exactly referencing best practices IMHO.

   The envelope sender address on the outgoing message is chosen by the
   sieve implementation.  It MAY be copied from the original message.

>>> Didn't we add a few sentences here, per comment above?

   A simple script can be used for redirecting all mail:

   Example:  redirect "[email-masked]";

   Implementations SHOULD take measures to implement loop control,
   possibly including adding headers to the message or counting received
   headers.  If an implementation detects a loop, it causes an error.

Aaron