> we can create a mailbox via HTTP GET request to <a href="https://api.unverified.email/create" rel="nofollow">https://api.unverified.email/create</a><p>Shouldn't GETs be idempotent? (Sorry for not having feedback on the idea, skimming it it seems nice, though there is fierce competition as others have shown here)
What kind of anti-abuse mechanisms do you have in play?<p>As soon as the API is figured out, it'll be used for mass spam signups. I've done one of these before, and pretty much if you allow any form of being able to retrieve a code or URL or number from the body/subject, it'll be used for millions of spam signups.
Nice work. I investigated a few similar services, mailtrap, mailgun, mailosaur. I wanted to try having my end-to-end tests assert that the email which got sent out actually included the correct info. (As in, you request a password reset to test@emailtesting.tld, and then you make API calls to assert the email exists and includes the correct text)<p>It works well for peace of mind as it gave me a high degree of confidence that I'm testing almost exactly what the end-user would experience. However, it does add 5-10 seconds of delay to your tests while polling the email inbox, it can be a little expensive depending on your test frequency, I think there are even some cases where you can hurt your email deliverability stats during automated email sending.<p>In the end, I decided to keep this test manual which I run every now and then only after making big changes. Instead integration tests which mock the email service are probably enough for my use case.<p>Curious how do others test the end-to-end behaviour of their web application, when it comes to emailing?
Having more open source software is always good, so congrats on putting something out there.<p>I'm very curious why this takes the approach it appears to take: running two docker containers with opensmtpd in one of them, and then scanning the maildir for message content; compared to what the numerous existing solutions (mailcatcher, mailtrap, mailhog, maildump) all do: run an in-process SMTP server.
I use a simple local catch-all SMTP server for testing. I install it on my test machine listening on some non-SMTP port (default is 2000), and then use iptables to make all connection attempts to port 25 end up at the catch-all server.<p>Here's the iptable command: "iptables -t nat -A OUTPUT -p tcp --dport 25 -j REDIRECT --to-port 2000"<p>The catch-all server is ridiculously simple. It just responds with a "220 hello" when connected to, and then just reads input line by line, logging all input to a file. It only knows about two SMTP commands: DATA and QUIT.<p>On QUIT it sends "221 bye" and closes the connection.<p>On DATA it sends "354 send the message" and then just reads the data and logs it to the file.<p>Anything else? It just sends "250 OK".<p>Note that this is pretty useless if what you are trying to test is a mail client, because you cannot test error cases. The purpose of this SMTP catch-all is for testing the content of messages your software sends, not for testing the process of mailing itself.<p>Each connection is logged to a separate file.<p>The source is a single Java file. Here it is if anyone wants it [1]. "javac SmtpSink.java" to compile. "java SmtpSink" to run. Messages are stored in the "msgs" directory, which you should make before running it.<p>[1] <a href="https://pastebin.com/WqkS7jNH" rel="nofollow">https://pastebin.com/WqkS7jNH</a>
Shameless plug: I've made a similar service with both an API and a web interface at: <a href="https://mailspons.com/" rel="nofollow">https://mailspons.com/</a>
If, by chance,the author happens to see the comments here... you may consider choosing an alternate (high-numbered / "unprivileged") port -- say, 2525? -- and redirecting connections to that port to 25/TCP on the same host.<p>This can be easily accomplished with a single iptables / nftables / pf / etc. rule.<p>(A non-insignificant number of ISPs, CSPs, etc., block outbound connections to 25/TCP by default -- except, in some cases, those going to to their own mail servers or "smarthosts".)
See also Mailslurper [0] and Mailcatcher [1] if you'd like to self-host an email catch-all service.<p>Mailslurper appears to be abandoned and seems to be missing deterministic builds that go module support provides.<p>Mailcatcher has been around for a while, with my first discovering it being used in a legacy project's test suite back in 2014.<p>Both could use some better SEO since it's nearly impossible to find unless you know exactly the right keywords to use.<p>[0]: <a href="http://mailslurper.com/" rel="nofollow">http://mailslurper.com/</a>
[1]: <a href="https://mailcatcher.me/" rel="nofollow">https://mailcatcher.me/</a>
>The mailbox_id from the above setup should be included somewhere in the text of the email, the subject, the bcc address, the headers, or any other field (even email address of the sender or recipient will do).<p>Sorry... how does it know what mailbox id to look for?
If your testing system depends on a remote server, it's not testing just your code anymore. Tests must be as isolated from other changes as possible or else they do not tell you anything.
Mailtrap, which is listed as an alternative Ruby library, is also available as a service: <a href="https://mailtrap.io/" rel="nofollow">https://mailtrap.io/</a>