CHANGELOG.md

v5.3.5

11/04/2026

1. • Grav 1.7 sites on PHP 7.3 load again. Email 5.3.4 added a PHP 7.4 arrow function to a class that loads on every request, which stopped the whole site with a syntax error #197
   • A mail transport that can't be set up now reports why on PHP 7.3 too, instead of failing with a syntax error
   • A new test fails when a file that loads on PHP 7.3 uses newer syntax. Only the provider and inbound classes may, since they are never loaded below PHP 8.1

v5.3.4

10/31/2026

1. • [security] The security fixes below were found by Anthropic's OSS Scanner
   • [security] A form value longer than 64 KiB is now cut to that length before an email body is converted with process_markdown
   • [security] The Date header of an inbound email is now ignored when it is longer than 256 bytes, and the message is read as having no date
   • [security] Addresses that plugins pass to the email plugin are used as plain text, while the addresses in a form's email action and in the plugin settings can still use Twig such as {{ config.plugins.email.to }}

v5.3.3

10/21/2026

1. • Newsletters can go through a different provider from the rest of the site. A new Newsletter Mail Engine setting (mailer.marketing_engine) beside the mail engine: site mail such as order confirmations and password resets keeps using the mail engine, and anything marked as marketing goes through the newsletter engine instead. Left on "Same as the mail engine", which is the default, everything goes one way as before. A sender marks a message with $message->marketing(); Email::marketingEngine() answers the engine it will use and Email::splitEngines() whether the two differ. Built for a site that sends its own mail through Cloudflare Email Service, which allows transactional mail only, and its newsletters through Resend or SES
   • A provider can say it is for transactional mail only. Capabilities takes an optional transactionalOnly, for a provider whose terms allow receipts, password resets and notifications but not newsletters or other bulk mail, as Cloudflare Email Service's do. A newsletter add-on reads it and refuses to send a campaign through that transport. A transport plugin checks property_exists() before passing it, so it still loads beside an older Email plugin. Written up in docs/providers.md
2. • The debug log no longer records credentials. With debug on, the HTTP transports' whole request, headers included, and the SMTP AUTH exchange went into logs/email.log, which put every API key, token and SMTP password the site sends with into a log file. The Authorization header, the header-borne tokens providers use and the SMTP password are now replaced with <redacted> before anything is logged or returned by getLastSendDebug()

v5.3.2

10/21/2026

1. • A provider can name a test address. A transport plugin's provider class may now have testRecipient(): ?string, answering an address the provider's own documentation names as accepted, delivered to nobody and reported back as delivered, such as Resend's delivered@resend.dev or the SES mailbox simulator. A store testing its delivery webhook sends there, so the test reaches no real inbox and still produces the event it waits for. It is deliberately not on the Provider interface, because a new interface method would be a fatal error in every transport plugin not updated in the same release: consumers ask method_exists(), a plugin that has it still loads beside an older Email plugin, and a plugin without it simply has none. Written up in docs/providers.md, with the rule that only an address the provider documents counts

v5.3.1

10/09/2026

1. • Updated the bundled Symfony Mailer and Mime to 5.4.52 and the IDN polyfill to 1.43.0, which include the fixes for their published security advisories. Thanks @bago #196

v5.3.0

09/24/2026

