Introducing our Fake SMTP Server

We are pleased to announce the release of SMTP Bucket, a fake SMTP server for e-mail integration testing. SMTP Bucket provides a handcrafted, fully compliant, SMTP implementation, but makes no attempt to deliver the e-mails it receives to their intended recipients. Instead, we store them in our database and make them available on our website and through our REST API. We do not require registration, and we do not currently impose any usage limits. Simply use these connection details in your client application, and send SMTP Bucket your e-mails as if it were any other SMTP server:

Host: mail.smtpbucket.com
Port: 8025

We use a non-standard port because the standard SMTP port 25 is blocked on many networks.

Why did you build it?

SMTP Bucket began life as an internal scratch your own itch project. We needed to verify our applications were successfully sending e-mail via an external SMTP server in a way that doesn’t require an endless stream of throwaway e-mail addresses. We were also desperate to reduce the risk of accidentally spamming real customers with test emails, which, as well as damaging our reputation, could easily result in our domains and IP ranges being blacklisted.

How did you build it?

If you’re wondering about the technologies we used to build SMTP Bucket, the core SMTP implementation and REST API are written in Java 8 using Spring Boot and a MariaDB database. The main website is a separate Java & Spring Boot app with a UI built with Thymeleaf and Bootstrap. The website consumes the same API we’ve made public, so anything you can do on the website can be done via the API, or vice versa. This blog is powered by WordPress. Oh, and we’re hosted on Linode.

What can I do with it?

SMTP Bucket is, first and foremost, a developer’s tool. It allows our development teams to code against a working SMTP server without installing anything on their local machines, or making a real mail server available on our office network.

It also makes our QA team’s job much easier. Before we introduced SMTP Bucket, they spent half their working lives on sites like Mailinator, and we experienced frequent bouts of panic when someone realised they’d sent a test message to a real e-mail address. Of course, at some point in your application lifecycle, you will want to connect it to a real mail server, but if all you need to do is find an e-mail confirmation link, for example, SMTP Bucket can be a useful tool.

As important as human testing is, where we’ve found SMTP Bucket really comes into its own is when used to support post-deployment checks as part of an automated release process. You can deploy your application to a working environment, configure it to send e-mail via SMTP Bucket, run automated tests using tools like Selenium, and programmatically retrieve any generated e-mails via our REST API. This is especially useful when a browser based test scenerio depends on information contained in an e-mail, like a password reset token.

What’s next?

Our immediate development priorities are an HTML preview option for the website and STARTTLS support in the fake SMTP server – we’ll probably implement SMTP Authentication at the same time. That will allow applications that require those options in the ‘real world’ to use SMTP Bucket with the minimum possible amount of reconfiguration.

Of course, not everyone will be happy having their test e-mails visible to anyone who knows the addresses they were sent from or to. If there is sufficient interest, we will consider implementing private buckets as a chargeable option. The basic level of functionality we offer now will always be free.