Subject: 3028bis, section 4.2, paragraph 2

From: Philip Guenther <[email-masked]>
Date: Tue, 6 Feb 2007 17:26:16 -0700

There's been some lingering dislike of the description of the redirect 
action, particularly how it describes the change of envelope recipient. 
3028bis-10 removed this sentence
 	The "redirect" modifies the envelope recipient.

as it was observed that it implied that the result of the 'envelope' test 
would be affected.  With that gone, only the second paragraph actually 
described how the address in the action was to become an envelope 
recipient, but it's description is fairly indirect.  So, I propose 
replacing most of that paragraph, so that instead of reading thusly:

    The redirect command performs an MTA-style "forward"--that is, what
    you get from a .forward file using sendmail under UNIX.  The address
    on the [SMTP] envelope is replaced with the one on the redirect
    command and the message is sent back out.  (This is not an MUA-style
    forward, which creates a new message with a different sender and
    message ID, wrapping the old message in a new one.)

it would instead say:

    The message is send back out with the address from the redirect
    command as an envelope recipient.  Implementations MAY combine
    separate redirects for a given message into a single submission with
    multiple envelope recipients.  (This is not an MUA-style forward,
    which creates a new message with a different sender and message ID,
    wrapping the old message in a new one.)

And yes, the elimination of the mention of .forward files in intentional, 
as that irked some.

Are there any objections to the above change?

Philip Guenther

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 7 Feb 2007 09:43:27 +0100

Philip Guenther writes:
> And yes, the elimination of the mention of .forward files in 
> intentional, as that irked some.
>

No, but maybe I want to add a requirement to prepend a new 'Received' 
field so that a human tracing problems can tell what happened to the 
message. Not 100% sure. In some (many?) cases there are enough Received 
fields anyway.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 7 Feb 2007 11:11:05 +0100

Arnt Gulbrandsen writes:
> message. Not 100% sure. In some (many?) cases there are enough 
> Received fields anyway.

Perhaps: SHOULD ensure that there is sufficient information in the chain 
of 'Received' fields that a human observer can see what happened?

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 07 Feb 2007 11:52:12 +0000

Arnt Gulbrandsen wrote:

> Perhaps: SHOULD ensure that there is sufficient information in the 
> chain of 'Received' fields that a human observer can see what happened?

Arnt,
I think this is already covered by existing paragraph in -10 (which 
Philip didn't plan to change):

   The "redirect" action is used to send the message to another user at
   a supplied address, as a mail forwarding feature does.  The
   "redirect" action makes no changes to the message body or existing
   headers, but it may add new headers.  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.)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 7 Feb 2007 13:07:39 +0100

>   add another when redirecting.)

Fine. A 'for' clause is desirable, but I suppose it always is.

Arnt

---

From: Philip Guenther <[email-masked]>
Date: Wed, 7 Feb 2007 06:38:33 -0700

On Wed, 7 Feb 2007, Arnt Gulbrandsen wrote:
...
> Fine. A 'for' clause is desirable, but I suppose it always is.

IMHO, if the discussion in RFC 2821 of 'for' clauses and when they should 
or should not be included (c.f. sections 4.4, 7.2, and 7.5) is 
insufficient, then it should be fixed there and not in 3028bis.

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 07 Feb 2007 13:50:34 +0000

Philip Guenther wrote:

> IMHO, if the discussion in RFC 2821 of 'for' clauses and when they 
> should or should not be included (c.f. sections 4.4, 7.2, and 7.5) is 

Agreed. IMHO, this is not 3028bis business.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 07 Feb 2007 13:54:13 +0000

Philip Guenther wrote:

> action, particularly how it describes the change of envelope 
> recipient. 3028bis-10 removed this sentence
> as it was observed that it implied that the result of the 'envelope' 
> test would be affected.  With that gone, only the second paragraph 
> actually described how the address in the action was to become an 
> envelope recipient, but it's description is fairly indirect.  So, I 
> propose replacing most of that paragraph, so that instead of reading 
> thusly:
>

Speaking as an individual: No objections from me.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 7 Feb 2007 17:14:26 +0100

> insufficient, then it should be fixed there and not in 3028bis.

I could argue that one either way... so let's just use the text you 
proposed earlier today.

Arnt

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 7 Feb 2007 15:43:08 -0500

> And yes, the elimination of the mention of .forward files in intentional, 

(yay!)

> Are there any objections to the above change?

