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

John C Klensin <klensin@mail1.reston.mci.net> Sun, 29 September 1996 23:32 UTC

Received: from cnri by ietf.org id aa16405; 29 Sep 96 19:32 EDT
Received: from list.cren.net by CNRI.Reston.VA.US id aa10099; 29 Sep 96 19:32 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 SAA12761; Sun, 29 Sep 1996 18:51:36 -0400 (EDT)
Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by list.cren.net (8.7.6/8.6.12) with ESMTP id SAA12732 for <ietf-smtp@list.cren.net>; Sun, 29 Sep 1996 18:51:19 -0400 (EDT)
Received: from white-box.jck.com ("port 2061"@white-box.jck.com) by a4.jck.com (PMDF V5.0-5 #16053) id <0DYINHIZG000CC@a4.jck.com>; Sun, 29 Sep 1996 18:51 -0400 (EDT)
Message-Id: <SIMEON.9609291817.C@white-box.mail1.reston.mci.net>
Date: Sun, 29 Sep 1996 18:51:17 -0400
Reply-To: John C Klensin <klensin@mail1.reston.mci.net>
Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
From: John C Klensin <klensin@mail1.reston.mci.net>
To: Ned Freed <Ned.Freed@innosoft.com>
Cc: "O'Brien, Walt" <Walt_OBrien@dg-webo.webo.dg.com>, 'ieft-smtp' <ietf-smtp@list.cren.net>, Harald.T.Alvestrand@uninett.no
Subject: Re: Multiple "To:" and "Cc:" header lines in SMTP messages
In-Reply-To: <01IA1WOQ216Q8Y55C6@INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit
X-Sender: john@mail1.reston.mci.net
X-Mailer: Simeon for Windows Version 4.1a6
X-Authentication: none
X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN

On Sun, 29 Sep 1996 13:24:16 -0700 (PDT)  Ned Freed 
<Ned.Freed@innosoft.com> wrote:
> I disagree; the proper recommendation is "SHOULD NOT generate a single field
> for each separate address". The question of whether or not to generate multiple
> field for lots of addresses should be left open, as it is too
> environment-specific to recommend anything at this time.

Ned, I think we are getting into the fine shadings of meaning here, 
but...

  * I agree with your statement of the SHOULD NOT

  * I would still favor strong guidance to not generate multiple of
    these fields unless has strong, probably environment-specific,
    knowledge that it is necessary.  It is not a practice I think we
    should be encouraging when it is not needed to deal with broken
    systems.

Similarly,

> > - The only recipient semantics that make sense is to treat it as if it
> >   was a single long To: field. So it's a SHOULD ACCEPT.
> 
> I disagree; the proper recommendation is "MUST ACCEPT". And yes, this
> absolutely is a change from RFC 822.

The disadvantage of the MUST ACCEPT on the receiver is that it 
tells the sender that breaking things up into multiple ones of 
these fields is reasonable and accepted behavior, i.e., if they do 
it and the receiver doesn't accept it, it is unambiguously the 
receiver's fault.  I don't think we (or you) mean that. If the 
receiver merely has a "should", then we have an opportunity to 
reinforce the notion that a sending system who does this without 
environment-specific information is putting its users and their 
mail at risk. That is as it should be, IMnvHO.

No one is questioning the fact that there is a problem here, the 
only questions are about tactics and strategy, and I contend that a 
MUST ACCEPT is bad strategy, whatever advantages it might have in 
particular systems in the short term.

    john