[Top] [All Lists]

Re: 3028bis, section 4.2, paragraph 2

2007-02-07 21:36:46

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