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)
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 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).
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?
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.
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.
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.
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.
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.
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.
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.
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)
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.
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'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?".
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.
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.
* 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.
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.
90 comments
[ 4.1 ms ] story [ 141 ms ] threadIt'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.
Thanks!
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.
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:
http://edition.cnn.com/2017/04/03/europe/st-petersburg-russi...
Would this service have any benefits over what mailtrap offers?
Disclaimer co-founder
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.
This is a really bad idea. Keep PII far away from your test environments.
If you have to import production data then, yes, that would be annoying. Anonimizing data sometimes is not easy.
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.
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.
https://en.wikipedia.org/wiki/Email_address#Sub-addressing
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)
(change port as you see fit, below 1024 requires root/sudoing)
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?".
or
https://webhook.site
I'm sure it converts better, but it feels more honest to remove the "forever" part.
* 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.
I cannot believe anyone would use this service
It's not pretty but it works well enough. :)
[1] https://mailcatcher.me/
This is the simplest SMTP server you'll ever see. It's asynchronous. One instance should handle over one thousand emails per second.