Q: Why doesn't LISTSERV include CC:d addresses in distributed messages?

By Jacob Haller
Senior Support Engineer, L-Soft

When LISTSERV distributes a message to a list, it modifies certain email headers by adding a "Reply-To" or "Sender" address as well as a DKIM signature. It also standardizes the "To" and "Cc" fields so that they contain only the mailing list address. This is done for a couple of different reasons:

It makes it easier for your subscribers to identify messages coming through the mailing list or set up a filter to move list messages to their own folder.
For mailing lists with a restrictive "Send" setting, the Cc:d users may not be able to post to the mailing list. If LISTSERV maintained the original "Cc" addresses, and if subscribers to the mailing list continued to Cc them in replies to the original message, then the Cc:d users would be caught in a situation where they wouldn't be able to reply to the mailing list. They would be trapped in a discussion that they could neither participate in nor leave.

To prevent this, addresses present in the original message's "To" and "Cc" fields are moved to "X-To" and "X-Cc" headers, or "Comments: To" and "Comments: Cc" headers, or dropped altogether, depending on if the mailing list has an X-Tags list configuration setting configured.

We don't normally recommend changing this but also recognize that there may be cases where it's desirable for Cc:d addresses to be preserved. For those situations, you can use the following workaround.

The IETFHDR Subscription Option

There is a subscriber setting called IETFHDR, which tells LISTSERV to not alter most of a message's headers when it distributes it to subscribers who have the IETFHDR subscription option set. In particular, subscribers set to IETFHDR would see the original "To" and "Cc" headers in the messages that they receive.

IETFHDR has some side-effects:

With IETFHDR, the mail headers cannot be changed in any way by LISTSERV (with one exception, see below). If someone sends mail to LisTnAmE@lIstserV.HoSt.CoM, that capitalization is exactly what people on the receiving end will see if their subscription is set to IETFHDR.
The "Reply-To" and "Sender" settings have no effect on messages sent to subscribers who are set to IETFHDR.
Messages posted to the mailing list will have a "Sender" header pointing to the owner-LISTNAME@listserv.host.com address. This is not configurable and cannot be disabled. (This was one of the requirements of the proposed standard that IETFHDR is based on. See the historical note at the end of the tech tip for some background information on this.)
The SUBJECTHDR subscription option (which tells LISTSERV to add the mailing list's name to the subject line of messages that it distributes) cannot be set at the same time as IETFHDR. You can however add Misc-Options= IETFHDR_SUBJECT_TAG to a mailing list's configuration to cause the subject tag to be added to subscribers with the IETFHDR option set, causing IETFHDR to function similarly to SUBJECTHDR in that way. This will affect all subscribers set to IETFHDR.

Setting and Removing IETFHDR for Individual Subscribers

A list owner can set an individual subscriber to IETFHDR by going under "List Management > LISTSERV Command" and issuing a command like this:

quiet set LISTNAME IETFHDR for subscriber@example.com

That subscriber (and only that subscriber) will see messages that are posted to the mailing list with their original "To" and "Cc" headers intact. You can use this method to test out this option before setting it for the entire mailing list, or if there are particular subscribers who would find this option useful.

If you want to remove the IETFHDR setting for an individual subscriber, you can go under "List Management > Subscriber Management", find the user's subscription and choose another option under the "Headers" section of the subscriber options area.

Setting IETFHDR for All of the Mailing List's Subscribers

If you decide to make all subscribers have this subscription option, first go under "List Management > List Configuration" and enter Default-Options= IETFHdr to set this option for all new subscribers. If there is already another HDR option listed in Default-Options (for instance, SUBJECTHDR or FULLHDR), then remove it at this time.

Then, go under "List Management > LISTSERV Command" and issue the following command:

quiet set LISTNAME IETFHDR for *@*

This will apply the IETFHDR setting to all existing subscribers.

Undoing the IETFHDR Setting

If you set IETFHDR option for all of your subscribers and later determine that it isn't well-suited to your needs, then you can undo the changes as follows.

First go under "List Management > List Configuration" and change the Default-Options setting to what it was before you added IETFHDR. In most cases, this will just require removing IETFHDR from the setting, or if there aren't any other parameters in the setting, removing the Default-Options line altogether. If you previously had another header option, for example SUBJECTHDR in Default-Options, then you would restore it now.

Second, go under "List Management > LISTSERV Command" and issue a command like this:

quiet set LISTNAME FULLHDR for *@*

This will replace the IETFHDR option with FULLHDR for all existing subscribers. If you instead wish to set it the SUBJECTHDR or another header option, then you would substitute that option for FULLHDR in the command.

A Historical Note about IETFHDR

The IETFHDR subscription option was introduced in 1993 in LISTSERV 1.7f, following discussions in an Internet Engineering Task Force (IETF) working group regarding mailing list practices. The option was introduced to mimic the behavior required by what the group intended for an eventual "IETF LISTSERV" standard, and in the LISTSERV 1.7f release notes it stated:

It is important to understand that these headers are [...] being provided to answer requirements from Internet specialists; it is "their" headers, not "ours". They are not meant to be user-friendly and are not open to negotiations. They will not spawn sub-options with various bells and whistles added. They are here to allow LISTSERV to emulate an SMTP redistribution list if desired, and nothing more.

In the event, the "IETF LISTSERV" standard never materialized.