[ On Friday, May 9, 2003 at 10:03:48 (+0100), Philip Hazel wrote: ]
> Subject: Re: [Exim] -t and Resent- header lines
>
> I don't like that because it is crazy when there are several sets of
> them. But see my further comments below.
Smail simply treats resent-* headers simply as replacements for the
non-prefixed headers. I believe that's what sendmail does as well, but
it's been a while since I've had time to find and read the relevant bits
of its source code. The "obsolete" syntax in RFC 2822 specifies:
When multiple occurrences of destination address fields occur in a
message, they SHOULD be treated as if the address-list in the first
occurrence of the field is combined with the address lists of the
subsequent occurrences by adding a comma and concatenating.
and Smail is still primarily an RFC 822 compatible mailer, and not a
2822 compatible mailer.
On the other hand I don't see any explicit mention one way or another
about what should be done when multiple copies of a destination field
appear if the obsolete syntax is not supported. Given the relatively
unstructured nature of mail headers I don't see why the support for
multiple headers of the same name was omitted from RFC 2822 either.
> 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.
It's a "should" rule, and it's a very silly and unjustifiable rule. Yet
another problem with RFC 2822 overstepping its (own[1]) bounds. Most headers
have no guaranteed order (with the lone exception being received headers).
[1] RFC 2822 does at least include this sage bit of advice:
3.6. Field definitions
[[ .... ]]
It is important to note that the header fields are not guaranteed to
be in a particular order. They may appear in any order, and they
have been known to be reordered occasionally when transported over
the Internet.
> 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.
MUAs add resent-* headers to indicate that the user is resending the
message. The MTA's job, when it is using headers, is to use those
prefixed headers in place of the non-prefixed ones, fixing them up as
necessary, and to add any missing but required prefixed headers.
What the MTA does with any existing resent-* headers when the user is
resending a message that was already resent to them is of no concern
here. However I've seen MUAs delete the existing prefixed headers,
prefix them again, put X-* junk in front of them, etc. I have never
seen them simply left alone as RFC 2822 improperly suggests.
> <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>
That's because the people on the standards committees often fail to
fully understand and appreciate the implications of what is often
initially their primary goal when they are updating an existing and
widely used things: Document common behaviour. This is partly why
RFC's 2821 and 2822 took many times too many years to complete and for
certain why they are full of bizzare and unnecessary junk; and similarly
why we now have this horrible invention called C99. These problems can
only get worse as profit-oriented interests gain increasing influence.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
