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.
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.
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.
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)
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...
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
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.
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 :)
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?
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)
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.
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
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.
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.
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.
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.
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.
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.
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).
This is a really bad idea. Keep PII far away from your test environments.