I’ve been following this conversation, quite interesting. But, and this is just a question for the conversation. Is there any reason when the user registers that the user name (email address) isn’t folded into lowercase and stored that way?
To be honest, that would probably work most of the time, possibly all of the time. Here’s where I address the theoretical problem with it in the original post:
2. Although the domain part of an email address is case-insensitive, my understanding is that the relevant RFCs suggest that you shouldn’t make assumptions about the local part. While everything I’ve read claims that in practice it will make no difference, let’s assume that we need to preserve the address as entered at sign-up. (It’s fail-safe to do so, whether we strictly need to or not.)
Domain names are case-insensitive. So if I sign up with ‘
email@hidden’ and you store ‘
email@hidden’, there’s no problem—when you send me an email, I will receive it. My understanding is that the relevant RFCs say, in summary, that you shouldn’t make any assumptions about the local part. So if I sign up with ‘
email@hidden’, and you store ‘
email@hidden’, you can’t _assume_ that will be delivered (even though it probably will be). Even if the RFCs said explicitly that the local part was case-insensitive, you’re relying on every MDA to implement that correctly. I don’t know of an example MDA that is case-sensitive on the local part, but that doesn’t mean there isn’t one.
So, the fail-safe approach is to store what the user signed up with, and use that as the literal email address when sending out email. As a nice UX enhancement, at login time we want to make a case-insensitive comparison between what the user enters in the textfield and what’s stored in the database. It’s the latter problem we’re trying to solve here.
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden