A message modified by addheader or deleteheader MUST NOT
be considered the same as the original message unless it
matches the original message exactly.
For example, the following code fragment
keep;
addheader "X-Flavor: vanilla"
keep;
files two messages, not one.
The above represents a problem for those of us who have read section 2.10.6
of 3028 and decided to do a full execution of the script, then apply all
actions.... if we come across a script like this:
keep;
addheader "X-Flavor: vanilla"
keep;
addheader "X-Flavor: strawberry"
keep;
addheader "X-Flavor: chocolate"
keep;
addheader "X-Flavor: pistachio"
keep;
addheader "X-Flavor: bannana"
keep;
And we are filtering a large message (Say 20MB), then the simple and obvious
implementation is going to have to freeze a copy of the message every time
it sees fileinto/redirect/keep and then if it sees addheader/removeheader it
will need to create a copy of the message. This means that with the above
script we'll end up with 6 different copies of the message = 120MB of
memory/storage. Sounds like a potential security hole.
So it seems that as it is written, editheader is putting strong bias on
"take actions as you go" implementations. Do we want do do this?
I can't see that the above functionality is really all that useful, so at
the moment I'm inclined to say that we move more towards section "2.10.3
Message Uniqueness in a Mailbox" of 3028 which says:
Implementations SHOULD NOT deliver a message to the same folder more
than once, even if a script explicitly asks for a message to be
written to a mailbox twice.
I think it makes it too complicated to consider there to be any more than
one "message" in context when processing the script.
So what should the keep/addheader/keep script do? I recon it files one copy
of the message into the inbox, and the implementation is free to either add
the version with or without the header. If the user really wants to keep a
copy that does NOT have the header, then they do keep/stop. If they want
one with the header they do addheader/keep.
I know some will probably not like the above, but then 3028 already permits
implementations to operate differently WRT to some situations like catching
errors. ie an "action-as-you-go" with a fileinto/reject/reject script may
file the message before producing an error, so I think it would be ok for
this slightly peculiar case to operate in an implementation specific way.
Nigel