Faker: Generating real email addresses

[alexjmoore]

Hi,

I am the owner of 'moore.io' and I have noticed an increased number of 'test' emails hitting my users. It has been hard to track down the source of this as it comes from many platforms, but finally one of them used a real email address as a return address and informed me they were using your 'faker' gem.

Looking through your code I can see that you have a range of 'names' and a range of domain suffix and so it is perfectly possible to generate users with a moore.io domain - and I'm sure many others!

My suggestion would be to use https://www.mailinator.com/ or similar services to generate your fake email addresses as many people are using your gem to test email sending as part of their application and in this case your output is not fake!

Thoughts?

Many thanks,
Alex

[b264]

This is definitely a usage problem and not a gem problem; is there any way you can think of to accomplish this without defeating the purpose of this library? You could always send a PR to remove Moore from the lists and add another word instead. Just an idea..

[alexjmoore]

What about putting a '.local' or some other suffix that is known not to be real?

[b264]

I sent a PR to change Moore in the locale files to Moor but this will only affect the newest versions and so the problem would only slowly disappear. Code already downloaded will continue to be the same. I'm not sure what else can be done from this end :face_with_head_bandage:

[alexjmoore]

Thanks for that, however I still think there shouldn't be use of real domain suffixes like .io etc, as this may lead (like in my case) to generating valid email addresses. What about instead using RFC 2606 suffixes, so still randomise the names to generate decent data samples, but have them all end in .test?

More info here:

https://tools.ietf.org/html/rfc2606

[b264]

I think the entire purpose of this library is to generate real-looking data for presentations and testing. If someone is sending emails to these addresses, it is a problem for sure, but it's a problem with their usage of the library and not the library. I'm not sure what can be done on this end aside from the PR I submitted above. Maybe the package maintainer or someone else can chime-in with ideas? This is like trying to fix poor driving skills by talking to the automotive manufacturer. A possible idea is to add long random numbers to the email addresses but as the above, this is only a partial "fix" and some folks may not want these numbers in their fake data.

[stympy]

Agreed. The point of Faker is to have real-looking data. It's up to users to use the gem properly.

[alexjmoore]

Actually I don't really agree with blaming the users. Your tool generates fake data for testing. Having an address with the suffix .test is the defined way of doing so in such a way that it guarantees the address not to be real. As per RFC 2606. So an address like :

john.[email protected]

Or even:

john.[email protected]

Are both good looking test data, legitimate email addresses and guaranteed to not be real addresses.

Your tool generates fake data for testing, sending emails is a legitimate test, I think your users are using your tool correctly, but that the tool should not be using real domain names.

[xurizaemon]

There are harmless use cases for testing real-world addresses also (eg MX lookups), so I'd prefer if the tool retain that functionality - but perhaps it could default to RFC2606?

docs/internet.md mentions "email" and "safe_email", but "email" being the more discoverable (the library is so easy to use, we intuit many of the generator names), users don't realise they are hitting live addresses. The same error will happen with other Faker implementations too, I ended up on this issue via docs for fzaninotto/Faker.

Defaulting to RFC2606 for email would avoid the unsolicited emails, and support users who want to retain the old behaviour calling "unsafe_email" or similar.

@alexjmoore I do wonder if you've had any nice test coupons or login URLs arrive though ...

[alexjmoore]

I agree, the library is built for testing and so should default to the RFC that specifies clearly how to address such test scenarios.

But yes, i get plenty of links in my inbox, almost daily, latest was series of account access emails for a test instance of Oracle Cloud :-)

[stympy]

Actually, the library was originally built for taking screenshots. It also happened to prove useful for generating test data.

[suterma]

I do suggest, that indeed faker would generate actual test email adresses by default.

This is an issue for our company. We want to have test email data, but at the same time make absolutely sure it never reaches a real person, as this would harm our reputation.

I am doing it like so, which is admittedly easy enough:

Faker<ContactData> contactDataFaker = new Faker<ContactData>("de_CH")
    .RuleFor(i => i.EmailAddress, f => f.Person.Email + ".test");

[b264]

@suterma What language is that? It looks like Typescript

[suterma]

This is a line of C#. I forgot to copy the end semicolon in this example, corrected now.

[b264]

This is the Ruby library -- try https://github.com/slashdotdash/faker-cs