| > There is another twist on this. I venture to say that a Sieve
| implementation
| > MAY choose to forward a message using MIME encapsulation. In such a case
| > resent headers MUST NOT be inserted. This should be enough for seriously
| > considering Alan's suggestion.
|
| I venture to say that it must not. Have you missed the following
| paragraph from the -04 Sieve spec?:
|
| The forward 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 forward 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've lost some antecedents in this discussion. What part of "Alan's
suggestion" are you disagreeing with, Barry? That there is a need for
"resend" itself, or with Tomas' suggestion that "forward" possibly do a
MIME-wrapped resend?
If you are satisfied with the current function of "forward" (ie: simple
resubmission of the message, without modification, to a different address
list), then I'm inclined to agree.
I would propose not to modify the current behavior of "forward", and,
instead, add new functionality to a new action, called "resend". This will
preserve existing Sieve rulesets while still providing new function.
About the MIME wrapping, I think it makes sense. Some end-users will want
simple forwarding, which they can already do, while some end-users will
prefer to MIME-wrap and send a new message. Perhaps, the suggested "resend"
command can be modified with an argument:
resend :mime <address>
Without the :mime argument, "resend" does a "forward", with the addition of
"Resent-" header insertion. With the ":mime" argument, a new message is
created, containing the original within a MIME encapsulation.
While we're quoting the -04 spec, let's also look at the abstract:
This document describes a mail filtering language for filtering
messages at time of final delivery. It is designed to be independent
of protocol, and implementable on either a mail client or mail
server. It is meant to be extensible, simple, and independent of
access protocol, mail architecture, and operating system. It is
suitable for running on a mail server where users may not be allowed
to execute arbitrary programs, such as on black box IMAP servers, as
it has no variables, loops, or ability to shell out to external
programs.
Given this, I would suggest that if the Sieve engine is to be useful for
both "client" and "server" usages, then it should perform functions that are
needed in both contexts. MIME encapsulation has become an important feature
for both servers and clients.
Also, I would suggest that the text "no variables" be changed to read "no
external variables". Clearly, `headers["To"]' is a kind of variable.
--
Alan K. Stebbens <alan(_dot_)stebbens(_at_)software(_dot_)com>