Add https://mailsnag.com to the list. You can share email samples with others for the review and it also allows receiving emails for your prod env - send emails to your app and process them in it.
The idea is that, in a a test environment, we should not actually deliver the mails to the recipient, instead making them available on a web page (or through an API).
An API driven approach like Msgdrop is more flexible, as many apps can’t configure a fake SMTP server, especially if you use tools like Mailgun or SendGrid.
It's a web application too, not just a SMTP server. The MailHog web app is a little rough around the edges (it's an early AngularJS app) and had some bugs involving HTML mail content, so I can see the need for an updated version.
I do the same with mailcatcher but by self-host I mean I would throw it in the projects docker compose file for local development and spin it up specifically for that project and take it down when not needed.
since folks are sharing tools they use to test, I have one to validate if your email sender can send internationalized emails
pünicode.com. Any local part will create a temp cache that you can check to see if your email system can deliver to international local and/or domain parts. EG, send an email to josé@pünicode.com and see it show up at pünicode.com/emails/josé.
Wow...I didn't realize there were so many of these. People have mentioned almost a dozen in the comments so far.
I too have one, but it is very barebones. No GUI, no API. I suspect it would fail in many cases that the others handle, but it is fine for my test environment. That environment is basically a bunch of services from work that in production run on separate servers all shoved into one test VM with a firewall that blocks most outgoing connections to keep things from escaping.
The firewall reroutes any attempted outgoing port 25 connections to localhost port 2000, which my fake SMTP server listens on. When something connections it creates a timestamped file, sends them a "220 hello" message, and then loops reading what they send. Everything they send is copied to the file.
If they send a "quit" command it sends back "221 bye" and disconnects and closed the output file.
If they send a "data" command it sends back "354 send the message" and then loops until they send a "." line. When they send that it sends back "250 OK".
If they send anything else it just says "250 OK".
That ridiculously small subset of SMTP turns out to be fine in my environment.
Here it is in case anyone might actually find it useful [1]. Building and running is simple. It's a single Java file, SmtpSink.java. Put that somewhere, "mkdir msgs" there, "javac SmtpSink.java", and then "java SmtpSink". The data for each connection will be in the msgs directory.
If "my users" might receive test emails, that means I'm using real user email addresses in my test data, therfore my test SMTP server should not be a random system on the internet but something I fully control.
So, it's called fakemail but there is a real SMTP server in there. Attachments should work fine. Getting the web app to create SMTP accounts was quite tricky, I'm sure there are better ways but I ended up implementing the unix crypt() algorithm in C#.
Server is holding up fine so far (there was a rate-limiting bug which brought the site down yesterday). Logs show 37K unique IPs have accessed it since yesterday, and it seems to be using about 1% of the CPU (it's on a free VM in the Oracle Cloud).
There is a whole API sitting behind the web page, including proper authentication, but the frontend is very much a MVP.
Very few actual emails have been sent to it, so I'd love it if people could actually send stuff. There are a bunch of websites that can be used to send test mails, e.g.
Comes with a small API so your integration tests can actually check the contents of emails that were expected to be sent out. Did a Show HN a while ago with more details - https://news.ycombinator.com/item?id=40590670
Wow, this and all the various other options mentioned look very useful. Like others, I have hacked together configurations to do this in the past and would have loved to have these instead.
I had no idea on the availability of all the various options, which leads to the question: Where would one find examples of similar network test servers for other protocols/functions?
For example:
- A SAML IdP - Define accounts and complete a login, allow debug of request/response.
- A DNS Server - Define local domains and records, control whether Internet domains are resolvable or just local ‘corporate’ records.
- Syslog Server - Catch logs and make them temporarily available. (usually syslogd works for this, but maybe test harnesses have advantages).
The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting").
Unless the server believes you as an individual user were sending too many it should not have been a 429
If the server was unable to handle the volume of requests more generally it should have been a 503 which also supports Retry-After
IME, it is relatively common to get this response code incorrectly, i.e., not triggered by rate. IME, it can be triggered by sending one and only one HTTP request to a site one has never visited before. For example, a request sent to a certain IP address with a certain set of HTTP headers and header values using a certain HTTP method and HTTP version.
Despite what "Too many requests" suggests, people writing/configuring software are (accidentally) sending this error in response to requests based on quality not quantity.
In each case where I have received it, I was able to make the error go away by changing something about the request.
I don't want to burst bubbles, but postfix with few lines of config can redirect all email to DEVs.
You really want, whenever possible, to test everything using real tools. Doubly so, using tools you'll use it PROD. However, at least postfix is de-facto standard.
apt-get install postfix, postfix-pcre bsd-mailx, config and done.
Here's an example redirecting ALL outgoing emails, UNLESS they are to your OK domains. Redirects are sent to an alias in /etc/aliases, which you can point to anything.
(Easier for DEVs to modify when required)...
/etc/postfix/header_checks (adds a header with original TO)
/^(.*)@((?:(?![^\.]+.corp-domain1.com|anotherdomain.ca|localhost).)*)$/ PREPEND DEV-ENV-REDIRECT: ${1}@${2}
This MUST be the same as the above regex, so that the TO preservation + redirect are both done in tandem..
Without the need to worry about overall redirect stuff.
NOTE that if you don't have a unique email for your company's DEVs to use, this won't work, HOWEVER... you can redirect with more refined controls above.
That is, instead of saying "if it's not to a company domain, then redirect this DEV TEST email!", you can "If not to this specific email address, then redirect to this specific email address".
The reason I have this setup to redirect of not corp domain, is that the env I have this deployed in is byte per byte 100% identical to PROD deployment, with only very, very, very, minor tweaks. About 20 bytes or so.
That way, all tests done in DEV are 100% identical to configs in PROD. You eliminate PROD deploy bugs more aptly this way. And so if local MTAs are postfix in PROD, then you can keep all of your PROD postfix configs, with these minor changes to lock down DEV. And, you can keep the all the config files, all the config, and just have empty header_checks, recipient_canonical_map files.
But this means that alert emails that might get send from PROD have genericized domains, so in such envs it's easier to NOT redirect corp dest emails carte blanche, and then send everything else to a redirect dest.
That way monitoring / emerg emails get through unvarnished.
Most people these days are using a service provider for SMTP in production, so it isn't really possible to keep your prod and test configs in sync.
I do agree about using testing everything real tools, which is why this (fakemail) uses OpenSMTPD as the mail server.
All the work is in configuring it (similar complexity to your postfix configuration by the looks of it), interfacing to it, and deploying it (currently using ansible but will probably dockerize it).
The fact that no emails can get through to a real recipient is a feature.
It's always fascinating to me when people say "not to burst your bubble but it's really simple to use this other tool which can already do the task", and then write an essay about all the workarounds they had to apply to make the other tool work
The thing is, it's not "another tool", but instead "a tool deployed in at least hundreds of millions of *nix servers, which is rigidly compliant with SMTP RFCs, etc, etc".
If you want to debug issues with sending mail from code, then ensuring you have something that will scream if you "do it wrong" is a big bonus. And having something tested for 20+ years with rigid adherence to RFCs, deployed more widely than any other *nix MTA, is probably a good thing too.
In terms of "essay", I know it looks big on your phone screen (I presume), but a few paragraphs of background info is hardly that.
The “OG” I would consider Mailcatcher [2] from my Rails days
[1] https://github.com/axllent/mailpit
[2] https://mailcatcher.me/