RFC電子メールアドレスを確認しない

多くのサイトではユーザーがメールアドレスを入力する必要があります。私たちは、クールで精巧な開発者として、入力されたアドレスの形式をRFC規格に従って厳密にチェックするよう常に努力しています 。 これにより、アプリケーションとサイトは電子メール形式を正しくチェックし、使い勝手に問題はありません。すべてが正常に機能することを確信しているので、私たちは優しく眠ります。

ええ、どんなに！

上記の議論はクールで強化されたコンクリートのように聞こえますが、ここでの問題は、メールアドレスに完全に意味のないものが含まれる可能性があり、実際、RFC規格に従ってアドレスをチェックすると、非常に混乱する可能性があることです。

なぜそう 正しくて妄想的なメールアドレスを作成する方法はたくさんあります。 これは、一部のメールサービスでは、後方互換性のために、古くなった形式でアドレスを送信できるためです。 たとえば、これはDNSが出現する前、および現代のuser@domain.tld形式が出現する前に存在した電子メールです。UUCP「 bang path 」が使用されました—配信に関与するルートに沿ったすべてのノードのリストを表すアドレス。

メールアドレスの内部

メールアドレスは次のようになります。

mailbox@hostname
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、メールボックスはローカルユーザーアカウント、ロールアカウント、またはメーリングリストなどの自動化システムのルーターにすることができ、メーラーが配信時にアクセスするDNSサーバーに知られている場合、ホストはホスト名として使用できます。

さらに、一部のシステムでは、アドレスにタグを追加できます。 これは通常、次の形式で発生します。

 mailbox+tag@hostname
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タグとセパレーター（通常は「+」ですが、qmailはデフォルトで「-」を使用しますが、異なる構成が可能ですが）は配信中に無視されます。 これは通常、フォルダと自動化によってメールをフィルタリングするために使用されますが、受信者ごとに入力されたアドレスを分離し、個人データの悪用を識別するためにも使用できます。

したがって、「メールボックス@ホスト名」という形式のアドレスでは、「メールボックス」はユーザーアカウント、アプリケーション、またはシステムロールアカウントですが、さらにルーティングや、並べ替え、自動化、追跡に使用される識別子などの贅沢なものを含めることもできます。ホスト名」-通常はドメイン名ですが、サブドメイン、サーバー、サービス、IPアドレス、または単なるホスト名にすることができます。

有効なRFCボックス名

仕様はかなり奇妙なアドレスを承認しますが、それらのすべてをサポートすることは有益ではありません。なぜなら、一部の人は複雑すぎ、ネーミングでそのようなピルエットを作るのに十分な知識を持っている人はあまりいないからです。 このようなアドレスをサポートすると、従業員がそのようなアカウントをサポートすることが難しくなり、日常生活で使用されることはほとんどありません。

ボックスにはスペースを含めることができます。 私が覚えている限り、インターネットAOL以前は「Imya Polzovatelya」のスペースを許可しました。これは、そこから切り取られたメールボックスとしても使用されていました。

 "Alan Turing"@example.com <==  ,    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、このロジックでは、スペースのみを含むボックスが正しい：

 " "@example.com <==  ,   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これは別の有効なアドレスです。アドレスの有効な文字から作成されます。

 !#$%&'*+-/=?^_`{}|~@example.com <==      
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、アポストロフィをチェックしてください、アポストロフィはサポートされるべきです：

 Miles.O'Brian@example.com <==  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アポストロフィは引用符で囲んだりエスケープしたりするべきではありませんが、そのようなアドレスをデータベースに保存するときや他の場所に転送するときは、すべてのchiki-fartsを確認してください。

ウィキペディアにはさらに多くの例があります。

