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)
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.