1. • Inbound mail. A plugin that wants to read mail sent to a site — a helpdesk turning replies into ticket updates, a forum taking posts by email — now has one place to ask. Providers\Inbound\InboundGateway::receive() takes a receiver key, the request and that receiver's config, and runs the same four steps for every provider in the same order: find the receiver (404), check the size against the receiver's limit and the caller's (413, before any verification work), verify (401), and parse, which never throws. What comes back is an InboundResult holding the verdict, the HTTP status to answer with, and the messages. Each message is an InboundMessage with every field a consumer needs already normalised: message ids without brackets and lower-cased, the envelope recipient kept apart from the visible To so a support+token@ address survives, the receiving server's SPF, DKIM and DMARC verdicts read from Authentication-Results, and attachments with their inline cid: ids. Ask Email::supportsFeature('inbound') first; it is true on PHP 8.1 and later, like the rest of the provider contract
   • A provider plugin receives mail by implementing InboundCapable on the provider class it already registers. It is a separate interface rather than a new method on Provider, because every transport plugin implements Provider today and a new method there would be a fatal error in each one not updated in the same release. The rules are the delivery-report rules — authenticate before acting, over the raw bytes wherever the scheme signs raw bytes; parse() never throws and does no network I/O — plus fetch() for providers that send only metadata, which a consumer runs later from its own worker. Written up in docs/providers.md, which also refines the delivery-report rule to the same wording, since SNS and Mailgun sign inside the payload rather than over it
   • Two receivers that need no provider account at all. cloudflare takes each message from a free Cloudflare Email Routing Worker, byte for byte, signed end to end with an HMAC over the raw body, a timestamp and a 300-second window. generic is the same scheme for a Postfix pipe, a forwarder or a cron job. docs/inbound-cloudflare.md has the Worker source, the dashboard steps (including the Subaddressing setting that plus addresses need), Cloudflare's size and CPU limits, and a shell and a PHP sender, all checked against the real verifier
   • An IMAP client that does not need ext/imap, which left PHP core in 8.4 and was never on most hosts anyway. Inbound\Imap\ImapMailbox connects over implicit TLS or STARTTLS (never falling back to plain text), logs in, finds new mail by UID with UIDVALIDITY tracking, downloads it without marking it read, and marks it \Seen and moves it once the caller has stored it — with UID MOVE where the server has it and copy, delete and expunge where it does not. Messages over a size limit are reported without being downloaded, and every failure says whether it was the credentials, the network or the server. For Gmail with an app password and most hosting mailboxes; AUTHENTICATE XOAUTH2 has its place reserved for later
   • A MIME parser with no dependencies. Every maintained MIME library for PHP brings packages Grav core also ships at its own version (guzzlehttp/psr7, pimple/pimple, psr/container) or a dependency-injection container, and Grav loads every plugin's autoloader into one process. Providers\Inbound\MimeParser reads what received mail needs — encoded-word headers, nested multiparts, quoted-printable and base64, charsets (ISO-8859-1 read as Windows-1252, the way mail clients do), RFC 2231 filenames, inline images, forwarded messages kept whole as attachments, delivery reports — and never throws. Tested against Gmail, Outlook (with a winmail.dat) and Apple Mail replies, Latin-1 and Windows-1252 mail, a bounce, an out-of-office and a forward

v5.2.1

09/15/2026

