Hacker News new | comments | show | ask | jobs | submit login
Show HN: Fake SMTP server as a service (develmail.com)
149 points by pogo77 on Apr 3, 2017 | hide | past | web | favorite | 87 comments

"No fake recipient email addresses anymore, use real ones!"

This is a really bad idea. Keep PII far away from your test environments.

The real issue there is that you're using PII in a test environment, not what address you send the test email to or what service it uses. Even if you were using a self-hosted mailtrap-like app you should be paranoid about PII ending up there (when was the last time someone did a security audit of that part of your infrastructure?).

There is value in being able to send test emails to a real email address, if for no other reason than you'd like to be able to test that the email address rewriter does turn off properly when you go from dev to QA.

I completely agree - but I use mailtrap.io quite a lot. It's wonderful to be able to make up any email address and have mail sent to it from your test system, without having to run your own mail infrastructure.

Plus, all it takes is one bad setting to accidentally spam all of those people.

Exactly. Wouldn't this be a good way to harvest a ton of valid email addresses?

This was my first thought. I definitely wouldn't risk my client's privacy going through a third party like this.

I usually seed dev and test databases with fake data. Emails are usually a sequence like userN@example.com Sending mail to that is usually not a problem, unless the content of the mail is somewhat sensitive. Again, fake data helps. When I work with Ruby I use the faker gem.

If you have to import production data then, yes, that would be annoying. Anonimizing data sometimes is not easy.

You are right, we agree that it's better to not use real data and probably shoudn't have used it as one of the "features", but sometimes it's hard to anonymize data you already have or you just need to test some one-time script and check if all the emails are going to be send correctly etc. Anyways, we will probably change that text, thanks!

Agreed. Don't use real PII for test environments. If you absolutely need to, find a way to create several hundred real functioning email addresses which are dedicated to testing purposes at different domains/services, as widely spread out as you can, to verify that your outgoing email is actually being delivered from a test environment.

You need to be able to verify, by looking at the receive headers on the individual email accounts, from a widely disparate set of receiving SMTP daemons/services that your emails are passing SPF, DKIM, DMARC checks, your IP block is not in some peoples' RBLs, etc.

This is why I love Google's feature of letting you generate addresses with a +. It's so very useful

Sub-addressing of the format username+foo@host pre-dates Gmail. I think what is unique to them is being able to include periods anywhere within the username, e.g. us.ern.ame@host, user..nam.e@host, username@host are all equivalent.


which is useful for testing delivery to gmail, but ideally you want to have a really mixed bag of receiving smtp daemons with different spam/abuse filtering profiles (all of which are pretty much opaque these days for anti spam reasons) and different services to test reliable delivery.

I'm co-creator of mailosaur.com

We added both the SMTP option and wildcard email address suffix for this reason - Some people want to use SMTP to catch all, others prefer specific email addresses (e.g. One per test run)

On my laptop, where I do all of my development work, I just configured Postfix to send everything to plain files:


I like this a lot better than sending stuff out across the network.

https://github.com/mailhog/MailHog looks like a really nice alternative, where you can also test HTML mail, etc.

Personally, my local SMTP actually sends email, because I DO want legitimate email (mutt, cron) though, so I'd be scared to mix up two local smtp instances.

MailHog is pretty great. In response to your concern, by default it runs on a non-standard port, so you need to configure your apps to point at it (port 1025 by default). Even then, you can configure it to act as a MITM, where the webmail interface lets you "release" messages you actually want to send out: https://github.com/mailhog/MailHog/blob/master/docs/CONFIG.m...

Mailcatcher is an even simpler solution (assuming you can install rubygems): https://mailcatcher.me/

Mailcatcher is available as a Docker container, so you don't even necessarily have to set up Rubygems yourself: https://hub.docker.com/r/schickling/mailcatcher/

I recently ported a small combined SMTP/POP3-server (from Ruby to Crystal) so I can read the mail from my projects in Thunderbird or the OS X Mail app. Yes, this is another shameless plug, but I hope it's useful: https://github.com/tijn/devmail

