On Tue, 28 Sep 2004, Seth Goodman wrote:
From: Tony Finch
Sent: Tuesday, September 28, 2004 8:51 AM
<...>
Try reading RFC 2822 section 3.6.6.
Since this section only talks about 2822 headers, and I can't find anything
that clearly applies in RFC2821, what is the practice for the return-path
for this type of resending and where is it described?
It's implicit in RFC 2822. Since resending involves resubmission by the
MUA in the usual way, the return path of the resent message is the address
of the resender. This makes sense because as you say the resender is
responsible for the additional part of the message's journey, not the
original sender or the final recipient.
Contrast this with the alias-forwarding case where the recipient is
responsible for the forwarding: there's no distinct party responsible for
the intermediate point. In the event of a failure only the sender can be
informed, so the return path remains constant.
Where is resending meant to be used as opposed to creating a new message
containing the original message content or including the original
message as an attachment?
I'm not sure what distinction you are making here.
We use resending when a message has been sent to the wrong person (often
the wrong role address). It is resent to the right address so that replies
to the original sender are simpler -- no need to unencapsulate the
original message.
If there is a need to add a comment to the message then encapsulation
forwarding is the appropriate tool.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BAILEY: SOUTHEAST 5 TO 7 VEERING WEST OR SOUTHWEST 4 OR 5. OCCASIONAL RAIN.
MODERATE OR GOOD.