Ethereal allows to generate new testing accounts via an API. Every account is a full featured IMAP/POP3 mail store with the condition that all emails expire after 7 days from the account.
Fair enough. I only ask because email testing should be able to run in an isolated test network. Perhaps dovcot+postfix in a container may be too much work for some folks.
I want to know if there are any httperf/seige like tools for email. I would love to blast my server with 100k valid & invalid emails and see how it does.
We always use MailTrap for our projects. It's a fake SMTP server with a webbased inbox. Nothing to install, you just have to configure some SMTP credentials in your applications. https://mailtrap.io/
Not trolling, but why would any developer need a service like this? Isn't that what Mocking frameworks and Interfaces (Interface driven design) are for?
Ex: I would create an interface called IMailService with the operations like Send etc, and once my application is ready, just swap the concrete implementation of the MailService class with the one that talks to the real mail service using Dependency Injection.
If it's not for developers, who would use something like this?
Sometimes you want to do a higher level integration / end to end test. Consider for example where you’re testing a docker image and need to provide an SMTP endpoint. This could be a solution.
So, I have an application that sends alerts via email and 'sms', and to save costs for some sms messages, I use the cell provider's email address w/ the user's phone number.
These alerts can go to a user and/or a user's supervisor(s).
Additionally, the content of the message is dynamic.
This service would be very easy to add as a config option and let non-technical coworkers test the application for accuracy.
Also, I will know that SMTP is actually working.
Otherwise, I need to write the code and a UI for the non-technical coworker, and a way to store it. I have other things I need to work on.
Not sure what you're alerting for so maybe it doesn't matter but I just wanted to warn you about using sms mail gateways. Most of the time the email gateways work (with varying delays) but I've seen every major provider fail or take days to deliver when I needed it the most.
How do you test your mocks to ensure they match real SMTP/IMAP/POP client behavior?
If the same developers write the clients and the mocks, then it's likely that both components implement identical misunderstandings, if there are misunderstandings.
It's what I do. However, I rarely integrate with email, and when I do it's for in-house email addresses.
That said, I was giving an example of why a mock might not be an appropriate solution, and not on the wider topic of what "enough" might be.
I can certainly think that testing the ability to send emails to, say, 5,000 different addresses, and check that they are received, might be easier with something like this system.
We use mailcatcher[0] on our sandbox server so that product and QA can test email features in a live environment. Mailcatcher was a drop in replacement with our existing codebase. No need to add in additional business logic specific for testing or have to write our own interface to expose the "sent" emails.
I'd probably set SMTP_URI in my environment or as a java property and just use that to configure my SMTP service. While an Interface and DI might be useful for unit testing, when I'm testing in integration, ci, or qa environments, I'd want to make sure that I'm using an SMTP server that can't send emails to the outside world. Postfix is pretty easy to setup for this scenario (a whitelist of users/domains to forward mail for) so I can still test mail output.
I was once trying to develop a SMTP sender lib for PHP.
After reading a lot's of RFC's, I found it's really helpful to test my code against some standard SMTP server so I can know my code is work as expected.
But a real SMTP server is not an option as they all have some kind of filters and server settings that will interfere my test, + In this case, I don't think doing TDD with a real working commercial server (i.e Gmail, Outlook etc) is a good idea. It's not only slow, but also wasting (their resources).
That's when a fake SMTP server come in handy. Because not only you can use them to Send a lot's of mail, also those emails will not generate any (I hope) real world side effect.
If you are using /usr/sbin/sendmail style delivery, for example via the built-in postfix implementation on macOS and many linux-like systems, it's fairly easy to configure postfix to rewrite absolutely everything to go to your own email address. This can be quite helpful during development, because not only do you get to see the emails as they are delivered, but you can also worry less about sending development emails out to random addresses around the world. (Look into "recipient_canonical_maps")
Ethereal.email uses Wild Duck Mail Server as the backend https://github.com/nodemailer/wildduck
In fact this was one of the reasons I created Ethereal - to get some load test against Wld Duck
You need the destination address to not run dkim spf or dmarc on the forwarded emails with rewritten destinations.
I came across this when forwarding everything to gmail. Gmail is smart enough to accept this for mail originally destined for an address you enabled as "send from". However, mail sent to e.g. retailName@domain.com will fail the checks and never be delivered.
My team uses mailcatcher, also, but (partly) for reasons I've not yet seen mentioned:
Our primary application allows us to safely import recent dumps of the production databases into select CI systems, of which some tables have user records with real email addresses for report sending, etc.
In the case that the code which sanitizes these records misfires or otherwise fails to do its job, at least we won't send random emails to actual customers. I know we've all gotten those from a vendor at one time or another and it's a corporate level face-palm that's worth the extra effort to avoid. Belts & suspenders, defense-in-depth, and all that.
I like Papercut better. It runs on your own machine and you can configure forwarding rules in case you want to test e-mail on other clients like Outlook or GMail. The interface is simple and clean.
43 comments
[ 4.3 ms ] story [ 69.2 ms ] thread- Most of us don't know about it
- You have to install postfix
http://danfarrelly.nyc/MailDev/
So far my experience has been good. I get to work on some email sending code on a wifi-less airplane.
[0] https://github.com/mailhog/MailHog
Ex: I would create an interface called IMailService with the operations like Send etc, and once my application is ready, just swap the concrete implementation of the MailService class with the one that talks to the real mail service using Dependency Injection.
If it's not for developers, who would use something like this?
These alerts can go to a user and/or a user's supervisor(s).
Additionally, the content of the message is dynamic.
This service would be very easy to add as a config option and let non-technical coworkers test the application for accuracy.
Also, I will know that SMTP is actually working.
Otherwise, I need to write the code and a UI for the non-technical coworker, and a way to store it. I have other things I need to work on.
But, as you said, it can be iffy, so that is why I want to know if the issue is with stuff I control, or them.
So, at least I know it is being sent and my logic is solid.
If the same developers write the clients and the mocks, then it's likely that both components implement identical misunderstandings, if there are misunderstandings.
That said, I was giving an example of why a mock might not be an appropriate solution, and not on the wider topic of what "enough" might be.
I can certainly think that testing the ability to send emails to, say, 5,000 different addresses, and check that they are received, might be easier with something like this system.
[0] https://mailcatcher.me/
My bad.
For staging environments I like Mailtrap.io because it's a cleaner interface for non-devs.
After reading a lot's of RFC's, I found it's really helpful to test my code against some standard SMTP server so I can know my code is work as expected.
But a real SMTP server is not an option as they all have some kind of filters and server settings that will interfere my test, + In this case, I don't think doing TDD with a real working commercial server (i.e Gmail, Outlook etc) is a good idea. It's not only slow, but also wasting (their resources).
That's when a fake SMTP server come in handy. Because not only you can use them to Send a lot's of mail, also those emails will not generate any (I hope) real world side effect.
I came across this when forwarding everything to gmail. Gmail is smart enough to accept this for mail originally destined for an address you enabled as "send from". However, mail sent to e.g. retailName@domain.com will fail the checks and never be delivered.
Our primary application allows us to safely import recent dumps of the production databases into select CI systems, of which some tables have user records with real email addresses for report sending, etc.
In the case that the code which sanitizes these records misfires or otherwise fails to do its job, at least we won't send random emails to actual customers. I know we've all gotten those from a vendor at one time or another and it's a corporate level face-palm that's worth the extra effort to avoid. Belts & suspenders, defense-in-depth, and all that.
“8. How is this sustainable Ethereal Email service is funded by the ads displayed on Nodemailer.com. So don't forget to click on these banners!”
https://github.com/ChangemakerStudios/Papercut