[Mailman-Developers] Modifications to msg

[John W Baxter]

At 18:56 -0800 3/18/2002, Dan Mick wrote:
>> RFC 2822 rules on the number of specific headers a message can have.
>> E.g. it can have many Received: headers, but only one Reply-To: header
>> (although the latter allows for multiple addresses... go figure).
>
>Ease of parsing.  No one but humans typically looks at Received:,
>but dumb MUAs need to use Reply-To:, so complicated tricks for
>accumulating a list are limited there.  (at least that's what
>I'd guess at for a rationale.)

There is rather tortured logic in the old (and maybe new) documents
justifying the ability to have multiple addresses in the single From:
header.  Personally, I've never sent or received one of those, even as a
test message (I'm sure to get one now, having said that ;-)).

The other side of the coin is that there almost have to be multiple
received headers (OK, there could be one, munged some more by each handling
MTA, but that sounds dangerous for several reasons including ultimate
size), since multiple MTAs along the message's travel MUST each include a
Received: header (or would have to stick the information into the one
Received: header given the other rule).  And, of course, too many hops
would be harder if the MTAs had to unwind a 30 sub-item Received: header.


So let's turn the question around:  of what headers is there a logical
reason for multiples.

1.  Received, for the reasons mentioned.
2.  X-anything (I suspect, since there's little control over those)

But not Date: (despite the appearance of multiple ones of those in some
messages) and several others.

Reply to: ??  There probably shouldn't be huge numbers of Reply to:
addresses.  Multiple addresses are probably allowed on the same sort of
reasoning as multiple addresses in From:--the boss and the secretary thing.

(Unlimited reply to headers sounds like a great way to get a Spam
multiplier effect, but that wasn't a consideration at RFC writing time.)

And remember, too, that some things in RFCs are the way they are because
that's the way they are (and are hard to explain any other way).

  --John

-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA