Re: 3028bis, section 4.2, paragraph 2

Mark Mallett wrote, in regards to this text in 3028bis-10, section 4.2:
   <...>  In particular, existing
   Received headers MUST be preserved and the count of Received headers
   in the outgoing message MUST be larger than the same count on the
   message as received by the implementation.  (An implementation that
   adds a Received header before processing the message does not need to
   add another when redirecting.)

...
> That's interesting, I didn't notice that change.  That does mandate the
> addition of a Received by (or as of) the time a redirect is done.  It
> also implies that adding a Received line is at least discussed elsewhere
> in the document, which it isn't (other than a casual mention in loop
> control).  Maybe that's picky, but if the addition of a Received line is
> alluded to, perhaps it should be discussed.  For example, there could
> be a recommendation that an implementation "adds a Received header before
> processing the message" -- but then is this considered part of the
> original message?
I don't get what's unclear about this.  If the addition was made "before 
processing the message", then by definition the message being processed 
has the added header field.
Oh, and the phrase "original message" is used exactly once in 3028bis-10, 
where it says that the envelope sender of a redirected messaage "MAY be 
copied from the original message".  I'll change that to say "MAY be copied 
from the message being processed" to kill that phrase completely from 
3028bis.
I'd like to stress that the *critical* thing in that paragraph is the bit 
about "count of 'received's MUST be higher", as that's what provides a way 
to break loops.  If the parenthetical comment about implementations that 
do things a particular way raises more issues than it clarifies, then the 
correct action at this point is to *remove* the comment.

> e.g. as applied to the 'editheader' mandate that
>    if an error terminates processing of the script, the original
>    message header MUST be used when doing the implicit keep required by
>    [SIEVE] section 2.10.6.
> where I think it could be argued that such an added "Received" line
> would be valuable to preserve.
In the context of 'editheader', I think it's clear that "the original 
message" just means "the message as it was before any addheader or 
deleteheader actions were processed".  If you disagree about that being 
clear, well, suggest text for editheader...but that doesn't affect this 
discussion of 3028bis.

> The new language that "Received headers MUST be preserved" also implies
> that the removal of any Received headers via an extension (e.g.
> 'editheader') must be ignored for the redirect.  Is that the intent?  I
> dunno whether I think that's good -- I probably do, but it certainly
> means more special-case work for me :)
An excellent question, but again, one that should be raised against 
editheader and not 3028bis.
(I'm not sure either what the Right Thing is.  I'll note that editheader 
could override 3028bis, just as body overrides variables.  The key 
procedural requirement, I think, would be the inclusion of "Updates: 
3028bis" on the title page of editheader.)

I hope I'm not coming across as trying to dodge the issues here.  I just 
feel we need to "keep our eyes on the prize": getting 3028bis published. 
It's what, 2 years late, by the original schedule?  Issues that 3028bis 
raises in other documents should be left to those other documents, even if 
they've been last called.  If it's a general mail agent issue and not 
specific to sieve, then perhaps it belongs in 2821bis or 2822bis ...or in 
a completely new I-D.

Philip Guenther