メールアドレスの大文字と小文字の区別に関するプログラミング

多くのウェブサイトと同様に、ログインのユーザー識別子としてメールアドレスを使用しています。

RFC 5321 [ ＃2.3.11 ]には、電子メールアドレスのローカル部分は次のように記載されています。

アドレスのドメイン部分で指定されたホストのみがセマンティクスを解釈して割り当てる必要があります

つまり、メールアドレスを処理するアプリケーションでは、GMailがユーザー名を決定するときにドットを無視する方法など、2番目に推測することはできません。また、ローカルパーツが指定されているため、アプリケーションはメールアドレスのローカルパーツを大文字と小文字を区別するものとして扱う必要があります。

しかし、ユーザーは愚かで、最近のケースでは、大文字のメールアドレスでサインアップした（そして確認メールを正常に受信してクリックした）ユーザーが、小文字のメール形式を使用しているため、ログインできないことに気付きました。住所。

受信トレイで大文字と小文字を区別するメールサーバーに遭遇したことはありません。一部がどこかに存在することは間違いありませんが、メールのユーザー名の大文字と小文字を区別することには、それを維持する問題よりも大きなメリットがないのではないかと疑問に思っています。

私は、GMailのドット処理やあらゆる種類のプラスアドレッシングをエミュレートすることはしません。なぜなら、それらはユビキタスであるとは思われず、大文字と小文字を区別するほど自動的に想定されないからです。しかし、私はそれが白黒のシナリオではないことを知っているので、誰かが実際に広範囲の大文字と小文字を区別するメールアドレスがどれくらいあるか知っているかどうか興味があります。

http://tools.ietf.org/html/rfc5321#page-42（強調を追加）：

ローカル部分の上記定義は比較的寛容であるが、最大の相互運用性のために、ホストを期待がメールを受信することは、メールボックス定義避けるべきであるローカル部分が必要（または使用）引用符で囲まれた文字列形式または場所ローカル部分はケースであります-sensitive。

rfcは大文字と小文字を区別しません。また、個人的には、大文字と小文字を区別するローカルパーツを持つホストを見たことがありません。

大文字と小文字を区別しないメールアドレスは事実上の標準です。

したがって、メールのユーザー名の大文字と小文字の区別を削除することには、保持する問題よりも大きなメリットがあると言うのは正しいと思います。

パラグラフ2.4。RFC 5321の一般的な構文原則とトランザクションモデルは次のように述べています（強調は私のものです）：

したがって、SMTP実装は、メールボックスのローカル部分の大文字と小文字を維持するように注意する必要があります。特に、一部のホストでは、ユーザー「smith」はユーザー「Smith」とは異なります。ただし、メールボックスのローカル部分の大文字と小文字の区別を悪用すると、相互運用性が妨げられるため、お勧めしません。メールボックスドメインは通常のDNSルールに従うため、大文字と小文字は区別されません。

AFAIKのすべての一般的なメールホストでは、大文字と小文字が区別されるメールを回避しています。メールの大文字小文字を区別するサービスを使ったことがないので、びっくりしません。

あなたがしなければならないことは、メールを送信するために提供されたメールアドレスを使用し、それをアカウント識別子として使用するときにエラーが発生しにくいものに変換するか、少なくとも完全に一致するものが見つからない場合のフォールバックとして使用することです。

これは、Soundexアルゴリズムが曖昧さを生み出すものを削除することにより、英語の単語または名前に対して行うことの非常に大まかな類似です。たとえば、アドレス全体を小文字に変換し、サブアドレスと英数字以外の記号をローカルパーツから削除することができます（たとえば、Lance.Boyle+sometag@Example.comに削除されますlanceboyle@example.com）。ログイン中に使用される任意のアドレスに同じ変換を適用すると、より多くのバリアントに一致するようになり、アドレスのその他の使用は提供されたバージョンになるため、ユーザーは賢明ではありません。

技術的な観点から、これはあなたのログインを行いませんわずかに簡単に強引に。これが問題になる場合は、ログインに完全一致を常に要求し、送信する電子メールは「正しい」アドレスに送信されるため、アカウントを検索するときに許容できる「ログインまたはパスワードを忘れた」オプションを提供できます。

上記のようなアドレスがサインアップと検証を経て完全に作成される場合、重複と同じように変形する他の人を拒否することは不合理ではないと思います。私は、任意のサイトのように割り当てローカルアドレスをということを断定したいLance.Boyle、LanceBoyle、lance.boyleおよびlanceboyleと異なるとして扱い、それらは、トラブルの他の種類のソースであるかもしれません。