A while back I noticed that sometimes after setting an encoding and sending to the list that the encoding was lost to UTF-7 anyway. This was about the same time as the list software change so back them I assumed incorrectly that the new software was setting UTF-7 headers (Content-Type: text/plain; charset="utf-7") and loosing my ISO ones (...charset="iso-8859-1"). Now it seems that the way the setting was getting lost was by saving and recalling message drafts in MS OExpress. It is very possible that there are other ways MS will mess this up but

now I think it's fixed.

FYI here is my file entry on the subject. "List of Encoding Problems with Outlook Express: You can't shut off charset encoding. (Two choices: MIME and UUEncode. There is a "MIME: encode text using None" option which doesn't work, it still encodes.) You can't set an encoding 'for once and for all'. There is no clear indicator of the encoding in use (have to go down two menus to check/set each message). Selecting a useful encoding [Western European (ISO)] results in display using an undesirable proportional width font. Manually selected encodings are easily lost and overridden to UTF-7 (example: set ISO, save as Draft, recall, send, it will be UTF-7**) The appearance of an encoding is buggy; what appears when reviewing a saved message is sometimes decoded, sometimes not, with the same message. Can't check a message header on an unsent message." so Sellam aggravation is nothing compared to this <g>