# External email handler for user notifications

**URL:** <https://meta.discourse.org/t/external-email-handler-for-user-notifications/51693>\
**Category:** Feature\
**Created:** [18. Oktober 2016 um 14:17 UTC](https://meta.discourse.org/t/external-email-handler-for-user-notifications/51693 "2016-10-18T14:17:41Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![LeoMcA](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/leomca/32/87233_2.png) [@LeoMcA](https://meta.discourse.org/u/LeoMcA)\
**Post date:** [26. Oktober 2016 um 18:47 UTC](https://meta.discourse.org/t/external-email-handler-for-user-notifications/51693/2 "2016-10-26T18:47:52Z")

</div>

Just my £0.02:

> [@sniepoort](#):
>
> This module would for example list all available email types (user\_posted, user\_private\_message, user\_invited\_to\_topic, etc.), and you would have the option to enable or disable for the Discourse email handler.

My thoughts are this wouldn’t be terribly hard from a plugin - one could monkey patch all the appropriate methods, and then based on whether the setting is currently to have the Discourse email handler enabled or not, call `super` within the patched methods, or call your own code.

> [@sniepoort](#):
>
> We’re aware that this is pretty library specific (the Postmark API obviously varies from others), but perhaps a solution could be found for a general use case.

I think the best way would be to write the plugin with the assumption that other APIs will be supported (so, for instance, include a setting to choose which api to use, and therefore write all the code to work based on what that setting is set at), but not necessarily implementing any of them. Then, it should be trivial for another contributor to implement support for whatever email API they want to use, and send a PR.

---

_[View the full topic](https://meta.discourse.org/t/external-email-handler-for-user-notifications/51693)._