You can just use MailHog for free, it works pretty good. https://github.com/mailhog/MailHog

I'm a fan of MailHog. It's simple for the whole team to setup and the optional chaos monkey button is a great way to make sure your email system can tolerate periodic failures properly.

It works locally and is really simple to setup for shared staging/prerelease environments, handles high volumes really well and the websocket auto-update system is great.

Personally, I'm a fan of using Mailhog for local and Mailtrap.io for shared environments because in my experience, non-technical testers have a better experience with Mailtrap and it's simple tie ins to review the look of emails on different platforms/clients.

Basically, Mailhog for local sending, does it send, can it handle failure, etc and Mailtrap.io for "does it look right?".

MailCatcher (Ruby, https://mailcatcher.me/) is a good and open solution for this, MailHog (Go) is open as well, even simpler to set up (no worries about Ruby versions) and has never caused me any trouble.

I don't like the idea of external SMTP for this when http://danfarrelly.nyc/MailDev/ can make everything works locally - and it's very easy to add in our Docker based projects.

SMTP4dev is a good option for Windows.

Personally I use Papercut and so far I'm pretty happy.

If you don't need the complexity of a full-blown visualisation UI, you can just (assuming you have Python on the machine) run

     python -m smtpd -n -c DebuggingServer localhost:1025
it will dump all mail to stdout.

(change port as you see fit, below 1024 requires root/sudoing)

Yeah, there are a couple very good opensource options like this on github.

Why not one-liners? Available on every Linux and Mac:

        python -m smtpd -n -c DebuggingServer localhost:1025
Oh and serve a directory as a website with this other one-liner:

        python -m SimpleHTTPServer <port>

you sir, just shut this whole thread down, methinks.

Thanks for all the comments so far, we really didn't expect so many of them, even though most of them are suggesting alternatives (just kidding, we appreciate them as well :)

We are especially thankful for suggestions about what to change, improve or add, we will try to work on them and also probably change page design/theme to make it simpler and cleaner.

We know about most of the alternatives lot of you suggested (mailcatcher, maildev, etc...) and we used them a lot, but we created this so you can have it "installed" everywhere or maybe share account so other people from company could check emails, texts etc easily.

And we wanted to publish this MVP as soon as possible to check if there is at least some interest in such thing (and even our server couldn't handle it sometimes :)

This seems similar to https://mailtrap.io

I've used mailtrap with great success on a Django application that I used to work on. It really is great to just change the SMTP config for the mail sending service without having to worry about adding checks for "if in testing send all emails to a particular address".

Would this service have any benefits over what mailtrap offers?

Also https://mailosaur.com

Disclaimer co-founder

And similar to http://mailinator.com

We created this for our usage, but decided it could be useful for other people too :)

It's still under development, so there are not many features yet, but we would like to hear your opinions and what could we improve or add.


One very useful feature would be to add up to date filtering systems in report only mode (eg SpamAssassin), SPF / DKIM / DMARC checks, etc. Without having your own up to date inbound MTA, it's very difficult to test your own mails for things that might be triggering spam filters.

Do those services really have a feature like that? That seems like they wouldn't people to easily figure out if an email the have sent makes it through filters. Maybe I'm wrong, I have never had to worry about email in a business environment.

SpamAssassin, DKIM, SPF, DMARC are all things that you can check locally, so yeah, you can def. determine if an email is going to get through at least basic filters. Note that SpamAssassin is more a framework, and that a lot of this stuff is going to be bayesian/machine learning kinda stuff, so while you may get through basic level filters, people pay a lot for the higher end stuff, and you can't test those kinds of things. (barracuda email filtering and that kind of thing)

So this is useful for:

1. developing software that sends e-mails, but not having to set up a test environment/pray you don't break production, and

2. testing out new software that insists on sending e-mail when you're just one person in a small/localhost-only environment.

I love it.

One thing I'm sad to see is that there seems to be no TLS/STARTTLS support on the side of develmail. Given that TLS can be a bit finicky to set up and that plaintext SMTP is ideally deprecated as fast as possible, it may be worth a thought to just Let's Encrypt it.

Thanks! We understand that encryption is a must, we plan to add this feature as soon as possible.

Some years ago I wrote a tool called mailcat, which is a fake SMTP server that prints the incoming emails to stdout. I use it to this day when I need it in development. It's available at https://github.com/soveran/mailcat

At my previous company we used mailcatcher[1]. Worked fine, but with lots of e-mails, the service might crash.

[1] https://mailcatcher.me/

You already have an SMTP Server for testing on your OS:

sudo python -m smtpd -n -c DebuggingServer localhost:25

I think some are being a smidgen too hard and dismissive about this.

That you can do this a bunch of other ways isn't really the point at all. Doesn't even matter if it's easy to do.

The point is to make it very easy to do and to provide some additional features in the process.

I am all for "another way to do it" and especially if the goals are making it easier while adding functionality and it doesn't cost me anything.

That's a "win win win" even if you never use it.

I need to make a Username/Password/Domain Checker As A Service. Just send me your bank account credentials and I will verify that they work for you.

pogo77, congrats on launching. somewhat random comment: your site is completely broken when JS is disabled. This is usually not a problem for general Internet population, but somewhat important for your target audience who's got fed up with laggy JS animations and battery drain and installed NoJS with aggressive settings.

It's even broken with enabled JavaScript, but disabled Cookies. Sadly lots of sites are nowadays.

    As a startup we currently offer one simple subscription program completely for FREE! 
    Meanwhile, we are working hard on our paid plans with plenty of new features, everyone who signs up for our current free plan will be automatically migrated to our highest paid plan for free forever!
    **In case of excessive or unreasonable use of service, additional limits may be applied
As a developer, I appreciate being able to lightly use a service for free. I also appreciate that people have to be paid. It's ok to charge for something that gives value to other people. I think that promising early users to be free forever is short sighted. Maybe they have to offer it for free because it is relatively easy to just spin up your own SMTP sink locally.

* I would not use a free service - I want to know that my company is a customer. I want recourse/support if there a problem. That said - be sure to get insurance, for when there is a fck up.

* I want to pay to make sure that companies we use stay in business.

* If my business is using your services to make money - you should be able to ask for money easily.

* The "free forever" send the message that you are shy about asking for money.

* Start testing pricing now. (with the price "reduced" to "free" - ie use strikethrough)

* Remember a startup is only a business if it is charging for its services. Otherwise, it is just an expensive hobby.

Also, I think of all the services I've used that (usually quietly) limit their "free forever" service into a tier and scrub it from their marketing once they get rolling and don't need to over-promise in their marketing anymore.

I'm sure it converts better, but it feels more honest to remove the "forever" part.

Claiming to be free forever AND being a service that explicitly expects you to send a bunch of real email addresses to, is almost on the level of a Nigerian prince for sketchy behaviour.

I cannot believe anyone would use this service

In a Java environment, we spin up an instance of Dumbster [0] using our test harnesses, run our integration tests and tear it back down.

[0] https://github.com/athalay07/dumbster

For testing/dev at work, I wrote a little go app that listens to SMTP on port 2525, collects mail into a boltdb, and presents it in a very simple web UI (port 7070) that lets you browse users and their mail. (A simple drill-down of list of users / emails for user / message details, including all mime parts and download links for attachments. The top page has a "clear" button.)

It was an evening's work, so it's very simple, but it works and we've found it very useful. (The original idea was to very simply expose the application flows involving mail to selenium, but I've found it very useful for dev, too.)

