電子メールアドレスの検証はどこまで行われるべきかと思います。私の分野は主にWeb開発ですが、これはどこでも当てはまります。

私はいくつかのアプローチを見てきました：

• 「@」が存在するかどうかを単純に確認します。これは非常に単純ですが、もちろんそれほど信頼できません。
• 標準の電子メール形式のより複雑な正規表現テスト
• 完全な正規表現に対するRFC 2822 -これに伴う問題は、多くの場合、電子メールアドレスが有効であるかもしれないということですが、それはおそらく、ユーザーがどのような意味ではありません
• DNS検証
• SMTP検証

多くの人が知っているかもしれませんが（多くの人は知らない）、電子メールアドレスには、ほとんどの人が通常考慮しない多くの奇妙なバリエーションがあります（RFC 2822 3.4.1を参照）が、あなたの検証：電子メールメッセージをアドレスに送信できるようにするか、それともユーザーが入力することを意図したものであるかを確認しようとしていますか（それ以外の場合は、「有効」 'アドレス）。

私が検討したオプションは、より難解なアドレスで警告を出すだけですが、リクエストは通過できますが、これによりフォームがより複雑になり、ほとんどのユーザーが混乱する可能性があります。

DNS検証/ SMTP検証は非常に簡単に思えますが、DNSサーバー/ SMTPサーバーが一時的にダウンし、ユーザーがどこかに登録できない、またはユーザーのSMTPサーバーが必要な機能をサポートしていないという問題が発生することを予測しています。

ここにいる経験豊富な開発者の中には、これをどのように扱うのでしょうか？私がリストしたもの以外のアプローチはありますか？

編集：私はすべての中で最も明白なことを完全に忘れて、確認メールを送信しました！それを指摘してくれた回答者に感謝します。はい、これは非常に簡単ですが、関係者全員の面倒な作業が必要です。ユーザーは電子メールを取得する必要があり、開発者はユーザーデータが有効であると確認される前にユーザーデータを記憶する必要があります。

ほとんどのフォーラムのように、ユーザーに電子メールを送信して応答を待つ以外に、有効な電子メールアドレスを確認する100％信頼できる方法はありません。

単純な「@」検証ルールを使用してから、ユーザーにメールを送信してメールアドレスを確認します。

しかし、これは私の個人的な意見です...私は他の提案を待っています。

1つの提案：アドレスに+が含まれるアドレスを拒否しないでください。それらを拒否するのは面倒なことですが、有効な文字であり、Gmailユーザーはaddress+label@gmail.comを使用して、着信メールをより簡単にラベル付けおよびソートできます。

あなたの投稿では、「SMTP検証」と言うとき、サーバーに接続し、RCPT TOが受け入れられたかどうかを確認しようとしているようです。実際に確認メールを送信することとは異なるため、ユーザーのアクションに合わせてインラインで行うことを想定しています。ネットワークの問題、DNSの障害などの問題に加えて、この方法ではグレーのリストが破壊される可能性があります。方法はさまざまですが、本質的にグレーのリストは常に、接続するIPごとに受信者に配信する最初の試みを遅らせます。前述したように、これは異なる場合があり、一部のホストは最初の試行で無効なアドレスを拒否し、有効なアドレスのみを延期する場合がありますが、異なる実装をプログラムで整理する信頼できる方法はありません。

アドレスが有効であり、実際にアプリケーションで使用することを希望する所有者から送信されたことを確認する唯一の方法は、確認メールを送信することです。さて、スパムがフィルタリングされない限り、私は推測します=）。

電子メールの検証に正規表現を使用することのもう1つの弱点は、有効なトップレベルドメインをすべてキャッチし、無効なドメインをすべて拒否することはほとんど不可能であることです。

たとえば、Jeff Atwoodの返信の基本的なメール正規表現：

\ b [A-Z0-9 ._％+-] + @ [A-Z0-9 .-] +。[AZ] {2,4} \ b

2〜4文字のTLDを受け入れます。したがって、たとえば、.spamは受け入れられますが、.museumと.travel（両方とも有効なTLD）は拒否されます。

もう1つの理由は、@を探して確認メールを送信することです。

国際的なドメイン名では、ほとんどすべてが可能です。

• Håkan.Söderström@malmö.se
• punnycode@XN--0ZWM56D.XN--HGBK6AJ7F53BBA
• TEST @例子。测试.مثال.آزمایشی

テストを行いたい場合は、まずそれをpunycodeに変換する必要があります。

punycodeなしであなたがすべきことは、そこでテストすることだけです：

