[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Multiple "To:" and "Cc:" header lines in SMTP messages
> 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
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
> 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.