As I understood Meteor internally uses nodemailer to send emails and creates the corresponding transport based on the defined MAIL_URL environment property.
We have implemented an EmailSenderService which creates several different nodemailer transports. It uses the account settings defined as settings for production mode and a hardcoded ethereal account for development mode.
I wonder if and how it is possible to change the internal Meteor email handling to use our application specific EmailSenderService to send all kind of emails especially the ones send via the account-password package (e.g. enrollment- and forgot-password-emails). My idea is to redirect the calls to the central Email.send function to our EmailSenderService instead of calling the Meteor internal logic.
Thank you for thinking along and any upcoming ideas and hints...
You've got a few options:
Email.send
As @iiro says, you can just monkey patch the Email
module by replacing the send
method with your own.
Email.send = function (options) {
return EmailSenderService.send(options);
}
email
package with a local versionIf Meteor finds a package of the same name in the packages/
directory of your project, it will use that one over it's own implementation. Documentation
Email.send
EDIT: I didn't see that EmailTest
isn't exported. So this only works by making a local copy like in option 2.
Looking at the source of the email package, there's a hook which is run at the start of Email.send
and allows you to prevent the default execution by returning false. You could use this like so:
EmailTest.hookSend(function (options) {
EmailSenderService.send(options)
return false; // To stop default sending behaviour
});