• 少なくとも1つの@
• ローカル部分の少なくとも1文字です
• ドメイン部分に少なくとも1つのドットがある
• ドメイン内の少なくとも4文字です（誰もtldにアドレスを持っていないと仮定し、tldは少なくとも2文字であると仮定します）

function isEmail(address) {
    var pos = address.lastIndexOf("@");
    return pos > 0 && (address.lastIndexOf(".") > pos) && (address.length - pos > 4);
}

@やのような単純なものをチェックするのが最善です。JavaScriptを使用して、実際にメールで確認を送信します。彼らが彼らのアカウントを確認するならば、あなたはあなた自身に有効な電子メールアドレスを持っています。こうすることで、実際に勤務先住所を持っていることを確実に知ることができ、フォームであまりに面白くする必要がなくなります。

偽陰性を与えないオープンソースのバリデータを使用します。手間がかからず、アプリの堅牢な検証。

Cal Henderson、Dave Child、Phil Haack、Doug Lovell、RFC 3696のテストケースを照合しました。全部で158のテストアドレスです。

私が見つけたすべてのバリデータに対してこれらのテストをすべて実行しました。比較はこちら：http : //www.dominicsayers.com/isemail

人々がバリデータを強化するにつれて、このページを最新の状態に保つようにします。Cal、Dave、Philが、これらのテストのコンパイルと、自分のバリデーターに対する建設的な批判に協力してくれたことに感謝します。

特にRFC 3696に対する正誤表を知っておく必要があります。正規の例のうち3つは、実際には無効なアドレスです。また、アドレスの最大長は254または256文字で、320 文字ではありません。

（確認メールを完全に忘れていたので）回答から検討すると、低摩擦ソリューションの適切な妥協案は次のように思えます。

1. 正規表現を使用して、電子メールアドレスが有効であることを確認し、あいまいな場合は警告を出しますが、完全に拒否することは避けます。
2. SMTP検証を使用して、電子メールアドレスが有効であることを確認します。
3. SMTP検証が失敗した場合、そしてその場合にのみ、最後の手段として確認メールを使用します。確認電子メールは、低摩擦と見なされるにはアプリケーションの外部でやり取りが多すぎるように見えますが、完全なフォールバックです。

RegexBuddyは、ライブラリから次のメール関連の正規表現を提供します。

メールアドレス（基本）

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b

メールアドレス（RFC 2822、簡略化）

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

しかし、私はピーターとスーパージョーの反応に同意する傾向があります。唯一の実際の「テスト」は、実際に検証メールを送信することです。

私は4つの異なる会社で働いており、ヘルプデスクの誰かがO'MalleyやO'Brien、またはアポストロフィの付いた他の電子メールアドレスという名前の人に怒鳴られました。前に提案したように、すべての正規表現がすべてをキャッチするわけではありませんが、手間を省いて警告を生成せずにアポストロフィを受け入れます。

-
BMB

メールボックスが存在するかどうかを実際にテストするために、さらに電子メールの検証を行うことができます。この手法には欠点があります（開発時間と誤用でブラックリストに登録される可能性もあります）。http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/

電子メールを検証する場合（つまり、ユーザーが電子メールアドレスを所有していることを確認する場合）は、確認電子メールのみが実行できます。この場合も、多くの人が専用のスパムアドレスを持っているか、OneWayMailのようなサービスを使用していますが、実際の電子メールアドレスを提供したくない場合は提供しません。したがって、基本的にはユーザーの妨害を作成しています。

検証に関しては、ユーザーが誤って間違った電子メールアドレスを入力しないようにするため、間違いなく正しい動機です。ただし、少なくともHTMLフォーム（電子メールアドレスを収集する最も一般的な方法）の場合、適切な手段とは言えません。

1つは、メールアドレスの実際の「単語」のタイプミスを認識できないことです。back2dso@example.comフォーマットだけに基づいて、間違っていることを見つける方法はありません。
しかし、さらに重要なことは、ユーザーの観点からは、入力したい電子メールアドレスが1つ（または手いっぱい）しかないことです。そして、おそらくあなたはすでにそれを入力しました。
したがって、アドレスを検証しようとするのではなく、すべてのブラウザが電子メールフィールドを認識し、そもそも電子メールアドレスを入力する必要性をなくすことに注意する必要があります。もちろん、以前に自分の電子メールアドレスをブラウザに入力したことがないユーザーがヒットする可能性が高い種類のサイトを構築している場合、これは当てはまりません。しかし、私たちの中で最もそのような立場にあると思います。

メールを使用しているコンテキストに依存すると思います。より深刻なプロジェクトではより厳密な検証が必要ですが、提供されたアドレスに確認リンクを付けてメールを送信すると、ほとんどの場合、メールアドレスが有効になると思います。