Only that you should replace "send" with "sent" ("The message is sent...").
Otherwise fine.

mm

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 7 Feb 2007 16:48:40 -0500

>   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?  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.  (as would, I think, other annotating
information, but I've said that before: I think that that editheader
prohibition is too broad since it reaches beyond changes made by
editheader, but I seem to be the only one who thinks that.)

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 :)

mm  (yes, I kind of got off on a tangent)

---

From: Philip Guenther <[email-masked]>
Date: Wed, 7 Feb 2007 21:21:49 -0700

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.)

...
> 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
> 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.

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Feb 2007 11:17:59 +0000

Philip Guenther wrote:

> deleteheader actions were processed".  If you disagree about that 
> being clear, well, suggest text for editheader...

I would just remind people that WGLC for editheader has ended as well. 
Cyrus and I are planning to request its publication next week.

So at this point we need specific text.

> but that doesn't affect this discussion of 3028bis.
>
>> 'editheader') must be ignored for the redirect.  Is that the intent?
>
I don't think this was the intent.

>>  I dunno whether I think that's good -- I probably do, but it certainly
> (I'm not sure either what the Right Thing is.  I'll note that 
> editheader could override 3028bis, just as body overrides variables.

Indeed. It is somewhat difficult to put normative requirements on future 
document (or in this case on a document that gets published later).

> The key procedural requirement, I think, would be the inclusion of 
> "Updates: 3028bis" on the title page of editheader.

Yes, go for it! :-)

> )

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Feb 2007 11:21:06 +0000

Philip Guenther wrote:

> 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.

Yes, we are way beyond our originally intended publication date.

> 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.

Agreed.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 8 Feb 2007 18:11:47 -0500

...

> to break loops.

Ah... I didn't get that connection at all.  OK, there is the text later
in that section:

   Implementations SHOULD take measures to implement loop control,
   possibly including adding headers to the message or counting Received
   headers.

So it sounds like you are saying that the new text about how the count
of Received headers MUST be larger is connected to that.  That since
some implementations may choose to count Received lines to avoid loops,
all implementations must have a higher Received line count when doing
redirect.  I don't see that as a valid prescription, I think that the
"take measures to implement loop control" is enough (especially since I
don't really think that Received-line counting is all that great a
technique).

I don't mean to be anal (other than it coming naturally, perhaps),
but I just don't see that as a valid justification for the MUST.
(Even though I am in favor of implementations adding a Received line.)

  ...

> I hope I'm not coming across as trying to dodge the issues here.

And again I hope I'm not being a pain.  However the text I commented on
is new as of -10, so it seems [more] reasonable to comment on it.  It
may be that everyone decides it's a non-issue... so be it.

At any rate I feel conflicted:  I like the idea of recommending that
implementations add a Received line, but not in the "redirect" section.
Evidently it's too late for that.  I not wild about the new MUST in the
redirect section, especially now having learned that its only reason for
being there is for loop control.  (I could probably even imagine good
reasons for removing some Received lines prior to redirect-- but I
dunno.)

My 2c...

-mm-

---

From: Tim Showalter <[email-masked]>
Date: Thu, 08 Feb 2007 16:44:13 -0800

Mark E. Mallett wrote:
> redirect.

If two (or more) implementations are configured to loop, just one adds 
Received headers and uses them for loop control, that's enough to stop 
the loop.

I can't imagine why anyone wouldn't add Received anyway, just based on 
advice in 2821 (and common sense).

Tim

---

From: Philip Guenther <[email-masked]>
Date: Thu, 8 Feb 2007 22:04:40 -0700

>> all implementations must have a higher Received line count when doing

Yes.  That seemed to be the list concensus, based on the thread with 
subject "Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla" at 
the beginning of November.  I didn't see any one arguing against mandating 
the addition of Received header fields by 'redirect' back then, so I took 
it to be agreed.

> Received headers and uses them for loop control, that's enough to stop the 
> loop.

Yes, but if just one implementation (in the "code base" sense) does _not_ 
add Received header fields and it is installed at multiple site, then it 
can sustain a loop.  Heck, an implementation with no loop control can be a 
mailbomb generator if it supports multiple redirects for a single message: 
it would just a sieve script that redirects to its own address as well as 
the victim address.

> advice in 2821 (and common sense).

Common sense is as common as a sense of humor, apparently.  (References to 
solving the Halting Problem were removed from 3028bis after multiple 
reviewers expressed their dislike for the text.)

Philip Guenther