In response to considerable user demand, I have begun work on a significant change to the way Mercury manages domain names. In all versions of Mercury up to and including the current ones, it has been possible to have multiple domain names serviced by a single Mercury instance, but all such domains shared a single user database (so, if you had a user called "john", then that user would appear in all the domains serviced by Mercury). Over time, it has become desirable to allow different domains to have their own users and mailing lists, separate from other domains on the server. There has also been growing demand for specialized types of domain, such as "MX Domains", where a Mercury instance can act as a secondary mail server for a domain that is not otherwise local (i.e, has no local users on the Mercury system). Finally, with a move to truly separate domains, it makes sense to allow domains to have their own specific filters, content and spam controls, whitelists and other mail processing controls, something not possible in the current implementation.
Providing these and other new capabilities will require considerable internal restructuring of the way Mercury works, and as an unavoidable consequence, certain internal Mercury API calls (the special functions made available to developers of third party expansion and plugin modules) are going to be affected. It is my aim to keep the disruption to the interfaces as small as possible, but there is inevitably going to be the possibility that some some existing third-party Mercury Daemons might require some adjustments. If you are a developer of Mercury Daemons, I would like to invite you to join the Mercury beta testing process so you can be kept informed of the changes well before the new code sees public release - please mail me directly, using my David.Harris@pmail.gen.nz address if you would like to take part.
In response to considerable user demand, I have begun work on a significant change to the way Mercury manages domain names. In all versions of Mercury up to and including the current ones, it has been possible to have multiple domain names serviced by a single Mercury instance, but all such domains shared a single user database (so, if you had a user called "john", then that user would appear in all the domains serviced by Mercury). Over time, it has become desirable to allow different domains to have their own users and mailing lists, separate from other domains on the server. There has also been growing demand for specialized types of domain, such as "MX Domains", where a Mercury instance can act as a secondary mail server for a domain that is not otherwise local (i.e, has no local users on the Mercury system). Finally, with a move to truly separate domains, it makes sense to allow domains to have their own specific filters, content and spam controls, whitelists and other mail processing controls, something not possible in the current implementation.
Providing these and other new capabilities will require considerable internal restructuring of the way Mercury works, and as an unavoidable consequence, certain internal Mercury API calls (the special functions made available to developers of third party expansion and plugin modules) are going to be affected. It is my aim to keep the disruption to the interfaces as small as possible, but there is inevitably going to be the possibility that some some existing third-party Mercury Daemons might require some adjustments. If you are a developer of Mercury Daemons, I would like to invite you to join the Mercury beta testing process so you can be kept informed of the changes well before the new code sees public release - please mail me directly, using my <a href="mailto:David.Harris@pmail.gen.nz" title="Contact David Harris" target="_blank" mce_href="mailto:David.Harris@pmail.gen.nz">David.Harris@pmail.gen.nz</a> address if you would like to take part.