In August of 2021, the Symfony team announced the deprecation of Swiftmailer with introduction of the Symfony/Mailer package that provides a modern and extensible approach to sending mail in PHP. We had originally planned to tackle this in Grav 2.0, but we have been slow to get Grav 1.8 ready for release, and 2.0 got pushed further out. So I decided to take a look and see if it was possible to create a backwards compatible version of Email utilizing Symfony/Mailer while still allowing full functionality and even add the ability to have 3rd party plugins to provide custom email transports.

Testing Email 4.0

This new version is available in the testing branch of GPM, so all you need to do is to change your System configuration to use testing releases:

gpm:
    releases: testing

You can also do this via the Admin plugin in Configuration ⟶ System ⟶ GPM Section ⟶ GPM Releases.

After this you should see several email related updates tagged with testing. The intial release is for Email v4.0.0-rc.1 and various associated transport plugins each tagged v1.0.0-rc.1. Please install and test and provide feedback in the Email plugin GitHub Issues

Email Address Flexibility

We've also moved away (while still full supporting) the default behavior of prior Email plugin releases, of having separate fields for an email address and name. Rather, we primarily use the RF822 format in a single text field: [email protected] <Bob Smith>. Email 4.0 actually supports many email formats automatically such as:

Yaml Syntax:

to: '[email protected]'

to: '[email protected] <Bob Smith>'

to: [[email protected], Bob Smith]

to: {email: '[email protected]', name: 'Bob Smith'}

to: {mail: '[email protected]', name: 'Bob Smith'}  #(for backwards compatibility)

And of course arrays of these various formats for multiple email addresses.

New 3rd Party Plugins

The Symfony/Mailer package also provides a number of 3rd party transports, and we have created associated Grav Plugins that integrate automatically with Email 4.0. These allow you to use API and sometimes HTTPS based communication which are much faster, provide better tracking and debugging, and are overall far superior to traditional SMTP.

The default supported list include:

• Amazon SES (symfony/amazon-mailer)
• Gmail (symfony/google-mailer)
• MailChimp (symfony/mailchimp-mailer)
• Mailgun (symfony/mailgun-mailer)
• Mailjet (symfony/mailjet-mailer)
• Postmark (symfony/postmark-mailer)
• SendGrid (symfony/sendgrid-mailer)
• Sendinblue (symfony/sendinblue-mailer)
• OhMySMTP (symfony/oh-my-smtp-mailer)

I also wanted to test the ability to support other providers and as we often use Mailersend ourselves, I created my own symfony/mailersend-mailer package and bundled that up in a plugin also. This served as a proof of concept and proved that any 3rd party email provider could be integrated with Email 4.0.

Mail Queue Functionality

During development I realized the built in spool-based queue functionality of SwiftMailer, that was always optional, never really worked that well, and required scheduling to setup, was not going to be easy to support. Even though Mailer has more much powerful queue functionality it requires external message queue systems, and that was something I didn't want to deal with in this first version at least. I feel very few users actually use the Queue and with modern Email services and API functionality, it's really not as useful as it was when we only had SMTP and strict sending limits. So for now Email 4.0 will not support queues, but everything else should remain the same.

If there is an outcry from the community about this functionality being removed, I'll circle back and take a look at what it would require to add Symfony/Mailer's queue support.

More information

For more information regarding configuration, integration with Grav, and setup help for a variety of Email providers, please review the Email plugin's README.md