> No fake recipient email addresses anymore, use real ones!

What if you send to the wrong server by mistake; not to develmail.com? develmai.com won't save your butt then.

Say something breaks in your configuration, and some mail-related layer resolves the address directly to an MX host and sends it there instead of the SMTP forwarding host it is supposed to be using ... know what I mean?

If you don't want packets to go to the wrong place, isolate your test box physically: e.g. 192.168.0.x "lab" network with no gateway to the Internet your intranet.

You're right, but it's just a suggestion. It's really up to you how you use the service, sometimes it might be handy to see real data :)

The point is that you can use real data with your own isolated test bed.

I'm not going to involve some random thing on the Internet in my test setup!

For one thing, I'm pretty sure I'd be violating a document that I signed about promising to safeguard my client's IT security, secrets and intellectual property.

Real data could be sensitive.

Anything of this sort that you set up will eventually be used by other people, who don't always know the full ramifications of what they are using. Somewhere down the line, someone will leak something into the test system. Maybe a user ID or password. Names of clients. Whatever.

Also, a test system has to be reliably operational. According to Murphy's Law, someone's thing you depend on on the Internet gonna disappear exactly when a lot of integration activity starts happening before a release.

Lastly, you should control every aspect of a test tool. Exactly how someone's SMTP thing handles SMTP could change in subtle ways from one day to the next.

