Currently, if I 8as a programmer) want to alter the sent msg in any way, I have to add my code somewhere directly in the codepath for composition/sending. this is unfortunate in general. Also, some people claim that such code for PGP must not be added. Create a way to plug in code that alters the sent msg. It shoudl allow for yet unknown code, e.g. I should be able to install the plugin without any recompiling. My suggestion: Define a sufficient method signature for calling the plugin from composer during the sending process, i.e. after the user clicked "Send". There is no UI whatsoever. All registred plugins will be called and it is up to the plugin to decide, if it will act. The plugin might add UI to the Mailnews Composer in ways offtopic to this bug. Implementation: There will be an XPCOM interface that consists (ideally) of only the method defined above. All plugins must implement this interface. Another implementation of the interface acts as kind of "deflector", finding all registered XPCOM components implementing this interface and calling them one by one. The composer send code will then call this implementation with the to-be-sent msg and take the result of the method as the to-be-sent msg. The method could include a return param in which the plugin tells, if it altered the msg at all. This could improve speed and decrease the likelyness of hard-to-track-down bugs in common situations. If any of this (in "implementation") is not possible, please correct me. I think, this would be a minimal interface for composer plugins (minimal = easy to implement) and it would do its job for PGP, S/MIME and friends. Maybe, it could even be used to extend Composer in a general way, e.g. a UI to add arbitary headers to the msg.

See http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html ("rough architecture notes for PGP & S/MIME integration with mozilla mail & news"). A point not covered there at this time: There should be a way to affect the order in which the plugins are called (e.g., spellchecker must run before encryption). I think declaring several predefined priorities (with guidelines on which to use for common purposes) would suffice.

Has any progress been made on this bug? One of the reasons I intially got interested in Mozilla was the possibility that there may be such an interface. I also realised around the same time that for many plugins that filter a message, a local proxy that forwards messages to/from a specific server would suffice. At this level, mozilla preferences could expose server types that wrap the remote server in the appropriate filter, and make the proxying transparent to the user. The hard work in mozilla for this method of filtering would be invoking the server, updating the server's preferences, and monitoring the state of the server.