1. • A form that drops every one of its recipients no longer does it in silence. An address the plugin cannot parse is discarded, and when the to parameter produced nothing at all, buildMessage() skipped the call that sets the To header entirely — so the message left with no recipients, the form told the visitor it had been sent, and not one line was written to any log. Every discarded address is now reported to both logs/email.log and logs/grav.log, naming the parameter it came from, the value that could not be read (truncated, so a mailing list cannot fill the log) and whether anything usable was left. The report also names the cause, because in practice there is only one: a Name <address> value that has been through Twig's escape filter, written as |e or applied by autoescape, arrives as John Doe <john@example.com>, which is not an email address by any reading. Address parameters want |raw. Addresses that do parse are handled exactly as before, including a partial failure — those go out to whoever was left, and are logged too, since half a send is every bit as quiet as none of one. Reported by @thekenshow (grav#3905)
   • A form whose email could not be sent stops reading the mail server's refusal out to the visitor. What went on the page was the transport's own words with a stop emoji in front of them, which is written for whoever set up the mail account and not for whoever filled in the contact form — it routinely names the server, names the account, and explains precisely why the credentials were rejected, to an anonymous stranger. The transport's text now goes to the Grav log, where the site owner will actually look for it, and the visitor is shown something a site can configure: an error_message on the email action, or the new Form send failure message setting in the plugin's Email Defaults, or failing both a translated "Your message could not be sent right now. Please try again in a few minutes." With Grav's debugger switched on the transport's text is appended to it anyway, on the grounds that anybody looking at the form with the debugger running is the person configuring it. Reported by @pboguslawski (form#567)

v5.2.0

09/08/2026

1. • bin/plugin email test-email says why a send failed, and what the provider called it when one worked. It answered "Problem sending email..." and nothing else, which is the least useful thing it could say about the one kind of failure only the provider can explain — an unverified sender, a token for the wrong server, an account still pending approval. It now prints the transport's own words and the HTTP response body beneath them, and on a successful send prints the provider's id for the message
   • An SMTP send gets an id too, read off the transcript. Symfony's SmtpTransport asks the server to take the message, reads the answer — 250 Message queued as 68bf1ca9e0d2f — checks the response code and drops the line, so an SMTP store had no provider id at all. It also appends the whole conversation to the SentMessage, so the answer was still there to be read, and it is now. On a provider's own relay that id is the provider's: MailerSend documents the id in this line as the same one their webhooks report events under, and since their webhooks carry no headers, no metadata and not the Message-ID either, it is the only handle a store sending through them over SMTP will ever get. SMTP2GO and SendGrid answer the same way, and an Exim relay spells it id=. Only the final 250 is read, because the ones before it are answers about an address rather than about the message, and a server that accepts without naming — plain 250 2.0.0 Ok — still answers null rather than having something invented from the line
   • The send log line carries the provider's id for the message, which is the first thing worth knowing when a delivery webhook cannot be matched to the message it is about
   • getLastSendId() answers the provider's own id for the message just sent. Every API transport already hands one back — Symfony's Resend, Postmark, SES, SendGrid, Mailgun and MailerSend transports all call SentMessage::setMessageId() with whatever their API returned — and this plugin was collecting it and dropping it on the floor, keeping only the debug string beside it. It matters because it is the same id that provider then names in its delivery webhooks, so it is the one string both ends are certain to agree on. Anything storing it can join a bounce or a delivery report back to the message it is about without needing the provider to echo a custom header, and without needing the Message-ID the message left with to survive the trip — which it often does not: a provider running on Amazon SES mints its own on the way out and reports that one. Null on a failed send and on a transport that answers no id at all

2. • A transport that answers a send with the message's own id no longer has that recorded as the provider's id. Message-ID is an identification header and Symfony answers those with a list of ids rather than a string, so the guard meant to catch this was casting an array and comparing an id against the word "Array" — it had never once fired. Mailgun's API answers a send with the id the message already had, in its wire form with the angle brackets on, so a store on Mailgun recorded its own Message-ID as Mailgun's id for the message; the delivery event that arrived then named a third string again, and the rung of the correlation ladder meant to be the most reliable matched nothing. Both halves are fixed: the header is read as the list it is, and the two ids are compared without the brackets, which are a transport's habit rather than a difference in the id. getLastSendId() answers null on a transport that only echoes, which is the honest answer and lets the match fall to the Message-ID rung that does work
   • A transport that cannot be built no longer takes the whole site down with it. The mailer is built on onPluginsInitialized, on every request, long before anything has decided whether this request sends an email — so a provider plugin that throws while naming its DSN does not produce a failed send, it produces a white screen on every page of the site. Including the admin, including the settings form where the missing field would have been filled in, leaving hand-editing YAML over SSH as the only way back. Found by saving the Mailgun settings with the domain still empty, which is an ordinary thing to do on the way to configuring it. Building the transport is now guarded: the reason goes to the Grav log, the site stays up, and the store gets an UnusableTransport that refuses messages with that reason attached. Deliberately not null://, which accepts everything and delivers nothing — a store whose transport is broken has to be told, because silently swallowing a customer's order confirmation is the worse of the two failures by a distance

v5.1.0

09/05/2026

1. • Email actions and plugins can now set custom headers on a message with a headers parameter, a map of header name to value, applied after everything else. The pair this was added for is List-Unsubscribe and List-Unsubscribe-Post, which together are RFC 8058 one-click unsubscribe: the unsubscribe button next to the sender name in Gmail and Outlook, and the thing a bulk sender is now expected to have. Setting a header that is already there replaces it, a value may be a list for a header that is allowed to repeat, and a name or value that cannot be written is skipped and logged rather than failing the whole send. Plugins building their own message can pass the same list to applyHeaders(), and can ask Email::supportsParameter('headers') first instead of comparing version numbers
   • A test suite, run with tests/vendor/bin/phpunit after composer install inside tests/. It installs into tests/vendor from its own tests/composer.json, so the vendor directory the plugin ships stays free of development packages
   • A provider contract under classes/Providers/, so that everything a mail provider knows about itself — how its delivery webhooks are verified and read, how a webhook is created from a pasted API key, what a sending domain's DNS has to say, and what its transport does to custom headers on the way out — lives in that provider's own grav-plugin-email-<provider> plugin rather than in whatever add-on happened to need the answer first. A transport plugin implements Providers\Provider and registers itself on the new onEmailProviders event; Email::providers() answers the registry, Email::providerFor($engine) and Email::providerByKey($key) find one, and a caller asks Email::supportsFeature('providers') first rather than comparing version numbers. A transport with no delivery API registers nothing, which is a complete answer: a store can then say plainly that the transport cannot report deliveries instead of showing a webhook address nothing will ever post to. Written up for plugin authors in docs/providers.md
   • Email::buildMailerFor($engine) builds a Symfony mailer for a named engine rather than only for the one the site is configured with, through the same transport builder, the same onEmailTransportDsn event and the same DSNs as before. Nothing sends through it yet; it is there so that a site which one day wants some of its mail to leave through a second provider has somewhere to ask for that mailer, without that day being the day the transport builder gets rewritten
   • Providers\Event::$hard now has a documented second meaning on a dropped event, which is the difference between a subscriber who is gone and one who happened to be on the list the morning the store ran out of quota. hard = true means the provider refused the address — it is on that provider's suppression list, or bounced, complained or unsubscribed there — and a store may treat it as permanent. hard = false or null means the provider refused this one message: a daily quota, a virus scan, content it did not like. The address is fine. Event::isRefusedAddress() is the question a suppression list should be asking, and docs/providers.md sets out which of each provider's refusals is which
   • Providers\SendHeader names the header a store stamps its send id into, so that every provider answers the same one and nothing has to hard-code a name. It is X-Grav-Send-Id unless the site sets providers.send_header in the Email plugin's configuration, or an add-on calls SendHeader::override() to name it for the request. The reading of it lives there too — out of a map of custom args or user variables, a {name, value} header list, or SES's message tags — because seven transport plugins were each about to keep their own copy of the same twenty lines. SendHeader::metadataHeader() is the Postmark twin, which is the same value under the X-PM-Metadata- prefix that is the only way metadata reaches a Postmark webhook

v5.0.8

09/04/2026

1. • The help text under the From, To, CC, BCC and Reply-to fields showed the name-addr example as "Your Name " in the new admin, which renders help as sanitised HTML and dropped email@address.org` as an unknown tag. The example's angle brackets are now written as entities so the format the field accepts is actually shown

v5.0.7

08/28/2026

1. • The Spanish translation now covers every string, up from two, and the messages asking you to configure a 'to' or 'from' address no longer name the opposite one. Thanks to @pmoreno-rodriguez

v5.0.6

08/17/2026

1. • Email addresses with a stray space around them are no longer thrown away, so a from, to, cc, bcc or reply_to setting that ends in a space keeps working instead of failing with a confusing "An email must have a From or a Sender header" error.
   • An address setting containing nothing but spaces now tells you that address needs configuring, rather than failing later with that same confusing error.

v5.0.5

08/05/2026

1. • [security] On Grav 2.0, email settings can no longer read your site, system or theme configuration directly, which was a way around the restriction added in 5.0.4 that already stopped them reading it through config (GHSA-p597-crqc-m349). Requires Grav 2.0.16 or later, which is also where the underlying protection for email settings lives.

v5.0.4

08/04/2026

1. • [security] On Grav 2.0, Twig in a form's email settings now runs under Grav's content sandbox, so someone who can only edit pages can no longer use an email action to run commands on the server (GHSA-gh8j-q67c-j53f). Requires Grav 2.0.16 or later.
   • Email settings can still read your site configuration and this plugin's own address settings, so {{ config.site.emails.sales }} and {{ config.plugins.email.to }} keep working, but they can no longer read your mail server password or any other plugin's settings.
   • Grav 1.7 has no Twig content sandbox, so email settings behave there exactly as they did before, and the plugin still runs on the PHP versions that line supports.

v5.0.3

06/14/2026

1. • Email templates that fail to render (a Twig syntax error, or an unresolved include or extends) are now logged to the email and Grav logs instead of failing silently, so a broken template is much easier to track down.

v5.0.2

06/08/2026

1. • Button links in HTML emails now keep their white text in email clients that force their own link color, by targeting the a.btn-primary and a.btn-secondary selectors with !important.

v5.0.1

04/17/2026

1. • Fixed compatiblity

v5.0.0

04/17/2026

1. • Added Grav 2.0 / Admin 2.0 support

v4.2.2

12/10/2025

1. • Fixed createAddress() to gracefully handle empty or invalid email addresses instead of throwing RFC 2822 errors
   • Fixed Twig processing to bypass Grav 1.8's security filter for trusted email config (fixes issues with {% include %} and field names containing mail)

v4.2.1

11/24/2025

1. • Added more details for HTTP error logs when using API-based email providers
   • Addressed a compatibility issue with Grav 1.8beta

v4.2.0

08/25/2025

1. • PHP 8.4 compatibility
2. • Vendor library updates

v4.1.2

01/06/2025

1. • Updated to latest symfony libraries (v5.4.45)
   • Added a note about Google App Passwords for authentication in the README.md

v4.1.1

10/28/2024

• Updated logging methods to support Monolog2+

v4.1.0

04/09/2024

1. • Update vendor libraries for Mailer to latest 5.4 versions
   • When you send an email you can use Email::getLastSendMessage() and Email::getLastSendDebug() methods to get information about the email processing.

v4.0.4

07/10/2023

1. • Fix for email file attachments using stream

v4.0.3

06/29/2023

1. • Simplified the Email::processRecipients() logic for readability
2. • Fix an issue with 2 email addresses provided with 'just' email and no name #176
   • Fix for blank subjectlines when using Message::setSubject() in Twig templates getgrav/grav-plugin-login#299

v4.0.2

06/27/2023

1. • some recipient handling improvements. e.g. missing bcc_name throwing error
   • Allow overriding of defaults with a form configuration. Use null to remove default email configuration

v4.0.1

05/20/2023

1. • Fixed a bug with Email 4.0 ignoring template: parameter when dealing with multiple body sections

v4.0.0

05/09/2023

1. • Migrated from Swiftmailer (which has been deprecated) to Symfony/Mailer, a more modern and extensible mailing library.
   • Built-in support for SMTP, SMTPS, Sendmail and Native (uses best solution per-platform) engines
   • Added ability to have 3rd party plugins that provide new engines (e.g. SendGrid, MailJet, etc.) with SMTP, API or HTTPS transports for faster and more reliable email sending
   • More flexible options for email formatting including RFC822 name-addr format (Joe Bloggs <user@example.com>) and simple arrays ([user@example.com, Joe Bloggs])
   • Support tags and metadata in Email::buildMessage()
   • Two new events onEmailEngines and onEmailTransportDsn to facilitate the integration of custom engines via plugins

v4.0.0-rc.4

02/27/2023

1. • Fixed for multiple recipients #167
   • Fix for simple array format with names which wasn't working

v4.0.0-rc.3

10/27/2022

1. • Fixed an issue with array based email address

v4.0.0-rc.2

10/19/2022

1. • Set sendmail as default engine to provide better fallback for unsupported mailer option
   • Added info about available engine plugins in README.md

v4.0.0-rc.1

10/05/2022

1. • Migrated from Swiftmailer (which has been deprecated) to Symfony/Mailer, a more modern and extensible mailing library.
   • Built-in support for SMTP, SMTPS, Sendmail and Native (uses best solution per-platform) engines
   • Added ability to have 3rd party plugins that provide new engines (e.g. SendGrid, MailJet, etc.) with SMTP, API or HTTPS transports for faster and more reliable email sending
   • More flexible options for email formatting including RFC822 name-addr format (Joe Bloggs <user@example.com>) and simple arrays ([user@example.com, Joe Bloggs])
   • Support tags and metadata in Email::buildMessage()
   • Two new events onEmailEngines and onEmailTransportDsn to facilitate the integration of custom engines via plugins

v3.2.0

03/28/2022

1. • Require Grav 1.7.32 and Form 6.0.0
2. • Added access email message object inside the twig template file
3. • Fixed twig not being initialized when building an email message

v3.1.5

01/03/2022

1. • Updated to Swiftmailer v6.3.0 with PHP 8.1 compatibility #157

v3.1.4

11/16/2021

1. • Added second parameter to Email::send() to get failed recipients

v3.1.3

07/19/2021

1. • Pass page variable to processed forms #141
   • Email configuration available to templates #152
   • New Event after eMail was sent #151

v3.1.2

04/06/2021

1. • Added new onEmailMessage event to make object available for editing #150

v3.1.1

01/31/2021

1. • Latest vendor updates including SwiftMailer 6.2.5
   • Updated CLI commands
   • Minor code cleanup

v3.1.0

12/02/2020

1. • Added support for auth_mode in SMTP engine #101
   • Obfuscate the password shown in the CLI test-email command #140

v3.0.10

11/09/2020

1. • Tweaked default base.html.twig template to better support dark-mode clients
   • Latest vendor updates
2. • Add missing support for template: in body array
   • Added check to process markdown with text/html content type only

v3.0.9

06/08/2020

1. • Disable password autocomplete in password field
   • Don't save empty string in password field #134

v3.0.8

04/27/2020

1. • Updated vendor library files
   • Use Grav's Parsedown class

v3.0.7

03/05/2020

1. • Updated email validator library
2. • Fixed Invalid resource theme:// on CLI command test-email on Grav 1.6.21 and later versions #128

v3.0.6

02/11/2020

1. • Updated email validator library

v3.0.5

02/03/2020

1. • Fixed a date in changelog (no other changes)

v3.0.4

01/17/2020

1. • Added ZOHO configuration example
   • Updated SwiftMailer library for PHP 7.4 support

v3.0.3

08/16/2019

1. • Support an array of multiple emails in email: form process
   • Allow form values in email templates
2. • Added Twig blocks for content and footer in email/base.html.twig template
   • Updated README.md to reflect working setup for GMail

v3.0.2

05/09/2019

1. • Requires Form Plugin v3.0.3
   • Added Russian translation #113
2. • Better fix for missing attachments when sending an email using a form form#333

v3.0.1

04/15/2019

1. • Put a try/catch around email attachments and log any errors rather than hard fail
2. • Fixed missing attachments when sending an email using a form form#333

v3.0.0

04/11/2019

1. • Added new template: to choose twig template option for email form processing
   • Moved buildMessage() and parseAddressValue() to Email object and made public
   • Refactored the EmailUtils::sendEmail() to take an array of params or the old param list
   • Switched to SwiftMailer v.6.1.3 (requires PHP7/Grav 1.6)
   • SwiftMailer 6.x compatibility fixes
   • Updated various translations
   • Added support for Email Queue with Scheduler support
   • Code cleanup, composer update
   • Added a new clear-queue-failures CLI command to flush out failed sends
2. • Added backlink for scheduler task
   • Added support for environment option to flushqueue CLI command
   • Fixed mailtrap hostname in README.md
   • Disable autocomplete on SMTP user and password fields

v2.7.2

01/25/2019

1. • Added default for to address
   • Updated EN language #99
   • Updated UK language #98
   • Updated RU language #100
   • Updated to SwiftMailer v5.4.12
2. • Fixed mailtrap hostname

v2.7.1

12/05/2017

1. • Added new onEmailSend() event hook before sending #70
2. • Added examples of setting up Email plugin with various SMTP providers
   • Updated RU language #60
   • Updated to SwiftMailer v5.4.8

v2.7.0

10/26/2017

1. • Now uses a dedicated logs/email.log file when debug: true
   • Improved the README.txt file with examples, and troubleshooting
   • Changed default engine to sendmail as mail is deprecated and not functioning [swiftmailer#866](https://github.com/swiftmailer/swiftmailer/issues/866}

v2.6.2

09/30/2017

1. • Removed extraneous files from vendor folder

v2.6.1

09/07/2017

1. • Improved the error message when missing from in the configuration
   • Silently catch malformed email exceptions

v2.6.0

05/22/2017

1. • Inherit options from plugin configuration #39
2. • Also process translation on the email subject getgrav/grav-plugin-comments#38

v2.5.3

01/03/2017

1. • Updated to SwiftMailer 5.4.5 #45

v2.5.2

12/13/2016

1. • RC released as stable

v2.5.2-rc.1

11/26/2016

1. • Added a new process_markdown option for emails in forms
2. • Improved the Utils::sendEmail() method to take the email type as an option

v2.5.1

10/19/2016

1. • CLI command will fallback to use the to from email plugin config if not provided
   • Explicit Composer based class loader to fix issues with class case

v2.5.0

09/07/2016

1. • Added a new bin/plugin email test-email CLI command
2. • Moved Email Utils class from Login to Email plugin
   • Provide a sample base email/base.html.twig template for emails
3. • Fix handling attachments with the updated file upload field

v2.4.3

08/16/2016

1. • Added Russian translation
   • Updated Swiftmailer to 5.4.3 #37

v2.4.2

08/10/2016

1. • Added Croatian translation

v2.4.1

07/14/2016

1. • Allow multiple email recipients (comma separated) #31
   • Added Danish and Spanish translations

v2.4.0

05/11/2016

1. • Now includes Swiftmailer v5.4.2 which introduces a number of bug fixes and improvements
2. • Correct starttls implementation, bundled in TLS

v2.3.0

04/20/2016

1. • Added debug option to enable logging on SwiftMailer.
   • Updated SwiftMailer from v5.1.0 to v5.4.1.
   • Added an option in the Admin settings to enable starttls
2. • Correctly name TLS in the Admin settings, the label was TTS (but the value was correctly named tls)

v2.2.0

02/05/2016

1. • Allow to send attachments in forms
   • Added French translation
2. • Throw an exception when trying to send emails without a from or to parameters setup, to intercept less meaningful errors and provide a better description on how to fix the problem
   • Changed SMTP password in admin to use a password field instead of plain text

v2.1.0

12/18/2015

1. • Added missing content_type to email.yaml
   • Added default values for CC and BCC
2. • Improved documentation of new email params in README.md
   • Moved config setting of mailer.default to mailer.engine

v2.0.0

12/11/2015

1. • Added support for from/sender name (Thomas Keitel)
   • Added support for message content type (Thomas Keitel)
   • Added support for reply addresses (Thomas Keitel)
   • Added support for CC/BCC (Thomas Keitel)
   • Added support for multiple body parts (Thomas Keitel)
2. • Fix email engine selection (z38)

v1.0.0

11/20/2015

1. • Fix for issue with no body parameter specified

v0.2.1

09/11/2015

1. • Fix onFormProcessed event

v0.2.0

08/11/2015

1. • Disable enable in admin

v0.1.0

08/04/2015

1. • ChangeLog started...