A message modified by addheader or deleteheader MUST NOT
be considered the same as the original message unless it
matches the original message exactly.
At this point, I'd like to throw this out as well. Anyone have
a compelling reason not to?
Personally, I'd like it to be replaced by an explicit statement
saying that these added headers do *not* make the message different.
Great! I'd like it thrown too, but it does sounds a little bizzare to do put
in the counter statement, as we all know that it isn't actually the same
message. If we are throwing it out, doesn't it make any of the following 4
options correct?
Should we say that
[ ] the first fileinto wins, say that
[ ] any one fileinto may win (but it has to be one of
the actual fileintos - can't have just half the
headers or additional headers),
[ ] the last fileinto wins,
[ ] or leave it completely open?
I'd like one of the first three -- I think if it is one of the
fourth, it starts weakening the connection between message modification
and message use, and I'd like that connection to be a strong one.
Well action-as-you-go implementations are going to vote for 1,
actions-all-at-the-end impelmentations are going to vote for 3, and I think we
need to make it equally feasable to implement either way which means I think we
have to have either option 2 or 4. So that makes me vote for option 2?
Nigel