Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need to store plaintext email addresses

blog.klungo.no

Post reply on HN
Print view View original

171–180 of 181 posts

Re: You might not need to store plaintext email addresses

#171

Post by GoblinSlayer »

ajanuary wrote: post #52
mantap wrote: post #50

Earlier quoted context omitted.

Says who? Email addresses are case insensitive. If email software treats emails as case sensitive then it is broken. People have to write email addresses on paper forms, in all caps.

Says RFC 5321 [1]: "The local-part of a mailbox MUST BE treated as case sensitive." It _does_ recommend receivers treat it as case insensitive for maximum interoperability, so it is de facto insensitive, but something implementing it as case sensitive isn't broken. [1] https://tools.ietf.org/html/rfc5321

Wait, how can it recommend to do contrary to MUST?

Re: You might not need to store plaintext email addresses

#172

Post by GoblinSlayer »

mantap wrote: post #50
inopinatus wrote: post #12

This scheme struggles in the face of email address case folding. At the protocol level, email addresses are case-folded on the RHS but case-sensitive on the LHS. So it’s crucial that LHS case is preserved by delivery systems. Unfortunately most users then treat them as folded on both. So you can successfully verify one variant, store the downcased hash, and it’ll subsequently match but delivery bounces. Or, hash the…

Says who? Email addresses are case insensitive. If email software treats emails as case sensitive then it is broken. People have to write email addresses on paper forms, in all caps.

I filled paper forms and wrote email in lower case all the time. What I miss?

Re: You might not need to store plaintext email addresses

#173

Post by GoblinSlayer »

AndrewStephens wrote: post #87

This is a clever idea but limited in applicability. It is probably fine for a low security web app or game, but could still leak personal information if the db got hacked. The problem is that the salt has to be the same for each record and that emails present a limited search space. Imagine I stole the database for blackmailable-fetish.com. All the emails are hashed with the same salt so I can brute-force the followi…

The salt is in config.

Re: You might not need to store plaintext email addresses

#174

Post by GoblinSlayer »

SahAssar wrote: post #102
medecau wrote: post #56

Earlier quoted context omitted.

Article 34.3.a seems to disavow the data processor of such requirement. The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met: (a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that rend…

I don't think hashing and encryption are considered equivalent in this case.

>(c) it would involve disproportionate effort. In such a case, there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner.

Re: You might not need to store plaintext email addresses

#176

Post by inopinatus »

Dagger2 wrote: post #166
inopinatus wrote: post #156

Earlier quoted context omitted.

> How does storing the email in plaintext get around issues involving sending emails to case-sensitive mailboxes? By the validation one performs at initial sign-up. I’m implicitly saying it’s okay to require that an email address was entered with perfectly matched case at signup, which is validated by a code or link etc, and then be more forgiving about what you receive in all subsequent uses because it’s supportive…

You could manage that with hashed emails by separately storing the case of letters in the user part, without storing which letters it's referring to. You could then apply that case to the user-provided email during checkout. (You could probably actually do a pretty good job in most cases just by bruteforcing the possible combinations and seeing which one matches the hash, but the worse-case CPU cost would be bad for…

This was proposed in another comment as well, and it’s a neat idea that unfortunately becomes fragile in the face of UTF-8 local parts, since the Unicode folding standards change over time.

Re: You might not need to store plaintext email addresses

#177

Post by inopinatus »

icedchai wrote: post #159
laszlokorte wrote: post #131

Earlier quoted context omitted.

Okay... so how is this issue currently handled? Say I create a new email account: lAsZlO@inopinatus.com and the mailbox is case sensitive. Next I create a youtube account but as E-Mail address I enter laszlo@inopinatus.com and I am told to click the link in the confirmation E-Mail... that I never receive. Well I do not like youtube anyway so I head over to hackernews and create an account to write this comment. Oh no…

I suspect you'll have difficulty creating a case sensitive email address on any public email service.

Actually I do perform case routing & delivery in one of my Fastmail accounts. It’s not the default, but it is possible, if you’re willing to write or generate Sieve, which I am.

Re: You might not need to store plaintext email addresses

#178

Post by icedchai »

inopinatus wrote: post #177
icedchai wrote: post #159

Earlier quoted context omitted.

I suspect you'll have difficulty creating a case sensitive email address on any public email service.

Actually I do perform case routing & delivery in one of my Fastmail accounts. It’s not the default, but it is possible, if you’re willing to write or generate Sieve, which I am.

What is your use case for case sensitivity? Just curious.

Re: You might not need to store plaintext email addresses

#179

Post by inopinatus »

GoblinSlayer wrote: post #169
inopinatus wrote: post #156

Earlier quoted context omitted.

> How does storing the email in plaintext get around issues involving sending emails to case-sensitive mailboxes? By the validation one performs at initial sign-up. I’m implicitly saying it’s okay to require that an email address was entered with perfectly matched case at signup, which is validated by a code or link etc, and then be more forgiving about what you receive in all subsequent uses because it’s supportive…

If you have a method to validate email by bouncing, you just use it every time.

That isn't how email confirmation works, because it's a) enormously prone to false negatives, b) subject to ruinous delays, c) occurring after the transaction i.e. too late, and d) building you a reputation as a bad sender.

This is why all email address confirmation today is asking you to click a link or enter a code.

Also note that the latter strategy is rising in popularity; it is because clickable links, whilst seeming so convenient, are themselves prone to both false positives and negatives, and also increase the likelihood of ending up in junk mail.

Re: You might not need to store plaintext email addresses

#180

Post by inopinatus »

icedchai wrote: post #178
inopinatus wrote: post #177

Earlier quoted context omitted.

Actually I do perform case routing & delivery in one of my Fastmail accounts. It’s not the default, but it is possible, if you’re willing to write or generate Sieve, which I am.

What is your use case for case sensitivity? Just curious.

A base58-encoded extension part, for segmenting actions due to email (and the replies/responses to/consequences of email) originated by a SaaS platform. Helps with routing of support requests in particular so we don't have to go back to the end-user to say "which did you mean?" and other similar CRM-ish behaviours. Also allows us to manage bounces, spam complaints, and RTBF assertions by (organisation,end-user) tuple and similar. The discriminator string itself comes from an application subsystem where it was already generated for our state machines. The (minor) downside is outbound delivery sometimes being delayed by greylisting more frequently than otherwise.

Since I've contributed to MTAs & MDAs and built multinational ISP email services in a previous life, I'm confident that every MTA of consequence is case-preserving of envelopes, I'm happy to rely on it. (this is also why I feel on solid ground pointing out the hidden gotchas in various proposed schemes that don't perfectly accommodate the same rule)

Post reply on HN