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? The intent seems to
be that the message should appear to have come from the original sender,
except for the Resent-* headers. This implies keeping the original
return-path, but that creates an odd situation. In the event of delivery
problems for the resent message, the original sender may receive bounce
messages from recipients that are completely unknown to him. He can read
the headers and figure out what happened, but the typical end-user can't do
that. The resender, who _is_ interested in DSN's from recipients to whom he
resent the message, wouldn't get them.
From the standpoint of responsibility for a message, the resender is
reintroducing the message back into the message stream with an entirely new
set of recipients and an optional Resent-Message-ID, so one could make an
argument for the return-path being that of the resender. The argument is
stronger if there is a new message ID, but that does not seem to be
required. None of this really matters if the standards and current practice
dictate that the return-path remain unchanged, I was just curious what the
rationale and supporting standards were. 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?
--
Seth Goodman