News for hackers. Stuff that matters.
Re:Complexities of e-mail validation logic by josephcsible on Monday May 24, 2021 @10:56AM (#27265090)
This logic is why so many Web sites today won't let you use a plus sign in email addresses, which ruins a really nice Gmail feature.
Re:Complexities of e-mail validation logic by kyrra on Monday May 24, 2021 @11:19AM (#27265370)
As people said, true spammers know to just strip off the "+" in the email address. This is actually a fun reason to set up your own domain and set up email forwarding for *@example.com to go to your main gmail or whatever account, then the "username" part of the email I just set to the domain of the account I'm signing up for. So I'll use [email protected] when signing up at Amazon (or whatever site).
Re:Complexities of e-mail validation logic by rootusrootus on Monday May 24, 2021 @11:27AM (#27265487)
> So I'll use [email protected] when signing up at Amazon

I go a little farther. I figure an attentive spammer might figure out that if I use [email protected] to sign up for Amazon, I may have exactly the scheme where *@johnsmith.net will work, so they can just add that to the spam list as a wildcard and pick a new address every time. So instead, I use [email protected], john102, john103, etc, to try and obscure my strategy and prolong the life of the domain forwarding.

Re:Complexities of e-mail validation logic by typicalbender on Monday May 24, 2021 @12:58PM (#27266781)
Hard truth is you're not worth enough for a spammer to look for that pattern, it's a numbers game and you're just making it harder on yourself.

Also unless you're keeping a lookup table you're losing a great benefit of the wildcard. You can, and I have caught a few places, tell when a company sells your email. If I get an email from company XYZ to my email [email protected] I know exactly who sold my email and to whom.

Re:Complexities of e-mail validation logic by rootusrootus on Monday May 24, 2021 @01:34PM (#27267282)
I agree that I'm probably not worth the effort, but if this kind of domain wildcard strategy were to become more popular it is entirely feasible for a rudimentary machine learning algorithm to detect its use.

> unless you're keeping a lookup table you're losing a great benefit of the wildcard

That's true, I don't keep a lookup table per se, though I do have a deleted items folder that I could look back in. I'm not sure what I would do, though, if I knew what particular company sold my email address? Send them a nastygram they will just ignore? I just block the address and move on.

Re:Complexities of e-mail validation logic by labawi on Tuesday May 25, 2021 @04:09PM (#27281940)
I think a typical spammer doesn't care much about such users, but if given given a choice they would rather avoid such users.

AFAIU, most buld spam is targeted on gullible or vulnerable people. The spam is often terrible on purpose.

Sophisticated or targeted attacks are a different category and they may be a good reason to prefer something non-guessable.

Re:Complexities of e-mail validation logic by willcipriano on Monday May 24, 2021 @11:33AM (#27265548)
I just have a entire domain for the purposes of spam. Anything sent to there ends up in my bulk folder. I use [email protected] so I can tell who sells my email or gets hacked. Never noticed someone trying to send a email to any addresses I haven't previously used.
Re:Complexities of e-mail validation logic by wastholm on Monday May 24, 2021 @11:59AM (#27265928)
> Never noticed someone trying to send a email to any addresses I haven't previously used.

At least a few years ago, I noticed a lot of spam to <random first name>@<my domain> -- i.e., completely made-up addresses that I had never used. Since messages sent to those addresses were guaranteed to be spam, I started treating them as free training data for the spam filter.

I don't know if this still happens, though, because I haven't looked.

Re:Complexities of e-mail validation logic by Grollicus on Monday May 24, 2021 @12:19PM (#27266199)
This is currently happening to my email domain. Gets rejected as it doesn't have a valid hash (recipient name), but the logfiles are full of <3 letters>@mydomain.com and <english_word>@mydomain.com rejections.
Re:Complexities of e-mail validation logic by klyrs on Monday May 24, 2021 @12:37PM (#27266457)
Yeah, this is an age-old issue -- in the early 00s, my mom got a domain and used the email <first_initial>@<domain>.com. She gave up battling the deluge of spam after about a year. We looked through the logs, and saw that her next choice of handle was also getting tons of spam, too, because it was also short.
Re:Complexities of e-mail validation logic by batch12 on Monday May 24, 2021 @02:54PM (#27268300)
I do the same thing. I use [email protected]. The addresses are temporary if I want them to be and I can automatically lock the senders to a list that is either automatically learned after x days or manually curated. I've seen some 'marketing' mail get filtered but no hacks yet.
Re:Complexities of e-mail validation logic by cgriswald on Monday May 24, 2021 @04:07PM (#27269077)
I’ve got [email protected] email for my domain and I’ve never created such an account, much less given it out. Without some uniqueness in the username, I’m not sure you can tell a company sold or lost your data.
Re:Complexities of e-mail validation logic by bcrosby95 on Monday May 24, 2021 @12:45PM (#27266579)
Spamming is a numbers game. I kinda doubt enough people are using this scheme to make figuring this out worthwhile for a spammer.
Re:Complexities of e-mail validation logic by nerdponx on Monday May 24, 2021 @12:20PM (#27266231)
I've wondered about this with big companies like Facebook, Google, Amazon, etc. as well as behind-the-scenes spyware/ad firms who are all probably very interested in linking my identity across user accounts, email addresses, device fingerprints, etc. I've hoped that there aren't enough people doing it (yet) for these orgs to find it worth the effort.
Re:Complexities of e-mail validation logic by macNchz on Monday May 24, 2021 @12:59PM (#27266804)
There very much are companies doing this and selling it as a service...here's an API that you can query with a piece of contact information to retrieve all sorts of additional information, including hashes of alternate email addresses, mobile device ids, social media profiles, and plenty of other stuff: https://platform.fullcontact.com/docs/apis/enrich/person-ins...
Re:Complexities of e-mail validation logic by rootusrootus on Monday May 24, 2021 @01:39PM (#27267339)
At a certain point -- probably the moment it becomes a business unto itself -- this kind of data collection should be subject to all the same rules we've come up with for credit bureaus. It should be a legal requirement that I can get the entire profile they have built for me.
Re:Complexities of e-mail validation logic by nerdponx on Monday May 24, 2021 @03:11PM (#27268491)
I was wondering specifically if they have special cases to identify such "personal" email domains and use them for record linkage.

It seems like an obvious thing to try, but maybe not worth the effort of implementing it, given the high risk of false positives and the low % of people who actually do stuff like this (not to mention they're probably not people who click on ads anyway).

Re:Complexities of e-mail validation logic by rootusrootus on Monday May 24, 2021 @01:37PM (#27267304)
Given the sheer amount of money involved, I believe it is likely that there are players in the market who are far more capable than we give them credit for.
Re:Complexities of e-mail validation logic by licebmi__at__ on Monday May 24, 2021 @02:19PM (#27267848)
I kinda imagine that spammer go for low hanging fruit. So spammers won’t bother with defeating a catchall domain forwarding, as it’s unlikely to give them returns. Although a motivated attacker might decide to try to send interesting phishing.
Re:Complexities of e-mail validation logic by dhruvrrp on Monday May 24, 2021 @07:38PM (#27270991)
What do you use for email hosting? Ive tried to do something similar but most places have a limit for email addresses even with paid plans.
Re:Complexities of e-mail validation logic by SilverRed on Monday May 24, 2021 @09:51PM (#27271839)
Fastmail does not seem to have any limit listed. I have not tested any extreme case since I just use a wildcard.
Re:Complexities of e-mail validation logic by em-bee on Monday May 24, 2021 @12:10PM (#27266078)
well, you could turn it around and use + addresses everywhere, so that any legitimate response must be to one of your + addresses. then treat anything without + as spam.
Re:Complexities of e-mail validation logic by shard on Monday May 24, 2021 @05:41PM (#27270045)
That makes me want to use an email address of the form [email protected], just to see how websites would handle stripping out everything starting from the +.
Re:Complexities of e-mail validation logic by academia_hack on Monday May 24, 2021 @12:57PM (#27266758)
The + is also useful for knowing who sold your email address on or was responsible for a data breach. If I start getting spam to <my name>[email protected], then I know I could chase down Hulu on Twitter for an explanation.
Re:Complexities of e-mail validation logic by zzo38computer on Monday May 24, 2021 @01:13PM (#27267005)
I do a similar thing, except that the email is actually hosted at my domain rather than being forwarded, and that I have a list of email addresses that I accept and reject all others; if I receive too much spam at one address, I disable receiving at that address.

I have found this to work; I hardly receive any spam at all, and do not need any separate spam filter.

Re:Complexities of e-mail validation logic by unanswered on Monday May 24, 2021 @08:07PM (#27271202)
I've run into at least one domain that blocks their own name in your email; that was fun.
Re:Complexities of e-mail validation logic by frereubu on Monday May 24, 2021 @05:31PM (#27269965)
Didn't you find you got a deluge of spam to generic addresess like admin@, info@, offers@ and so on? I tried this, although it was probably about 15 years ago now, and reverted it because I got about the same amount of spam as genuine emails.
Re:Complexities of e-mail validation logic by progforlyfe on Monday May 24, 2021 @05:09PM (#27269738)
Although hardly anyone uses yahoo mail anymore, they actually have this feature built in. Basically email aliases.
Re:Complexities of e-mail validation logic by judge2020 on Monday May 24, 2021 @11:27AM (#27265476)
Note that you should only do this for maybe 6-18 characters, some sites will test send an email to [30-100 character random string]@example.com and see if it bounces - if it doesn't, it'll suspect that domain to be some spammer with a catch-all email inbox and block it.
Re:Complexities of e-mail validation logic by jasonjayr on Monday May 24, 2021 @11:38AM (#27265608)
That's a terrible approach, plenty of valid, legitimate non-spamming domains use catchalls of arbitrary length for all sorts of reasons.

Additionally, sending a test email like that might also get the sender placed on a black list for triggering a spam trap inadvertently.

Re:Complexities of e-mail validation logic by pmontra on Monday May 24, 2021 @11:48AM (#27265773)
That's a worrying strategy because there are many reasons for using a catchall. Example: one email per site to track companies selling personal data, then maybe bounce that single email address.

Do you know any site blocking domains with a catchall?

Re:Complexities of e-mail validation logic by LorenPechtel on Monday May 24, 2021 @12:27PM (#27266325)
Yeah, if you have a domain of your own the sensible thing is a catchall, use a different address everywhere and block the ones that spam.
Re:Complexities of e-mail validation logic by alufers on Monday May 24, 2021 @11:37AM (#27265597)
Do you know what sites do that? I have my own domain and I haven't seen anybody do that. The obvious solution is to configure your mail server to only accept usernames before the '@' that adhere to some rule which only you know. Like checking if it is a palindrome or something obscure like this.
Re:Complexities of e-mail validation logic by bbarnett on Monday May 24, 2021 @11:37AM (#27265598)
I watch multiple corp's mail logs extensively, this is not even remotely a common thing.

Worse, I know at least 5 or 6 people personally, which do catch all. It seems like a very poor method to reliably catch spammers.

Re:Complexities of e-mail validation logic by megous on Monday May 24, 2021 @09:10PM (#27271608)
Max local part size is 64 octets. So 100 chars would be out of spec.
Re:Complexities of e-mail validation logic by tyoma on Monday May 24, 2021 @11:03AM (#27265189)
The best are sites that let you sign up with a ‘+’ but not log in. Zappos used to be the most prominent example.
Re:Complexities of e-mail validation logic by PebblesRox on Monday May 24, 2021 @02:38PM (#27268072)
Reminds me of a patio11 post (which I haven't been able to track down) where he said he gets people signing up with a '+' but then forgetting to include the extra part when they log in later. His login code accepts both versions and increments a counter to track how many people were too smart for their own good.
Re:Complexities of e-mail validation logic by nybble41 on Monday May 24, 2021 @01:15PM (#27267022)
I've run across at least one banking site which accepted a password on the sign-up page which was later rejected by the login page. The validation scripts on the login page used a more limited set of permissible special characters which didn't include parentheses. Fortunately it was only a client-side check, so it was relatively simple to bypass it once using developer tools and change the password.
Re:Complexities of e-mail validation logic by marcod on Monday May 24, 2021 @03:35PM (#27268715)
American Express at one point let me set a password over 8 characters, but logging in after only worked if I provided only the first 8.
Re:Complexities of e-mail validation logic by lozaning on Monday May 24, 2021 @05:24PM (#27269901)
At one point I know they also weren't case sensitive.
Re:Complexities of e-mail validation logic by wtetzner on Monday May 24, 2021 @04:19PM (#27269225)
Why would you ever validate the characters of a password on the login page? What a weird thing to do.
Re:Complexities of e-mail validation logic by scubbo on Monday May 24, 2021 @01:09PM (#27266949)
I once had a site _silently strip_ the + from signup email. So when I submitted `[email protected]` as my email address, they started sending mail to `[email protected]`. Madness.
Re:Complexities of e-mail validation logic by not2b on Monday May 24, 2021 @03:08PM (#27268455)
This is common; spammers know the semantics of '+' for gmail and will strip it. You need to assume that it will happen.
Re:Complexities of e-mail validation logic by cgriswald on Monday May 24, 2021 @04:14PM (#27269161)
GP said the site stripped the “+” only, essentially sending his email to another address entirely. Spammers strip the “+” and whatever follows it, so the spam ends up at the same address.
Re:Complexities of e-mail validation logic by scubbo on Tuesday May 25, 2021 @05:50PM (#27283173)
If spammers are converting from `[email protected]` to `[email protected]`, they are welcome to spam it as much as they want - it won't get to me.

EDIT: moreover, a service is perfectly within their rights to _internally_ store my email as `[email protected]` if they want - but they should still accept `[email protected]` as the identifier used to login with.

Re:Complexities of e-mail validation logic by tshaddox on Monday May 24, 2021 @11:59AM (#27265915)
I’ve seen sites send emails where the unsubscribe link doesn’t work because the URL contains the email address I signed up with and that email address contains a character that their web server doesn’t play well with.
Re:Complexities of e-mail validation logic by dangoldin on Monday May 24, 2021 @11:22AM (#27265418)
Interesting. How did that work? Does that mean that they would only create the user account under the + suffix? I imagine they must have had two email fields - the canonical email for login and then a separate notification email?
Re:Complexities of e-mail validation logic by ridaj on Monday May 24, 2021 @12:54PM (#27266714)
Why do so many people responding to this seem to assume the plus sign is to fool spammers? Of course it's not useful for antispam. It's mostly meant to make it easier to trace where a (legit) email comes from, for example to set up filters. https://gmail.googleblog.com/2008/03/2-hidden-ways-to-get-mo...
Re:Complexities of e-mail validation logic by sellyme on Monday May 24, 2021 @10:50PM (#27272128)
> Of course it's not useful for antispam.

I've received spam emails to at least 70 different +addresses. It is absolutely useful for antispam.

Spammers don't care about the reputation of the company they bought or stole the data from.

Re:Complexities of e-mail validation logic by raffijacobs on Monday May 24, 2021 @11:05AM (#27265200)
Can't you use "." Anywhere in your email to use the same multiple times in Gmail?
Re:Complexities of e-mail validation logic by josephcsible on Monday May 24, 2021 @11:07AM (#27265219)
Yes, assuming the websites following this logic don't block that too, but then you have to keep track of a mapping of dots to websites yourself instead of it being obvious from what you put after the plus sign.
Re:Complexities of e-mail validation logic by alfon on Monday May 24, 2021 @11:42AM (#27265669)
Or use a password manager.
Re:Complexities of e-mail validation logic by mderazon on Monday May 24, 2021 @04:32PM (#27269352)
Spammers aside, I'm interested to know what strategy different saas companies do in regards to users creating an account with + alias - Do you let users create multiple accounts with the same email but different + alias ? Or do you recognize that it's an alias and say that the account already exists ?

Not all email providers support the + notion so you'd have to run domain lookup on some hard coded list

Re:Complexities of e-mail validation logic by megous on Monday May 24, 2021 @09:16PM (#27271655)
Why should they care though? Anyone with a catchall can create 7 billion normal looking addresses under their domain. It's not like it would prevent anything.

Also anyone with gmail address can also place dots almost anywhere into the local part, to create another unique address without using a + sign.

Re:Complexities of e-mail validation logic by mderazon on Tuesday May 25, 2021 @05:19AM (#27274683)
Because of spammers creating garbage accounts on your platform
Re:Complexities of e-mail validation logic by megous on Tuesday May 25, 2021 @08:57AM (#27276222)
Yeah, but why care about email address format, if it's not going to stop spammers anyway, and you're just risking losing legitimate customers if you mess up trying to mangle part of an address you should not be touching according to the recommendation in the standard?
Re:Complexities of e-mail validation logic by SilverRed on Monday May 24, 2021 @09:53PM (#27271849)
The email spec considers these different emails. It's not a websites job to worry about how an individual host treats them. Gmail also treats . in the user section as useless but most hosts do not.
Re:Complexities of e-mail validation logic by jjav on Monday May 24, 2021 @05:42PM (#27270052)
> This logic is why so many Web sites today won't let you use a plus sign in email addresses, which ruins a really nice Gmail feature.

Contrary to popular belief, it is not a gmail feature.

I first heard of the + as destination filtering in the very early 90s at CMU where it was broadly used. Every single email address I've had since then has support the same (and notably, apart from a test account, I've never used gmail much, so that's not including gmail).

Re:Complexities of e-mail validation logic by j_wtf_all_taken on Monday May 24, 2021 @11:19AM (#27265375)
I don't really think that's the same. Forgetting the "+" in the validation regular expression is something else than refusing to implement all kinds of extra checks to support very weird and very unused things.
Re:Complexities of e-mail validation logic by alkonaut on Monday May 24, 2021 @02:16PM (#27267808)
Sites likely prefer your canonical/standard email address over any plus version. It would be easy to trim anything after the plus too I guess and just email you at your normal address
Re:Complexities of e-mail validation logic by gumby on Monday May 24, 2021 @02:36PM (#27268054)
I configured my mail server to use _ as a sub mailbox identifier to stop creeps who block +. I assume they are doing it to make sure their precious spam shows up in my inbox.
Re:Complexities of e-mail validation logic by toxik on Monday May 24, 2021 @11:09AM (#27265246)
OTOH, it being a standardized thing, a spammer would absolutely just strip that plus part off. Better do it secretly like a catch-all.
Re:Complexities of e-mail validation logic by nybble41 on Monday May 24, 2021 @01:28PM (#27267209)
It's not really all that standardized. The use of a '+' character to indicate an alias or label is merely convention—if you run your own server you can set the separator to any character you wish, or disable the feature altogether. As far as the RFCs are concerned the '+' character is just part of the account name and there is no reason why it cannot be a mandatory part of the account name on any particular server, such that stripping off the '+' and any trailing characters results in an invalid e-mail address, or even someone else's e-mail account. For sending email or using an email address as an account identifier it's definitely incorrect to treat [email protected] and [email protected] as equivalent. The same goes for account names which differ only in capitalization or placement of periods: some servers are case-insensitive and ignore periods in account names (e.g. Google) but these are server-specific traits and compliant email senders should not assume that every server will work the same way.

The '+' alias feature is a fairly common configuration, though, so for source labels it's better to either treat all unlabeled messages as spam or else use a more opaque labeling scheme ([email protected]) which doesn't hint at an alternative untracked email address.

Re:Complexities of e-mail validation logic by stonogo on Monday May 24, 2021 @01:54PM (#27267539)
Subaddressing is standardized in RFC 5233.
Re:Complexities of e-mail validation logic by nybble41 on Monday May 24, 2021 @01:58PM (#27267594)
For the Sieve Email Filtering Language, yes. Which is not actually part of SMTP. And even in RFC 5233 the specific separator sequence is up to the server; the RFC only specifies queries for ":user", ":detail", and ":localpart" to filter on the different fields independent of the choice of separator.
Re:Complexities of e-mail validation logic by dejj on Tuesday May 25, 2021 @03:26AM (#27273910)
Can you recommend a library / tool which can extract those reliably?
Re:Complexities of e-mail validation logic by gxnxcxcx on Monday May 24, 2021 @12:51PM (#27266652)
I think that when using email aliases to identify spam sources, the crucial part is that you can filter the stripped address (as well as any unapproved alias) to be directly identified as spam and then the +alias part becomes a key to properly get into the inbox.

That whole setup for tidiness is broken the moment a desired website does not accept an alias in your address, of course.

Re:Complexities of e-mail validation logic by sellyme on Monday May 24, 2021 @10:55PM (#27272160)
> a spammer would absolutely just strip that plus part off

Why? They don't care about protecting the business interests of wherever they got that address from, and it's not like stripping the plus off will meaningfully increase the success rate.

Re:Complexities of e-mail validation logic by jimktrains2 on Monday May 24, 2021 @07:07PM (#27270751)
The plus is a standard feature of email, not a Google specific thing like ignoring dots.
Re:Complexities of e-mail validation logic by ipaddr on Monday May 24, 2021 @08:03PM (#27271169)
gmail != email. Breaking gmail features helps ensure a level playing field.
Re:Complexities of e-mail validation logic by fomine3 on Monday May 24, 2021 @10:02PM (#27271897)
It also breaks legit non-gmail address