@ マイク -私は、確認メールが送信される理由の一部は、電子メールアドレスが有効であることを確実にするためだけではありませんが、それはそれを提出したユーザがアクセス可能であることを考えます。別の有効な電子メールアドレスにつながる電子メールアドレスに1文字の入力ミスを簡単に入力できますが、間違ったアドレスになるため、それでもエラーになります。

私がこれまでに電子メール検証のために遭遇した最も完全で正確な正規表現は、ここに文書化されたものです。気弱な人向けではありません。人間が解析しやすいように部分的に分割されているほど複雑です（サンプルコードはJavaにあります）。しかし、検証を最後まで行うことがメリットがある場合、私はそれがはるかに良くなるとは思わない。

いずれにせよ、ユニットテストを使用して、あなたの表現が重要だと思うケースをカバーしていることを確認することをお勧めします。そうすれば、あなたがそれをじっと見ながら、あなたは以前に働いたいくつかのケースを壊していないことを確信することができます。

あなたが何を選んだとしても、99％の時間、ユーザーは実際に自分のメールアドレスが何であるかを実際に知っていると誤解する必要があると思います。オーストラリアの誰かとして、.com.auドメインを所有できない可能性があることを通知する、非常に巧妙な電子メールの検証を非常に時々見つけます。これは、インターネットの初期の頃にはもっと多く発生していました。

最近、確認メールを送信することはユーザーに受け入れられます。また、オプトインおよび提供されたアドレスの検証の点でも役立ちます。

私が働いていた場所で開発されたいくつかのサイトでは、常に確認メールを使用しています。しかし、驚くほどよくありましたが、ユーザーは、うまくいかなかった可能性のある方法で電子メールアドレスを誤って入力し、その後、確認メールが届かないのを待ち続けることがよくありました。このような場合にユーザーに警告するために、アドホックコード（または、ドメイン名の部分ではDNS検証）を追加することをお勧めします。

私が見た一般的なケース：

• ドメイン名の中央に文字をドロップするか、他のいくつかの簡単なタイプミスをドロップします。
• TLDの混乱（たとえば、ドメイン.brへの追加、.comドメイン.brからの削除など.com.br）。
• www.メールアドレスのローカル部分の先頭にを追加します（これは構成していません。フォームのメールアドレスがいくつか見られましたwww.username@example.com）。

さらに奇妙なケースがありました。ローカル部分としての完全なドメイン名、2つのアドレス@（のようなものusername@domain.tld@example.com）などのようなもの。

もちろん、それらのほとんどはまだ有効なRFC-822アドレスであったため、技術的にはMTAにそれらを処理させることができます。ただし、入力対象の電子メールアドレスが偽物である可能性が高いことをユーザーに警告することは、特に対象読者がコンピューターに精通していない場合に役立ちます。

世界のすべての正規表現の検証は、誰かが間違ったまたは偽のメールアドレスを入力することを妨げません。本当に迷惑です。

目標に依存します。あなたがISPであり、ユーザーが有効な電子メールアドレスを作成していることを検証する必要がある場合は、可能なすべてに対して検証する正規表現を探してください。ユーザーエラーをキャッチしたいだけなら、次のパターンはどうですか：

[すべての文字、スペースなし] @ [文字と数字]（。[文字と数字]）。最後のグループが少なくとも1回表示されます。

この正規表現は次のように表示されます。

[\S]+@[\w]+(.[\w-]+)+

そして確認のために確認メールを送信します。

@ Yaakov（ここで何らかの「返信」を返信できます）

確認メールが送信される理由の一部は、メールアドレスが有効であることを確認するだけでなく、送信したユーザーがアクセスできるようにするためだと思います。別の有効な電子メールアドレスにつながる電子メールアドレスに1文字の入力ミスを簡単に入力できますが、間違ったアドレスになるため、それでもエラーになります。

同意しますが、それだけの価値があるかどうかはわかりません。また、そのための確認フィールドもあります（電子メールアドレスを再度入力します）。サイトのタイプが異なるアプローチを必要とする別の状況。

また、確認メール自体を送信しても、入力したアドレスが間違っていたことを元のユーザーに示す方法はありません。確認メールを受信しなかった後、彼らはあなたのアプリ/サイトに欠陥があると推測するかもしれません。少なくともユーザーが自分のアカウントの使用をすぐに開始できるようにすることで、特に適切に明白な場所に表示される場合は、電子メールアドレスを修正できます。

コース用の馬。