完全なRFC互換性が必要ですか？ 選択するのはあなた次第ですが、アドバイスはしません-アドレス内のスペースや非標準文字はかなり珍しいもので、ほとんどの場合それらは単なるタイプミスです。 大規模な電子メールプロバイダーは、ほぼ同じ理由でこれを許可しません。 したがって、通常、文字、数字、ピリオド、アンダースコア、ハイフン、アポストロフィ、プラス記号を許可すれば十分です。

大文字と小文字を区別するアドレス

RFCによると、アドレスの一意性は大文字と小文字を区別する一意性によって決定されますが、99.9％のプロバイダーは考え方が異なり、vasyapetrov @ example.comが既に登録されている場合はVasyaPetrov@example.comの登録を許可しません。 メールボックス名は大文字と小文字を区別しないことを考慮してください。

 ALLEN@example.com Allen@example.com allen@example.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少数のシステムは完全なケースチェックを使用して、アドレスAllen@example.comのみを許可し、他のすべてのAlleNoBの着信通信を破棄しますが、ユーザーはメールアドレスのケースを区別するために使用されないため、これは実際には機能しません。

ここでRFCの互換性を維持する必要がありますか？ 保存する前にアドレスを小文字に変換すると、少数のユーザーに問題を引き起こす可能性があります（手紙を送信することはできません）が、数百万通のメールを数回しか送信しませんでした。

ドメインは常に大文字と小文字を区別せず 、小文字にする必要があるため、データの正規化の観点からは、小文字のアドレスに変換することをお勧めします。 入力したアドレスを保存する場合は、正規バージョンが保存されるフィールドを追加します。

カスタムキャラクター

Gmailはここで異なります。標準には標準文字としてドットが含まれていますが、Gmailはドットのあるメールボックスアドレスとドットのないメールボックスアドレスを区別しません。 これらのアドレスは同じメールボックスを指します：

 first.last@gmail.com firstlast@gmail.com firstlast@gmail.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Google Appsでは、どのドメインでもGmailを使用できることに注意してください。

ここでの主な問題は、最初に入力された形式でデータベース内のアドレスを見つけることです。これにより、ユーザーとサポートサービスの両方、およびテスターのプログラマーに大量のrrが発生する可能性があります。 これは、2番目の標準形式のアドレスが便利な場所ですが、それについては後で詳しく説明します。

タグを使用したボックスの名前の拡張フォーム。

上記のように、sendmail、Postfix、qmail、Yahoo Plus、Gmailを含むほとんどのメール配信システム（ MTA ）は、拡張メールボックス名をサポートしています。 これにより、ユーザーはタグを追加して文字を並べ替えることができます。 これにより、1つのサイトまたはアプリケーションで多数のアカウントを作成できる場合があります。

 allen+one@example.com allen+two@example.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、メールボックスアドレスからタグを削除する必要がありますか？

いや！ ユーザーに親切にしてください。ユーザーは、利益のために個人データを盗んだり販売したりしないという信念に触発されます。 既存のメールボックスへの追加アカウントの登録を禁止しようとしている場合でも、別のメールボックスを登録して再度登録するのは今のところどれほど簡単か想像してみてください-エイリアスやフォルダを作成するのはそれほど難しくありません（ただし、エイリアス、フォルダ、タグについては、知っている）。

それでまた。 データベースにアドレスを格納するための2番目の正規形式を作成すると、トラブルが発生した場合に役立ちます。 必ずすべてのタグ、ポイントなどを削除し、新しく入力したアドレスをそれと比較できるようにしてください。

Unicodeおよび国際化されたボックス名

ボックス名は、拡張ASCII文字（8ビット）およびUnicode文字をサポートしていません。 この制限は、 SMTP仕様に根ざしています。この仕様が登場した時点では、これらはすべて存在していませんでした。 ただし、ISO-8859-xファミリのエンコーディングなど、ローカルで定義された8ビット値は引き続き使用できますが、どのようなエンコーディングであるかはわかりません。 実際、8ビットのメールボックスはスパマーにのみ見られました。

結局のところ、データをUTF-8で保存しているのですよね？ そのため、いずれにしても、知らない場合は使用されたロケールにそれらを戻すことはできません。

