The headers code is wierd. There're at least 5 different definitions for headers. Trying to add a header will be not just painful, but be a potential source for bugs. I'd vote for one or two classes, which (1) store the values and (2) know the protocol. Some relevant files: http://lxr.mozilla.org/seamonkey/source/mailnews/compose/public/nsIMsgCompFields.idl http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompFields.cpp#573 http://lxr.mozilla.org/seamonkey/source/mailnews/mime/public/nsMailHeaders.h http://lxr.mozilla.org/seamonkey/source/include/libmime.h http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompUtils.cpp#197 (UI files not listet)

Giving up for now :-(. Maybe later.

This attached proposed design is the result of the mentioned discussion on .mailnews. Not sure, if all this (including this bug) is still valid. Adding alecf to CC, as he knows the current infrastructure well. I added descriptions for arrows, because I don't know UML. Please point me to errors.

I am beginning a long an arduous process which hopefully will result in a rewrite of the libmime code in a nice C++ish XPCOMish way (see bug 248846). If anyone is interested in making such changes, I believe it will be easier when there is no more legacy code in the obfuscated pseudo-object system which is hardly interoperable with the rest of Mozilla. For the time being it would be easier for me if the libmime code were left untouched. If anybody finds it urgent to work on this bug right now, please coordinate with me. For now, I am marking this bug dependant on the rewrite bug.