Re: 3028bis, section 4.2, paragraph 2

Arnt Gulbrandsen wrote:

> Arnt Gulbrandsen writes:
>
> > Philip Guenther writes:
> >
> > > 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?
> > 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.
> 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.)