What is Reddit's opinion of MailHog?

From 3.5 billion Reddit comments

I personally use MailHog: https://github.com/mailhog/MailHog

It is now included in the Homestead build by default. But you can install it on any system.

Does all the similar functions as MailTrap - except it is completely local - so there are no API calls and it is lightening fast.

You can also integrate the emails into your tests - i.e. confirm an email was actually sent, confirm the contents of the email etc.

I just did my first Docker project few days ago by pranking my coworker with MailHog. I had to build it by myself for arm support.

I think most should work just fine by changing distro to one of these or these in your Dockerfile.

In terms of 'do I need SMTP to test locally' - no. You can either use the console backend or you can use something like Mailhog to capture the emails. Console Backend is easier (and I'd guess probably at the right level for you right now), but Mailhog looks more like a 'proper' mail client.

Become familiar with the testing tools for the language and framework that are in use.

For a web front end, this would likely be python and selenium.

For a java back end, this would be JUnit and probably Spring.

Additionally, think about the harness that the test runs. Not just "I wrote a test, it passes" as a checkmark but "how would I write a way to test 1000 different variations? How would I store those variations so that the test can run?" This gets much more into the engineer part of QA engineer that often gets missed.

If it needs to send email, how do you test that? You spin up a mailhog ( https://github.com/mailhog/MailHog ) with the test and verify that its sending the mail correctly. How does the application get the test configuration to send to mailhog instead of the corporate mail server? That's an interesting question. What if the mail server is down? Well, you can have mailhog do that too with its chaos monkey to make sending mail slow, or fail, or something that the happy path developer wrote and didn't consider failure cases.

Oh yea, chaos monkey... that's a neat thing. The original chaos monkey of Netflix was written by a QA engineer (the title was more likely SDET) https://netflix.github.io/chaosmonkey/

A very common way to execute some commands after the image has been built, before the "actual command" in the container runs is to have an entrypoint script, which does everything which needs to be done before finally running your app command.

You might want to be wary when your container ends up running multiple services. Usually you want to have them run in separate containers - just as you have a container for your development database and one for your app.

In the case of Postfix - I'm not sure you actually want to run it. Deliverability and similar email topics are an icky matter to get right, and there are services which can take a lot of pain away from you. MailGun is a great service to help your apps send emails, without having to run your own Postfix setup. If you want to see what emails are being sent during development, take a look at MailHog. Hope that helps!

I recommend using Mailhog for development anyway. It has a nice GUI and you don't have to worry that you'll send emails to an email address that doesn't belong to you. It shows both the HTML version and the plain text version. It also has a "source code" tab which lets you debug the email in more detail. Alternatives: MailCatcher

Mailhog is a great sandbox for testing out emails. You can view emails in both HTML and text. I use it for development/test as I know I emails won't accidently l am out. Only production is configured to use real SMTP provider.

https://github.com/mailhog/MailHog

The short answer is "probably, yes".

Technically for running tests (when TESTING is True) no emails will get sent out but in practice if you're using Celery (a very good idea) they don't get suppressed.

The issue there is Celery starts up in its own world where TESTING is False, then you kick off your test suite and configure pytest to use TESTING=True but since the email itself is being sent through Celery it doesn't get suppressed since FLASK_MAIL doesn't think TESTING=True is set at the point of sending the email.

Normally I just set up a throw away account to send email to in dev / testing and in production I use a real SMTP server. All values are controlled by an environment variable so it's easy to switch.

If you're not comfortable using something like mailtrap.io (mentioned in another comment) there's also https://github.com/mailhog/MailHog. I haven't used it first hand but it's a self hosted "fake" mail server that has a web UI so you can see your preview your emails. I'm probably going to try it in my next project.

Or better yet, don't send any emails to anywhere when developing, but catch them in a local mail server e.g. https://github.com/mailhog/MailHog

Then you can actually check what you are sending and if it's formatted correctly etcpp. and on top you don't accidentally send emails to real addresses.

Congrats on launching a product to the masses!

​

I use Mailhog a lot for this sort of thing (https://github.com/mailhog/MailHog) so switching to a paid-for service is going to be a big ask.

I can see benefits in QA testing or a CI/CD pipeline - esp. with the seamless spamassassin scoring and the like - but not so much for day to day code/run/test.

What else would HELO provide which would persuade me to make the switch, especially if I do development on a number of machines?

I've been experimenting with Mailhog for this and it works really well. It's open source so you can self-host it. I've used it to catch emails during testing and easily make any assertions through its API.

The main downside is that you have to run and maintain the service which is an additional moving part, but the service is easy to run so it shouldn't be a big issue.

Not directly related to mailing, but for testing purposes when sending email, running mailhog locally is great - if fakes being a mail server and allows you to visualise the mails you sent in a web-ui (and optionally pass them on). This prevents hitting limits of something like gmail for testing purposes and allows you to use something like send grid or another volume emailing service in the real production environment.

You have maybe added wrong entries to a db or backup server somewhere, no big deal. Just tell them and it will be fine.

Oh, and use something like Mailhog next time.

I'm not sure what problem you're actually trying to solve with this, but if it involves development or testing, you may have luck with one of MailHog/MailDev/mailcatcher. They're all "fake" SMTP servers that accept anything and make it accessible over a web interface or REST APIs. They can't relay to the internet at large unless you give them a valid relaying SMTP server.

Probably not the best option for a honeypot or process automation though.

http://www.icegreen.com/greenmail/ is an option, send mail via smtp and verify with pop or imap, have been using it for a year with robot framework. https://github.com/mailhog/MailHog/ can be an option too despite doesn't support imap or pop for retrieval, only non-standard api

I was searching for small desktop application, so these two with web UI is not really interesting for me.

https://github.com/mailhog/MailHog/issues/13

E.g. MailHog can't even save received emails as files and requires Mongo (!) for that.

> https://github.com/mailhog/MailHog

It really isn't different. I noticed MailHog will allow you to eventually send the mail for real, which mine does not. When I first wrote MailSlurper in Java back in 2011 I didn't find a lot of programs that did this. So I wrote something. Now I've seen quite a few of these. Either way it is a fun tool to write and I have found Go to be the perfect language to write it in.