RE: Multiple "To:" and "Cc:" header lines in SMTP messages

Ned Freed <Ned.Freed@innosoft.com> Sun, 29 September 1996 20:42 UTC

Received: from cnri by ietf.org id aa12686; 29 Sep 96 16:42 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa26173; 29 Sep 96 16:42 EDT
Received: from localhost (localhost.0.0.127.in-addr.arpa [127.0.0.1]) by list.cren.net (8.7.6/8.6.12) with SMTP id PAA09600; Sun, 29 Sep 1996 15:58:22 -0400 (EDT)
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.7.6/8.6.12) with ESMTP id PAA09588 for <ietf-smtp@list.cren.net>; Sun, 29 Sep 1996 15:58:17 -0400 (EDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01IA0BJ1M1FK8Y55C6@INNOSOFT.COM>; Sun, 29 Sep 1996 12:57:26 -0700 (PDT)
Message-Id: <01IA1VJAHV4Q8Y55C6@INNOSOFT.COM>
Date: Sun, 29 Sep 1996 12:44:32 -0700
Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
From: Ned Freed <Ned.Freed@innosoft.com>
To: "John W. Noerenberg" <jwn2@qualcomm.com>
Cc: bill@attmail.com, tjm24297@rpc1220.daytonoh.ncr.com, ietf-smtp@list.cren.net
Subject: RE: Multiple "To:" and "Cc:" header lines in SMTP messages
In-Reply-To: "Your message dated Thu, 26 Sep 1996 18:39:04 -0700" <v03010318ae70db29c4f7@[129.46.166.223]>
References: <3.0b24.32.19960926081741.0051af38@rpc1220.daytonoh.ncr.com> <BILL.96Sep26114451@pegasus4.ATT.COM>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN

> The problem is that *any* interpretation is guaranteed to be wrong to
> someone because the specification explicitly states the semantics of
> multiple occurences is undefined.  Consequently, the safest course for an
> implementor wishing to avoid the ire of other implementors is to avoid the
> generation of multiple occurences of addressee fields.

Unfortunately, this approach is far from safe. The fact of the matter is that
given the current state of the infrastructure application of this approach
leads directly to bounced messages. This is a much more serious problem than
the reply-to-all function sometimes not picking up all the addresses it should.

The problem with putting all of the addresses in a single instance of a given
field is that older version of sendmail (1) Have a 1024 character limit on the
size of a single unfolded field, (2) Truncate any field that's longer, making
it illegal, and (3) Bounce the message because of the now-illegal field value.

Newer versions of sendmail do not have these problems, but these newer
versions have yet to achieve anything resembling dominance in the installed
base.

This doesn't mean that what the agents originally being discussed here do is
right -- these sorts of agents typically put each address into a separate field
instance, and this is totally unnecessary. However, the blanket assessment that
only one field instance should be used no matter what is, if anything, worse,
since situations do exist where many recipient addresses must appear in these
fields. (In particular, the requirements of some government agencies are such
that large mailing lists must be expanded into the header so that the potential
readership of a given message at the time the message was sent can be
established.)

> Having said that, it's worth considering collecting like-named addressee
> headers into a single list for that header.  I agree a liberal
> interpretation would be useful.

It isn't merely useful, it is essential since there is no alternative to
using multiple instances of a field sometimes.

				Ned