メールアドレスは大文字と小文字を区別しますか？
電子メールの最初の部分では大文字と小文字が区別されますが、[email protected]、[email protected]および[email protected]に電子メールを送信しようとしましたが、どちらの場合も届きました。
メールサーバーはユーザー名をどのように処理しますか？大文字小文字を区別しないとメッセージが配信されない可能性がありますか？あなたの電子メールアドレスを与えるときに登録中に書かれたのと全く同じ大文字小文字を使うことが本当に非常に重要ですか？
RFC 5321のセクション2.3.11から：
標準のメールボックス命名規則は "local-part @ domain"と定義されています。現代の使用法では、単純な「ユーザー名」よりもはるかに幅広いアプリケーションを使用できます。その結果、そして中間ホストがそれらを修正することによってトランスポートを最適化しようと試みたときの問題の長い歴史のために、ローカル部分はアドレスのドメイン部分で指定されたホストによってのみ解釈され割り当てられなければならない。
そうです、 "@"の前の部分は完全にホストシステムの制御下にあるので、大文字と小文字を区別することができます。しかし実際には、広く使用されているメールシステムは大文字と小文字を区別して異なるアドレスを区別しません。
@記号の後の部分はドメインですが、RFC 1035のセクション3.1によれば、
「ネームサーバとリゾルバは、大文字と小文字を区別しないで[ドメイン]を比較しなければならない」
つまり、メールアドレスを大文字と小文字を区別しないで安全に扱うことができます。
これは昔からの質問ですが、ここでコメントしたいと思います。ある程度までは、電子メールアドレスは大文字と小文字を区別します。彼らはすぐにそのアドレスの使用をやめるだろう。 （彼らが物事を困難にする特定の理由がない限り、そして彼らは彼らが知っている特定の送信者からのメールだけを期待します。）
これは、不完全な人間だけでなく不完全なソフトウェアも存在するためです（驚き！）。これは、すべての電子メールが小文字であると想定するためです。彼らへ。受信者がそのようなメッセージを受信できない場合は、たくさんのメッセージが欠落していることに気付き、小文字のみのEメールアドレスに切り替えるか、サーバーで大文字と小文字を区別しないように設定します。
この記事への道は遅くなりましたが、私が言うには少し違ったことがあります...
>> "Are email addresses case sensitive?"
まあ、「それは……」（TM）
実際にはそれが良い考えであると考える組織もあり、その電子メールサーバーは大文字と小文字の区別を強制します。
それで、それらの狂った場所のために、「はい、電子メールは大文字と小文字を区別します」。
注：仕様でできることがあるからといって、そうすることをお勧めするわけではありません。
KISSの原則は、私たちのシステムは大文字と小文字を区別しないEメールを使うことを示唆しています。
堅牢性の原則は、大文字と小文字を区別するEメールを受け入れることを示唆しています。
解決策：
- 大文字と小文字を区別してメールを保存する
- 大文字と小文字を区別してメールを送信する
- 大文字と小文字を区別せずに内部検索を実行する
これは、このEメールが既に存在する場合は、[email protected]という意味です。
...そして別のユーザーがやってきて、このメールを使用したいと思います：[email protected]
...大文字と小文字を区別しない検索ロジックでは、「そのEメールは既に存在します」というエラーメッセージが返されます。
その解決策はあなたの場合には適切ですか？
そうでない場合は、大文字と小文字を区別する電子メールのサポートを要求するクライアントに便利料金を請求し、user @ x.comがすでに存在していても、USER @ x.comをシステムに許可するカスタムロジックを実装できます。
その場合、あなたの電子メール検索/検証ロジックは、この擬似コードのように見えるかもしれません：
if (user.paidEmailFee) {
// case sensitive email
query = "select * from users where email LIKE ' + user.email + '"
} else {
// case insensitive email
query = "select * from users where email ILIKE ' + user.email + '"
}
このように、あなたは主に大文字と小文字を区別しないことを強制していますが、彼らがそのようなナンセンスをサポートする電子メールシステムを使用している場合、顧客がこのサポートに対して支払うことを許可します。
pS ILIKEはPostgreSQLのキーワードです。 http://www.postgresql.org/docs/9.2/static/functions-matching.html
RFC 5321 2.4。一般的な構文原理とトランザクションモデル
SMTP実装はメールボックスのローカル部分のケースを保存するように注意しなければなりません。特に、ホストによっては、ユーザー "smith"がユーザー "Smith"と異なります。
メールボックスドメインは通常のDNS規則に従っているため、大文字と小文字が区別されません。
@ l3xごとに異なります。
正解が異なる可能性のある一般的な状況には明らかに2つのセットがあり、3つ目はそれほど一般的ではありません。
a）あなたはプライベートメールを送信しているユーザーです：
大文字と小文字を区別する最新の電子メールシステムはほとんどないため、おそらく大文字と小文字を無視して、使用したいケースを選択しても構いません。すべてのメールが配信されるという保証はありませんが、マイナスの影響を受けるメールはほとんどないため、 /する必要はありません。
b）メールソフトウェアを開発しています：
下部のRFC5321 2.4の抜粋を参照してください。
メールソフトウェアを開発している場合、RFCに準拠するにはwantを使用します。 can必要に応じて、独自のユーザーの電子メールアドレスで大文字と小文字を区別しないようにします（おそらく必要です）。ただし、RFCに準拠するには、外部アドレスを大文字と小文字を区別する必要があります。
c）電子メールアドレスのビジネス所有リストを従業員として管理：
同じメール受信者がリストに複数回追加される可能性がありますが、大文字と小文字が異なります。この状況では、アドレスは技術的に異なりますが、受信者が重複した電子メールを受信する可能性があります。この状況をどのように扱うかは、状況a）に似ています。つまり、それらを重複として扱い、重複したエントリを削除するのにおそらく/で構いません。しかし、これらを特別なケースとして扱う方が、「リマインダー」メールを両方のアドレスに送信して、お互いに重複しているかどうか、もしそうなら、受信者が使用したいメールアドレスを尋ねることができます。
法的見地から、両方のアドレスから確認/許可なしで重複を削除すると、責任を負うが漏洩する可能性があります個人情報/認証から- 無許可アドレス単に2人の実際に別々の受信者が同じケースに異なるケースを持っているためです。
RFC5321 2.4からの抜粋：
メールボックスのローカル部分は、大文字と小文字を区別するものとして扱わなければなりません。したがって、SMTP実装は、メールボックスのローカル部分の大文字小文字を保持するよう注意する必要があります。特に、一部のホストでは、ユーザー「smith」はユーザー「Smith」とは異なります。ただし、メールボックスのローカル部分の大文字と小文字の区別を悪用すると、相互運用性が妨げられ、推奨されません。