Hacker News Reader

Hacker News

Comment by ryantgtg | Hacker News Reader

Parent Full thread

ryantgtg

Wouldn’t it trivial for them to strip out all values from + to @ prior to selling your address?

View on HN

Yes. I've written code that does this for parsing leaked email lists before as part of a normalizing step.

Not sure why this is downvoted. I can imagine non-nefarious reasons to collect these lists.

Why do people downvote stuff that simply triggers them? This is useful info

Because it's cruise control for not needing to justify their point of view whilst still pushing their perspective. Sick, right? Votes and e-peen points have to be the worst aspect of HN and Reddit.

It's spam detection evasion.

Also, depending on the legislative framework, it might be illegal: If I give company my email address with a plus and an identifier in it, I give them permission to contact me under that specific email (with the plus on it). If I as a result receive emails under another address (without the plus on it), this might be a GDPR violation.

I don't see how it's a GDPR violation, but it does turn any contact into spam - the +less address didn't solicit any contact.

Not that spam laws are enforced or particularly enforceable.

It's a violation because you have to get explicit permission for each and every way of communication. So giving permission to be contacted through a single email address doesn't mean you gave permission for the phone or in this case another email address.

True, though there are marketing comms laws that predate GDPR (at least in the UK) that cover that too - that's what I meant by it being unsolicited spam.

In either case, the existence of the different authorised email address is irrelevant.

The original post never said they were using these lists to send unsolicited emails. It's your assumption they are a spammer; while I said I can imagine non-nefarious reasons to collect these lists.

For example: A lot of pentesting companies offer "darknet research" as part of their engagement; these have a non-nefarious use for these leaks, including private addresses: Given a list of customer's employees it's easy to guess some obvious Gmail/GMX/Yahoo/... addresses and check if they might be affected by any leaks (password reuse is pretty popular, especially with the not so technically minded). Troy Hunt, who runs haveibeenpwned, uses these lists as well; I suppose he normalizes Gmail, too.

Yes, OP could still be an evil /dudett/..., but while "innocent until proven guilty" might not be a HN rule, it's still something I like to assume about random people in the internet.

Hm, just saw: Something ate the "evil dude slash dudette slash ...".

I imagine the challenge is knowing what parsing rules apply to which domains. Gmail supports the + thing, but that's non-standard. Is that something you tried to handle in a general way?

> Gmail supports the + thing, but that's non-standard

Plusaddressing is valid and has been since 1982[1]. It's part of RFC822 and the subsequent RFC2822.

The fact that many websites do not allow + in an email address during validation is a common programming mistake and the sign of an undertrained engineer.

[1] https://people.cs.rutgers.edu/~watrous/plus-signs-in-email-a...

Sorry, I should have been clearer. Gmail will place messages for user@gmail.com and user+foo@gmail.com in the same mailbox. The grandparent comment talks about normalizing the address by removing stuff after the +. This sort of deduplicates the addresses. Other platforms may have distinct mailboxes for user and user+foo, so you can't strip it on those platforms. The mapping of user+foo to user is non-standard.

There won't be a general approach to deduplicating addresses that map to the same mailbox as the mapping rules aren't always public. But for Gmail, the rule is public, so a best effort deduplication could strip the +.

> The fact that many websites do not allow + in an email address during validation is a common programming mistake and the sign of an undertrained engineer.

Or just sanity.

I am totally onboard (https://news.ycombinator.com/item?id=31797121#31822961) with having compliant parsers (or just not using them)

But the RFC from what I can recall is _wild_. I can't find the part so maybe I am mixing something else up, but I believe you can embed comments into an email address.

All I am saying is that the possible scope of valid email addresses is likely so large, trying to write a parser for them is a sign of an underexperienced team rather than not having one at all.

Malicious actors are probably going to implement the Gmail parsing rules before they even look at the standard.

it should be trivial, i don't know if many do it - iirc haveibeenpwned.com doesn't

Reply on news.ycombinator.com