On Wed, 26 Oct 2011, Stephan Bosch wrote:
I've recently started implementing the editheader extension and based on the
specification (RFC 5293) I have a few questions.
(1)
This is the first extension to introduce an action command with match
arguments (match type and comparator), apart perhaps from the "denotify"
command of the long-deprecated notify extension. Some match types such
as ":matches" introduce the side-effect of setting match variables when
the variables extension is active (RFC 5229; Section 3.2). So, my
question is: can deleteheader action of the editheader extension affect
match variables or is that supposed to be disabled much like the body
test?
...
It should affect match variables. The variables extension, when it
describes the side-effect of the :matches match-type, places no
restriction on it only affecting its use in tests and not in actions.
As co-author of the RFC I can confirm that it was my intent that they do
so and that the original implementation, as written by my co-author Jutta,
certainly does set match variables.
Note that the body test explictly calls out that variables aren't set,
while no such statement appears in this RFC.
(2)
If I understand the specification correctly, users can use the
editheader extension to (accidentally) create invalid IMAIL (now RFC
5322, was RFC 2822) messages. Some header fields defined in the IMAIL
specification have a restricted number of occurrences and some have a
specific well-defined structure. The editheader specification does not
require, recommend, nor mention keeping the message a valid RFC2822
message. The only syntactic restriction I see is the requirement that
the field value complies with the "unstructured" nonterminal syntax from
IMAIL. It is allowed to silently refuse certain modifications (e.g.
deleting Received headers), but I would have expected some
recommendations in this respect. For example, is it wise to allow adding
a second 'Subject:' header, or to allow setting the 'Date:' header to
some syntactically incorrect nonsense? More complex examples would
include the requirement for a 'Sender:' header when more than one
'From:' mailbox is specified.
I think this is completely up to local policy. There are implementations
that operate in contexts where the 'message' that is being operated on is
not required to meet all the requirements of RFC 5322.
For a similar scenario, the IMAP standard's APPEND command merely says
that an appended message "SHOULD be in the format of an [RFC-2822]
message" and even provides an example of why a message might legitimately
fail to be in that form later:
Note: There MAY be exceptions, e.g., draft messages, in
which required [RFC-2822] header lines are omitted in
the message literal argument to APPEND. The full
implications of doing so MUST be understood and
carefully weighed.
(IMO, using the RFC 2119 keywords "MAY" and "MUST" in that note was
pointless. MUST be understood by whom? And how does 'understanding the
implications' affect interoperability?)
Personally, I'm a liberal on this: I think an implementation should let
you do whatever you want in the script and only when the message goes
'out' (via a fileinto, redirect, the implicit keep, etc) should the format
be checked in any way. The message format standard isn't a straight
jacket, but rather a statement about what others are expected to accept
and how they should interpret that. If you send something outside of that
spec, you've gone outside the bounds of the standard and left your message
open to rejection, modification, and misinterpretation...unless you have
an agreement beyond the base standard.
In other words:
Or am I just exaggerating this problem?
In my opinion, yes.
Philip Guenther
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve