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

[Ned Freed <[e-mail]>]

> 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.

My problem is that we do have strong, specific knowledge that generation of
multiple fields is necessary when many addresses are involved and the
environment is the Internet as a whole. As such, while I do not think this is a
practice we should encourage, it is something that it needed a lot more often
than people seem to think.

> > > - 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.

Actually, it is exactly what I mean. The sender has only two choices: Use a
single field and have the message rejected at a nontrivial percentage of
destinations or use multiple fields and possibly have any reply the recipient
generates not reach all of the intended destinations. Given these choices, the
sender is going to generate those multiple fields each every time. I'm getting
closer and closer to making the generation of multiple fields the default in
PMDF, BTW, because doing it the "correct" way is costing us significantly in
terms of product support and the answer to the problem is always the same.

Given that this is reality of the situation, the question becomes one of
whether or not we care about reply-to-all working in all cases. If we don't
really care about this then SHOULD ACCEPT is fine, if we do care then MUST
ACCEPT is the only realistic choice. And since I think we do care, I don't
think we have a choice.

> 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.

I might buy this if I saw any evidence of an extremely strong and immediate
trend towards getting agents deployed that can handle very long fields.

However, the trend I see is just the opposite -- as far as I can tell the
combination of deployment of broken agents and the deployment of agents capable
of generating multiple fields to deal with these broken agents is still
occurring faster than the combination of deployment of working agents and the
replacement of broken agents with working ones. And keep in mind that only an
extremely strong and immediate trend towards getting working agents in place is
meaningful insofar as what the standards say because anything less begins
to approach the timeline on which standards themselves get revised.

BTW, I'm also seeing an increased trend towards the generation of very long
header fields, mostly because our present infrastructure doesn't adequately
address the need for private mailing lists.

				Ned