Show HN: Fake SMTP server as a service
develmail.com
develmail.com
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.
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)
http://harold.internal.org/configuring-a-dev-box-mail-server...
I like this a lot better than sending stuff out across the network.
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.
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?".
python -m smtpd -n -c DebuggingServer localhost:1025
(change port as you see fit, below 1024 requires root/sudoing)
python -m smtpd -n -c DebuggingServer localhost:1025
python -m SimpleHTTPServer <port>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 :)
Would this service have any benefits over what mailtrap offers?
Disclaimer co-founder
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.
Thanks!
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.
sudo python -m smtpd -n -c DebuggingServer localhost:25
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.
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
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 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.)
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.
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.
This is the simplest SMTP server you'll ever see. It's asynchronous. One instance should handle over one thousand emails per second.
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.
It's not pretty but it works well enough. :)
† 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.
#sudo python -m smtpd -n -c DebuggingServer localhost:25
Works pretty well for me.
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...