Is this something people would actually pay for? Why not just set up a box running Postfix with a catch-all address and an outbound block on 25/TCP?

You answered your own question: that is a lot more work than using either this or one of the purpose-made packages like papercut or smtp4dev.

Thanks for keeping it for free. I use mailtrap.io and haven't ever hit their limits, but having it as a free service to the community is appreciated.

Sounds like inbox.py: https://github.com/kennethreitz/inbox.py

This is the simplest SMTP server you'll ever see. It's asynchronous. One instance should handle over one thousand emails per second.

Anyone using postfix already has smtp-sink in their arsenal. You already have a fake SMTP server.

I missed the signup button as it was white and the image HD not loaded.

I suggest adding another signup button at the bottom of the page. After I read the features I scrolled back up to look for a signup button which is when I noticed it was white as background image had loaded.

I made my own little debugging SMTP server in C# some time ago: https://github.com/vmp32k/MailBug/releases

It's not pretty but it works well enough. :)

Uh, maybe consider changing the styling/colors of that image slider at the top of your website: http://imgur.com/a/EY3sU

I've been using this for ages, works like a charm https://github.com/rnwood/smtp4dev

Locally you can run papercut https://papercut.codeplex.com/

Yes - I worked on this as well. Very similar concept to some of the other solutions here. Self-hosted (keep mail internal, fast) - Invent any email address you like (†), trap it all here. View it via the app, or query via REST. Designed to be open, this is really useful when you don't want to have to setup mailboxes, or deal with the additional header of catch-all addressing. I'm currently adding attachment support for the next release.

† This comes with the caveat that you don't use PII, because people make configuration mistakes - but if that's how you do testing, then I'd argue you have bigger problems in your organization than capturing mail. We use it with somefakeguy@ourdomain.com, someotherguy_datetime_from_automatedtest@ourdomain.com, rather than just sending stuff to _real_ addresses.

Why not?

#sudo python -m smtpd -n -c DebuggingServer localhost:25

Works pretty well for me.

Anyone seen something like this for webhooks? I want to quickly see the contents, headers and logs without building the middle-man myself.


honorary mention: https://10minutemail.com/ :)

Is this able to track bounced mails? Then it could be used to verify emails :)

Mailinator does this too of course (with API)


Please stop hijacking scrolling. Thankyou.

That together with a link to https://develhell.com/ at the bottom actually made me think it was a joke at first.

The pug made me think that to be honest.

There's a really horrible dithering effect on Chrome on Windows 10 when you scroll which gives me a headache.

Also on Ubuntu 16.04

I already have "Scroll Anchoring" enabled in Chrome's flags, wish they'd add a flag just to disable page's ability to override scrolling completely.

Unfortunately "Scroll Anchoring" will likely never make it to a production build as it has odd interactions with sites that override scrolling to jump to new page elements (adverts in particular).

CNN Edition pages are particularly broken:


Sorry, we didn't notice that. The design comes with this feature, but we will probably change it very soon.

Your first slide looks like this over here: http://i.imgur.com/2Wzbe3Y.png

Yep. White text is unreadable on dotty backround on mobile. Even zoom in doesn't help.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact