GMail for instance you can have an email like myname@gmail.com and when you sign up on a site you can do myname+nameofwebsite@gmail.com
Emails they send you will still go to myname@gmail.com and you can use the +nameofwebsite part to see who it was who maybe sold your email or had a breach. Can also use it for rules and labelling things.
SOME terrible devs out there don't allow + in email addresses even though it is wholly valid to have that character. Lots of devs screw up email name validation. Don't be like those devs if you ever have to validate emails.
GMail also allows for any number of dots in your name. So you can also use my.name@gmail.com or m.y.n.a.m.e@gmail.com if you want. I do this sometimes to re-sign up for trials if the service doesn't allow for the + trick mentioned above.
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Sadly, spammers and site-attackers know this trick.
Spammers, after they've harvested such an address, know that if they see "+", they can peel off the "extra" to spam you to your main mailbox
Attckers, if you've used a predictable "+", can predict what your other addresses might be on other sites ...so you still want to use unique passwords per site
Heh... And has been valid for over 20 years — at least that's when Sendmail added it. You'd think over two decades would be enough time for people to get the drift. :p
GMail also allows for any number of dots in your name.
Sadly, support for that in gSuite seems to be lacking. Probably because they know a lot of companies like to assign .@. So, if you have a legacy Apps account for your personal domain, you can't use that trick to work past the fifty free aliases limit. :(
Yes, not allowing for + in emails is terrible practice. I wish I bookmarked it but I read a great article a few years ago all about email validation and how futile it pretty much is - the conclusion was to just check for the presence of an '@' character. Email validation is best done by sending an email to the address and seeing if the user opens it/goes to some link within it.
Everything before the '@' is entirely ruled by the mailserver, so any validation rules you apply to this are effectively an assumption on the rules your user's mailserver use. I guess you could validate the post-'@' characters but with how many new TLDs are coming out this seems like more hassle than it's worth. Trust your users to know their emails (but make sure you're still encoding the input so as to avoid nasty SQL injection etc!)
Hopefully doing more than just encoding/escaping -- never place user data directly into a SQL statement! Always use placeholders like ? or whatever your flavor of DB allows. And if it doesn't allow for that, really think hard about why you're using that db (or db sdk)!
One, but I use the built-in aliasing.
GMail for instance you can have an email like myname@gmail.com and when you sign up on a site you can do myname+nameofwebsite@gmail.com
Emails they send you will still go to myname@gmail.com and you can use the +nameofwebsite part to see who it was who maybe sold your email or had a breach. Can also use it for rules and labelling things.
SOME terrible devs out there don't allow + in email addresses even though it is wholly valid to have that character. Lots of devs screw up email name validation. Don't be like those devs if you ever have to validate emails.
GMail also allows for any number of dots in your name. So you can also use my.name@gmail.com or m.y.n.a.m.e@gmail.com if you want. I do this sometimes to re-sign up for trials if the service doesn't allow for the + trick mentioned above.
I always forget about these tricks. Thanks for the reminder!
Sadly, spammers and site-attackers know this trick.
Heh... And has been valid for over 20 years — at least that's when Sendmail added it. You'd think over two decades would be enough time for people to get the drift. :p
Sadly, support for that in gSuite seems to be lacking. Probably because they know a lot of companies like to assign .@. So, if you have a legacy Apps account for your personal domain, you can't use that trick to work past the fifty free aliases limit. :(
Yes, not allowing for + in emails is terrible practice. I wish I bookmarked it but I read a great article a few years ago all about email validation and how futile it pretty much is - the conclusion was to just check for the presence of an '@' character. Email validation is best done by sending an email to the address and seeing if the user opens it/goes to some link within it.
Everything before the '@' is entirely ruled by the mailserver, so any validation rules you apply to this are effectively an assumption on the rules your user's mailserver use. I guess you could validate the post-'@' characters but with how many new TLDs are coming out this seems like more hassle than it's worth. Trust your users to know their emails (but make sure you're still encoding the input so as to avoid nasty SQL injection etc!)
Hopefully doing more than just encoding/escaping -- never place user data directly into a SQL statement! Always use placeholders like ? or whatever your flavor of DB allows. And if it doesn't allow for that, really think hard about why you're using that db (or db sdk)!
Fair, I just wanted to throw in something about security after making the questionably phrased statement of 'trust user input' :D
You can have unlimited temp email addresses with disposable email services.