これらはすべて有効な完全な電子メール検証システムであり、特定のWebサイトに対しては、他のシステムよりも適切（または保証されている限り）になります。多くの場合、いくつかの検証手順が役立ちます。

銀行向けのWebサイトを開発している場合は、これらすべてに加えて、カタツムリのメールまたは電話による確認が必要になります。

コンテスト用のウェブサイトを開発している場合は、それらのいずれも望まないかもしれません-後処理​​でメールを確認し、失敗した場合はそれを入力した人にとってはあまりにも悪いです-大勢の人が集まってサーバーのパフォーマンスを評価するかもしれません（たとえば、テレビコンテストなど）全員がインラインで正しく検証されることを確認します。

電子メールの確認はどこまで行う必要がありますか？

必要かつ保証されている限り。

そしてそれ以上（KISS）

MailinatorやMyTrashMailのような一時的な使い捨てスパムバケツサイトを使用している人々から保護するサイトを見てきました。私はあなたがそれらを除外すべきだと言っているのではなく、ただ言っているだけです。

メールの検証で何をキャッチしようとしていますか？

電子メールアドレスの正規表現による検証では、せいぜい、アドレスが構文的に正しく、比較的妥当であることが検証できます。また、正規表現が完全に正しくない場合、実際の配信可能なアドレスを拒否する可能性があります（すでに何度も述べたように）。

SMTP検証は、アドレスが配信可能であることを判断できます。これは、グレーリストまたはユーザーに関する情報をできるだけ少なく提供するように構成されたサーバーによって課される制限に従います。MTAが偽のアドレス宛てのメールのみを受け付けていると主張しているかどうかを知る方法がなく、スパム対策戦略の一環としてそれをただ床に落としただけです。

ただし、アドレスが入力したユーザーのものであることを確認する唯一の方法は、確認メッセージを送信することです。フォームに記入している場合、私のメールアドレスはであることを簡単に伝えることができますpresident@whitehouse.gov。正規表現は構文的に有効であることを通知し、SMTP RCPT TOはそれが配信可能なアドレスであることを通知しますが、確かに私のアドレスではありません。

HTML5の登場により、少なくとも1つの新しいアプローチが可能性に追加されました。クライアント側での検証を許可する' email ' タイプの入力の使用です。Firefox、Chrome、Safari、Operaの現在のバージョンはこれをサポートします（他のブラウザーはtype = textのように扱うため、問題なく使用できますが、検証はもちろん必要ありません）。

（数回指摘されているように）実行可能なアドレスを保証することはできませんが、ユーザーエラーの可能性をキャッチするだけの場所では、非常に有益な場合があります（最終的にはサーバー側のチェックを置き換えます）。

電子メール検証の3つの主要なレベル：

1）適切にフォーマットされたメールアドレスemail@email.comの正規表現チェック

2）ドメイン名にメールサービスがあるかどうかを確認するためのMXレコードに対するドメインチェックのメール送信

3）確認リンクまたはコードを記載した確認メールを送信する

レベル1：

Visual Studioでは、「正規表現バリデーター」を使用できます。また、「ValidationExpression」プロパティでは、電子メールアドレスの正規表現形式で追加するウィザードがある「...」ボタンをクリックできます。

レベル2：

以下は、nslookupを使用して、電子メールドメインに有効なMXレコードがあるかどうかを確認するC＃コードです。Win 2008 R2およびWin 7で迅速に実行され、問題ありません。

using System.Net.Mail;
using System.Diagnostics;

public static bool checkMXRecords(string email) 
    {
        MailAddress addr = new MailAddress(email);
        string domain = addr.Host;

        string command = "nslookup -querytype=mx " + domain;
        ProcessStartInfo procStartInfo = new ProcessStartInfo("cmd", "/c " + command);

        procStartInfo.RedirectStandardOutput = true;
        procStartInfo.UseShellExecute = false;

        procStartInfo.CreateNoWindow = true;

        Process proc = new Process();
        proc.StartInfo = procStartInfo;
        proc.Start();
        string result = proc.StandardOutput.ReadToEnd();

        if (result.ToLower().Contains("mail exchanger"))
        {
            return true;
        }
        else return false;

     } // checkMXRecords

別のオプションは、Arsofttools nugetパッケージを使用することですが、Windows Server 2008 R2では、私が経験したように遅いかもしれませんが、Win 7では高速に動作します。

レベル3：

電子メールの確認のために、ユーザーがクリックしたときに電子メールアドレスを検証するために、電子メール固有の16進URL（暗号化機能を使用）などhttp://domain.com/validateEmail?code=abcd1234を生成できます。このURLをメモリに保存する必要はありません。