On Thu, 8 May 2003, Greg A. Woods wrote:
> FYI, Smail-3 sends to them all, just as it would if the "resent-" prefix
> was not present.
I don't like that because it is crazy when there are several sets of
them. But see my further comments below.
Tony Finch has pointed out that RFC 2822 specifies that Resent- headers
should be added at the front of a message, so different sets are
separated by Received: headers. Sadly, the MUAs don't seem to follow
this rule. I "bounced" a message from Pine. What was delivered was as
follows:
Received: by new receiving MTA
Received: by bouncing MTA
X-Received: the Received's for the original message
X-Received:
X-Received:
Message-ID:
Date:
From:
User-Agent:
X-Accept-Language:
MIME-Version:
To:
Subject:
Content-Type:
Content-Transfer-Encoding:
ReSent-Date: <=== these have been added at the end,
ReSent-From: <=== not at the start
ReSent-To:
ReSent-Subject:
ReSent-Message-ID:
Where does emacs add its Resent- header lines? Does it obey 2822 or not?
I then re-bounced the message. At least Pine does the X- thing. I ended
up with:
X-ReSent-Date:
X-ReSent-From:
X-ReSent-To:
X-ReSent-Subject:
X-ReSent-Message-ID:
ReSent-Date:
ReSent-From:
ReSent-To:
ReSent-Subject:
ReSent-Message-ID:
If all MUAs that use Resent- with -t behave like this, then I suppose it
is safe to take recipients from all the Resent- header lines. It seems
to me, though, that this behaviour is disregarding what RFC 2822 says.
<grumble>
This is yet another example of behaviour that "everybody does that way"
which never gets documented, and which is never standardised because the
standardisation process is too laboured.
</grumble>
Bottom Line: I suppose the bottom line is "If an MUA uses -t to submit a
message that contains Resent- header lines, it has to know what it is
doing, and should ensure that there are no Resent- lines that contain
recipients it does not want, because the MTA may take recipients from
all of them." I suppose that is the origin of the X- behaviour.
This is too late for 4.20 now. I an wrapping the code so that it can get
released some time next week. I do not want to delay, because I am going
to be away for the first two weeks in June (not a vacation, an Internet
workshop in Kampala), and not long after I get back there is the next
Exim course in Cambridge [There are plenty of places left, folks! Sign
up now!] It will therefore be July before I do any further development.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
