If I can avoid it, I don’t run an email server on my machines. Instead I opt for using an email service like https://postmarkapp.com/. This normally involves me not using their api but rather their non-preferable smtp option. I always though it would be great if I could extend the cfmail tag to use the API but I just spotted the core.packages.lib.email.cfc in Farcry.
It doesn’t appear to be used. Is there a reason for this?
For the likes of ‘forgot my email’ etc, if we did move to using core.packages.lib.email it would be then worthwhile writing a plugin for postmark (and the like) that extended it, so you could configure in the admin for the api.
Thoughts anyone? Is there a reason it’s not being used?
The plan was/is to progressively update core. We decided it was worth
adding to core, even with those updates, because we wanted to get in the
habit of using that library for project specific emails, for exactly the
reason you’re describing. It makes it much easier to move between email
services. It has probably gone on the backburner because:
- most email services support the standard email protocols, and
- we’ve started using docker, and configuring email settings via
Which means that switching between services is already very easy.
I’m not really sure what the future of the email lib is, and would like to
hear your thoughts.
Good to know the origins of it. (is it the appendix of FC )
I guess my mind originally stems from CF with it’s single email server setup. So every time I wanted a site to use a different smtp I had to find all those cfmail’s and manually change them. I don’t use Docker, but with the move to Lucee it’s now easy to setup the email service on a per site basis.
Ergo, going forward, the only reason to move to a send service might be:
Ability to use an email service api (like postmark, but I’m unsure of the real benefit here)
Add additional actions to the transaction (eg logging, optin email marketing etc)
Add templates to emails (eg header and footers etc)
Using the full service api for something like PostMark would allow you to act on bounces, and other errors. You can show the reporting within your webtop; for example, delivered, opened, etc.
We use PostMark ourselves but generally we just look at PostMark’s own reporting.