ドメイン名

メールドメインには、HTTPと同じ制限があります。大文字と小文字は区別されないため、小文字に正規化する必要があります。

サブドメイン

一部のアドレスには不要なサブドメインが含まれています。たとえば、「email.msn.com」と「msn.com」は同じメールドメインです。さらに、こうした話は企業環境でもよく発生します（これは正規化のもう1つの良い候補です）。

国際化ドメイン（ IDN ）

IDNは、ドメイン名にローカルUnicode文字を使用するために作成されました。さらに、特殊文字を使用してドメインを作成することもできます。

 postmaster@→→→→→→→.ws
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは自然界の水循環を有名に説明しています。

HTTPと同様に、SMTPは7ビットエンコーディングのみをサポートし、この不幸に対処するために、 IDNはPunycodeに変換されます。これにより、ドメイン名とUnicodeの変換が可能になります。

 postmaster@xn--55gaaaaaa281gfaqg86dja792anqa.ws
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

申し訳ありませんが、IDNを使用するとフィッシングの可能性があります。 Unicodeには、ASCII文字のいくつかの異なるインスタンスが含まれています。 これにより、攻撃者は、名前の一部の文字が内部的にではなく外部的に一致するため、元の名前とまったく同じ名前のサイトを作成できます。

これにより、回答が必要ないくつかの質問が発生します。

IDNアドレスを許可する必要がありますか？ サポートサービスを使用してユーザーにサポートを提供できますか（たとえば、サポートには中国語のキーボードがありますか？）、UnicodeまたはPunycodeで保存する必要がありますか？ 正規のアドレスを保持する場合、どのエンコードでこれを行いますか？ メーラー（MTA）は一般にIDNをサポートしますか。また、手紙を送信するときにアドレスを待つのはどのような形式ですか？

IPアドレスの構文

IPアドレスの使用が許可されています：

 allen@[127.0.0.1] allen@[IPv6:0:0:1]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、このようなアドレスは疑わしいように見え、信頼されるべきではありません。

仮住所

ユーザーに一時的な住所を提供する多くのサービスがあります。 これは通常、匿名性や信頼できないサイトでの登録に使用されます。

HotmailやYahooなどのサービスでさえ、ほぼ同じ方法で使用できる、つまりしばらくすると破棄されるエイリアスを提供します。 そのようなアドレスを識別するための単一の手法はありません。最終的に、それが目的です。 彼らは、活動を止めようとしている人々の一歩先を行くために、一定のローテーションで巨大なドメイン名のセットを使用します。

ホワイトリスト機能

電子メールアドレスは非常に複雑な場合がありますが、ちなみに、99.99％（またはそれ以上）は単純な原則に準拠しており、残りは維持するのが面倒です。

したがって、アドレスに以下が含まれている場合は、おそらくアドレスのサポートを控えるべきです。

• 大文字と小文字を区別
• スペース
• 引用符またはエスケープ文字
• '._+-
  
  
  
  以外'._+-
  
  
  
  特殊文字
• ドメインフィールドのIP
• IDN

もちろん、これによって一部のユーザーに問題が発生する可能性がありますが、この場合、ユーザーはおそらく他の適切なアドレスを使用しようとします。 さらに、これにより、ユーザーロケールに関係なく、サポートにより優れたサポートを提供できます。

また、タグをサポートする必要があると思います。

必要に応じて、このRFC互換性をすべてサポートする必要があると考えている場合でも、正規アドレスを使用してデータベースに別のフィールドを作成できます。 このフィールドのアドレスは次のとおりです。

• 小文字
• タグなし
• UnicodeからASCIIにトランスコード
• 重複するサブドメインはありません

このアドバイスは過激すぎると思われるかもしれませんが、盲目的に基準に従うよりも優れています。 おそらく、いつかそのような簡略化された表記法が新しい標準になることを知っていますか？