Show HN: A fake SMTP server for software integration testing(fakemail.stream) This is a side project of mine. Use this as your SMTP server in a test environment to guarantee that your users don't receive test emails. Looking for feedback, especially on the security side. |
The “OG” I would consider Mailcatcher [2] from my Rails days
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.
[1] https://mailtrap.io.
> Mailpit was originally inspired by MailHog which is no longer maintained and hasn't seen active development or security updates for a few years now.
Security updates sure, but what really needs to update on an STMP (+ TLS?) solution?
- https://github.com/maildev/maildev
- https://github.com/Nilhcem/FakeSMTP
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é.
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.
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.
https://www.gmass.co/smtp-test
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
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).
- SNMP - Trap destination to capture/show alerts
Of course nobody has ever observed my rule.
Doesn't make it a bad rule...
I will probably update it to delete accounts that have been inactive for a year or something.
anyway - i got a great 429 back with a suggested try-after -time. it made me smile in appreciation!
well done!
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
Either something is wrong with my rate-limiting code or there are many people behind a single IP address.
Anyway the limits are increased now.
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.
Call it a very dynamic rate limit that autoscales all the way down to zero.
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}
/etc/postfix/recipient_canonical_map
/^(.*)@((?:(?![^\.]+.corp-domain1.com|anotherdomain.ca|localhost).)*)$/ externalredirect@localhost
# added
recipient_canonical_classes = envelope_recipient
recipient_canonical_maps = pcre:/etc/postfix/recipient_canonical_map
local_header_rewrite_clients = permit_mynetworks
#
header_checks = pcre:/etc/postfix/header_checks
#
externalredirect: dev
# dev's email.. (default unless set)
dev: /dev/null
Using a second redirect in aliases, allows you do something such as:
/etc/aliases:
#
externalredirect: dev, another_email_address_for_logs
# dev's email.. (default unless set)
dev: /dev/null
dev: /dev/null
dev: dev@corp.com
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.
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.
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.
Although in mailhog's case it looks like STARTTLS was never implemented. Hence the forks.