This concerns the way Listserv handles mail where a CC address is present, and is probably a well travelled path of dialog, so don't read on if you're likely to get tired of hearing it ;-) As it stands, when an email is either CC'd to a list, or where it is sent to a list but CC'd to someone else, Listserv removes the non-list address(es) and places them in the mail header Comments field. As I understand it, the main reason it does this is because problems can arise when you include a non-list members in a discussion. For example, the non-member(s) may receive lots of mail as the subject is discussed on the list but when they try to respond, if the list is private, their responses will be rejected. Are there any other reasons that I haven't considered? While the above is understandable, in mine and several of our more technical users opinions, there is an (at least) equally significant drawback. That is, the Comments: field is not displayed (by default, at least) on many (-- probably most) of the major email clients such as Outlook/Outlook Express. The latest complaint I've had about this was where a user had addressed a post to the list and CC'd it to "someone else". In the message he asked people to reply directly to the "someone else". Many of the subscribers then contacted the originator thinking he'd forgotten to CC it to "someone else", or tell them what "someone else"'s address was. One can imagine how frustrating and embarassing that would have been for him. A previous complaint I had was where someone had sent a message to [log in to unmask] and CC'd it to the list. He started the message with "Dear Joe", so when the list subscribers received it there was no visible indication who on earth Joe was. So, what can be done to rememdy this? It has been suggested that one could use the IETFHDR setting so that Listserv does not modify the headers, but that is surely not practical? For a start it is done on a per subscriber basis, but for it to be effective in this circumstance it would have to be applied to all the people on the list (I presume it would cause Listserv to have to send a separate message out to each subscriber aswell, like FULL822 does?). Furthermore, the average user is not that technical or in the case of many of our users they haven't got the *time* to explore the technicalities and intricacies of Listserv, especially when all they want to do is perform such a simply task as CCing something. So if you turn round to them and say "well, all the list susbcribers are gonna have to have their settings changed to IETFHDR for your CCing to work properly" most of them are likely to respond with "what the ....? All I wanna do is .....". The other point is that most users only find out about the way Listserv handles CC's AFTER the event. Having said all that, I do understand that there is no easy solution to this problem otherwise I'm sure it would have been employed before. However, I do feel more could be done by Listserv to help the user understand and deal with it. Here's some suggestions, some of which may not be very well thought out, but here goes anyway: 1) When Listserv recieves the message, if the list is configured as "Send= Public", preserve the To/CC headers. "Send= Public" would mean that the non-members could still participate in the conversation. One possible drawback to this is if the list owner changed the Send= setting after the posting, however, I should think that rare. 2) When Listserv receives the message it holds it in it's queue, sends a message back to the originator explaining what it's going to do to the headers and why, and adds an OK confirmation. If the originator then responded to the OK confirmation Listserv would distribute it as normal. If they didn't respond within 48 hours, Listserv would discard it. The drawback to this is that the message would have been sent already to the other, non-list, recipients, so it might be impractically messy. 3) If no other solution is feasible, then I think that this one should definitely be employed. That is, Listserv deals with the CC in it's current way, but sends out an email to the originator explaining what it has done and why it has done it. Part of the latest complaint I had about this, was that theuser wasn't informed what had been done. If he had, he could have quickly sent out a further note to the list with the guys address on it and saved face. What do other administrators feel about this subject? Am I (or my users) making a mountain out of a mole-hill? Any other suggestions for ways in which it could be improved? Regards -- Spencer Warhurst Listserv Service Manager JISCmail -> http://www.jiscmail.ac.uk Mailtalk -> http://www.mailtalk.ac.uk