Debugging e-mail-notifications can really be annoying. There are many different addresses flying around in the configuration. While developing and bugfixing, none of the created e-mails must be sent to the customer or other parties. In this post I will show you several alternatives to achieve this.
There are at least four different solutions covering different needs and complexities. My main focus is to ease development on a local setup. The first possibility is currently my preferred one.
Use a Mailcatcher
The basic concept of a mailcatcher is to act like a normal smtp server and speak the same protocol. The difference is that it does not distribute the received email to their intended destination, but to keep them locally for further processing. Furthermore they provide usually a web interface to view the trapped emails.
Thanks to my colleague Markus Sommer, I am using MailHog now. MailHog is a piece of software coded in Go. At least for MacOS users using homebrew it is really easy to install and use. The following command installs the software and registers it as the necessary services.
brew install mailhog
Downloads for many different other platforms are available via github. The downloads are prepared for each release. The current one it is 0.2.1.
After the the installation you have to point the mail setup in the InstallTool to your mailhog installation. The option “[MAIL][transport]” must be set to “smtp” and “[MAIL][transport_smtp_server]” must be set to “localhost:1025”, if it is running locally.
But before going into “development production”, you should test it via the InstallTool. Add your email address like shown on the screenshot and click on “Send test email”.
If everything is ok, you should see the test email in the web interface of mailhog. In order to see the email point your web browser to the address “http://localhost:8025”. The website should now look like this:
If you click on the title of the email, you can explore more details, like a source or plain text view. Another possibility is to “release” the trapped email. This means to forward / re-send the email to a real account for further testing.
If you cannot install MailHog or a similar solution to your computer, there is still a TYPO3 built-in solution, available for “ages”.
Trapping e-mails in mbox files
The first step is to set the value “mbox” in the option “[MAIL][transport]”. After that the option “[MAIL][transport_mbox_file]” must be set to an existing filename. All emails, which are sent by TYPO3 afterwards, are trapped into an file in the mbox format.
The mbox format is one of the first formats, which the email clients in the mit 1990 could read and edit. Basically it is a text file to which all received emails are written. An email is ended with two newlines. The next one starts with the “From:” line of the email.
The advantage is, that you can read the emails with any text editor. But it is not very comfortable to read emails this way, especially if they contain larger attachments. As the format is quite old, there are not many email clients supporting this format currently. On linux systems there is for example the cli mail client “mutt”.
Another option is to use the ImportExport-Tools in Thunderbird. The drawback is, that it is solely an import solution. If imported, the folder stays as is. If another email is received in the mbox file, a re-import is due and you must throw away the last import.
(While writing this, my idea is to provide a backend module parsing the mbox file and displaying the single emails. Much like mailhog, but integrated in the TYPO3 backend.)
Commercial Services
If you have teams, which work together on debugging emails, it is also possible to use external services. One of them is https://mailtrap.io/. This is some kind of a mailprovider that catches all the emails of your development instances. and view them via a web interface. Furthermore they offer a forwarding of incoming emails to dedicated mailboxes.
The most individual configuration is possible with the last solution:
Dedicated Mailserver for Development
This is the most complex setup. You (or your IT department) have to set up a dedicated mail service which is serving only for development purposes. This is quite a lot of work, as you not only want to trap the sent emails, but also want to debug their contents. If you have bigger teams, this is not a really easy task and requires a lot of work.
What do you use?
Which solutions do you use, to prevent sending emails to customer addresses while developing or enhancing a website? Do you have other solutions? If yes, I would be happy, if you leave a comment afterwards.
Credits
I found the blog post image on pixabay. It was published by Alexas_Fotos under the CC0 public domain license. It was modified by myself using pablo on buffer.
Do you have a best practice how to automate form tests which involve double opt-in?
Besides that: I’m still searching for a way to test emails in production. In most cases sending the mail is not the problem, but receiving it. Mail server configurations change, Spam protection is updated etc. All these things might lead to the problem that mails get lost. But I have no idea how to automate these kind of tests since most customers would not let you access their mail server environment.