Serviceを読んで理解し、同意したものとみなします。記号を付けることでひとつのアカウントのメールアドレスにタグを付けて扱うことができます。記号が含まれていると「正しいアドレスを入力してください」とバリデーションエラーを出すウェブアプリにしばしば遭遇します。バリデーション側が間違っていることになります。ことがあるのかもしれません。何かしらセキュリティリスクがあって許しておらず、そのエラーメッセージがたまたま「アドレスが間違っている」というものになっているのかもしれません。あれば自分でアプリを作る際に注意しておきたいです。逆に、単に歴史的理由や特定のライブラリのバグなのであれば気にする必要が無くなります。個の銅バッジ質問の趣旨と合ってないのは判っているのですが、こんな記事を見つけましたので紹介。15:42たぶんリスクは特になくて、プログラミングが面倒とかテストパターンが増えるとか、そういう理由で忌避されてるのかと想像しますね・・・。記号が特別な意味をもっていた時期があったのかもしれません。票8私の立場は、メールアドレスを扱うシステム作る側でもありますが、組織内でどのようなメールアドレスを作っても良いか技術面から決める側でもあります。そのため、質問の趣旨と微妙にずれているかも知れませんが、どのようなメールアドレス生成を許可するのかが関心の中心となった回答になっている事にご配慮ください。考えるべきリスクは二つかと思います。自分のシステム上で不具合が起きる可能性があるかどうか。他人のシステム上で送信できない・登録できない等の不都合が起きる可能性があるかどうか。実際は1.ではなく2.についてのみ考えるべきです。どのようなメールアドレスでも、可能な限り扱えるべきであるし、拒否すべきでは無いためです。それがもっともな理由であれば、拒否することもやぶさかでは無いと思います。そこでまずは、各システムや実装、その他において、どのような記号が許されるのかを見ていきたいと思います。RFC5322に準拠したメールアドレス本来であれば、RFC5322に準拠したメールアドレスには対応すべきです。少なくともMTAについてそのような実装になっている事を期待することは悪いことではありません。その他全てが完全にRFC5322に準拠している期待できるほど、標準仕様は守られているものではありません。RFC5322でのメールアドレスのローカル部にはdot-atom、quoted-string、obs-local-partの三つがあります。dot-atomは私達がよく目にするメールアドレスであり、英数字と記号.!#$%&'*+-/=?^_`{|}~でから作られます。先頭の.、末尾の.、連続する..はできません。quoted-stringは"で囲むことによって.の制限をなくし、ASCIIの他記号も使えるようにしています。"と\は\"と\\のようにエスケープする必要があります。obs-local-partは廃止された書き方であるため、使うべきでは無いでしょう。実際の所、MTAを除けば、後述のHTML5のようにdot-atomしか考慮されていない場合がほとんどです。docomoでメールアドレスに連続する..が昔は設定できた等、準拠しないメールアドレスがしばしば使われる事もあったことも注意すべきです。メールアドレスを扱うシステムを作る側としては準拠するパターン全てを考慮したいところですが、メールアドレスを作る側としては、dot-atomに準拠した場合であればだいたいうまくいくと期待できると考えるべきでしょう。addressHTML5では<input>でtype="email"を使うことができます。address)であるのかの判定が行われます。その時のローカル部については非常に単純で英数字と記号.!#$%&'*+-/=?^_`{|}~からなります。この妥当なメールアドレスはRFC5322のdot-atomに似ていますが、完全には準拠していません。準拠していない部分は、先頭の.、末尾の.、連続する..を許しているところです。qutode-stringは一切考慮していません。type="email">は積極的に使われていくと考えられます。Webシステムが当たり前になっていく現代において、この仕様は無視できるものではありません。HTML5において妥当なメールアドレスになるように、つまりqotued-stringは使わず、dot-atomを生成すべきでしょう。Postfixのallow_min_user=noによる制限Postfixにはallow_min_userという設定があり、この設定がyesでない限り、ローカル部が-から始まるメールアドレスの場合は、受け取りを拒否します。デフォルトはnoであり、つまり、インストール直後の何も設定していない(何も書いていない)状態では拒否します。このPostfixのデフォルトの動作はセキュリティ上の理由です。多くのPostfixのサーバーではこの設定は有効になっていると考えられます。RFC5322では-について特に制限はありませんでしたが、先頭に使うべきではありません。特別な置き換えに使われる記号Postfixでは、設定次第では、ローカル部にある%や!を@に置き換えて解釈される場合があります。これはさらに内部へリレーする場合やUUCPネットワークに対応するためのものです。%も!も問題なく使える記号のはずですが、意図せぬ置き換えを避けるために、通常の利用には避けた方が良いと考えるべきでしょう。拡張アドレスの区切り記号MTAの設定次第では記号+が拡張アドレスの区切り記号として使われる場合があります。Postfixでrecipient_delimiterが+の場合、user+extはuser+extという名前以外にもuserという名前でも存在や配送先を確認します。Postfixではデフォルトでは「空」のため無効のようです。拡張アドレスについて言及しているところのほぼ全てで、サンプルとして+が区切り文字として使われています。さんの回答にある歴史的経緯によるものかと思われます)メーリングリストでの特別なアドレスmailman等でメーリングリストを作成した場合、メーリングリストアドレスのローカル部に-bounce等とつけたアドレスが特別な意味を持つアドレスになる場合があります。任意の-を許してしまうと、他のメーリングリストアドレス用の特別なアドレスと被る可能性があるということです。利用者が任意の名前を申請し、自動的に登録されるようなシステムでは、そのようなことがないように注意が必要になります。シェルやバッチで特別な意味を持つ記号の考慮Postfixの先頭-禁止に近いのですが、メールアドレスを処理するプログラムがシェル呼び出しで処理すると言った場合、不用意なシェル展開で思わぬバグを起こす可能性があります。次のようなRubyプログラムを想像してみてください。#{temp}")もちろん、このプログラム自体が質の悪い(プログラムの内容によっては脆弱性がある)と言ってもいいと思いますが、内部用の処理に作られるプログラムは、しばしばこういった点の考慮が抜けていることがあります。言うことを事前に防ぐ意味で、シェル展開時に単独で意味がある記号#$&'*?`|~等は除外した方が良いかもしれません。非常に私事ですが、私の所の組織では、その昔0から始まる数字のみのユーザーが登録されようとしたことがあり、内部処理の途中で数値として変換され、その後、0を除いた数字のみユーザーとして一部のシステムに登録されたという事態が発生しました。そのユーザーは削除して、別の名前になったのですが、削除処理も途中でおかしくなって連携するシステム群にゴミが残り続けたというのがありました。プログラムのバグと言えばその通りですが、当時はシェルやPerlを組み合わせて作られたプログラムだったので、あまりそういった点は考慮せずに作られていました。いった古いプログラムがあることを考慮するとユーザー名の先頭は英字のみに限定するなどした方が良いかもしれません。(実際に、内の組織はそれ以降先頭は英字のみになりました。)主なクラウドサービスで使用できる記号いまやオンプレでメールサーバーを運用することは、莫大なコストの割に可用性が高められず、セキュリティ等のリスクが高くなるばかりで割に合わなくなっています。365等のクラウドサービスへの移行を真剣に検討することが求められることも少なくありません。365に移行するとなったとき、問題になるのは今のメールアドレスをそのまま使えるかどうかです。使えないメールアドレスがあった場合、利用者にメールアドレスの変更を依頼する必要があり、継続して使えないメールアドレスはビジネス機会の損失にも繋がります。全員ドメインを変えて、旧アドレスを転送するサーバーが永遠に残るという事例も珍しくありません。ユーザー名がメールアドレスとなるときは、ユーザー名に使える記号を調べておくのは必須です。Suiteで使えるユーザー名は下記に記載されています。ヘルプ記号は-_'.のみです。.についてはRFC5322と同じ制限があります。365で使えるユーザー名の情報は下記に記載されています。Docs使えると明記されている文字は.-_のみです。.-は先頭と末尾には使えません。これらはユーザー名としてであることに注意してください。エイリアスとしては他の記号をメールアドレスに設定できる可能性はあります。(詳細は未確認ですが、gmailのタグ付けのように特別な意味になる記号も注意すべきです。メールアドレスとして必須という訳ではありませんが、ほとんどのシステムでは無視されます。まとめもし、ユーザー名としても使うようなメールアドレスであれば、次のようにするとほとんどのリスクが回避できるかと思います。英小文字と数字と三つの記号-と_と.のみとする。先頭および末尾は英小文字と数字と記号_のみとする。※先頭は英小文字のみというのもあり。連続する..は含めてはいけない。同一ドメインでメーリングリストを運用する場合は、自動生成されるアドレスと被らないように考慮する。365への移行を考えているのであれば、事前に調査をしておいた方が良いでしょう。email-address準拠が一番現実的かも知れません(少なくともWebシステムの場合はフロント側の実装が一番楽です)。quoted-stringを使っているメールアドレスは(私が知る限り)見たことがないからです。.の扱いは内部のMTAによっては対応しきれない場合がありますので、注意が必要ですし、それがPostfixの場合は-から始まるメールアドレスは弾かれてしまうかも知れません。|5どの場面で許すかによって回答は変わってきます。記号によるタグ付けを許容するかスイッチすることができます。記号のついたメールアドレスを新規ユーザーアカウントとして認めたいとは思わないでしょう。別のユーザーに割り当てれば混乱が生じるのは明らかです。バーチャルドメインを使って一つのメールサーバーに複数のドメインを持たせ、それをMySQLで管理したとします。端折っているのが分かります。完全にRFCに準拠した「正しい」メールアドレスですが、上のクエリがこのアドレスを正しく解釈できるわけがありません。解釈するにはエスケープではなく適切なパースをやる必要があるのですが、MySQLのクエリ上でそれを実装するのが割に合うかは疑問です。日本の一部のケータイキャリアはRFC822に準拠しないメールアドレスを登録することが可能でした。ケータイ同士で送受信できれば事足りる多くのユーザーがこれを逆手に取って、スパムメールを遠ざける為にわざとRFC違反のアドレスを登録していたと記憶しています。(ソースが見つかりませんでした。あれば追記お願いします。完全にRFCに準拠していない「不正な」メールアドレスですが、ユーザーはPCから送信されたスパムメールがリレーサーバー上でエラーになることを期待して、あるいはこのようなアドレスがスパム避けになるという話を聞いて、こぞって使われました。これはもちろん、大問題になりました。RFCは単なるフォーマット仕様であり、サービスのリスクとフォーマット仕様は直接関係しているわけではありません。リスクに見合うメリットがあれば事業者はフォーマット仕様でも破ります。メールのような相手の居るシステムの場合は特にそうです。自分が送信するときはできる限り素直に送るようにし、逆に受信するときは寛容に構える事がリスクを回避するコツだと思います。Gmailはその伝統に則っているだけで、他のサービスで利用できるかまでは担保していません。これもリスクの一つと言えるかもしれません。さんが何を期待というか想定しているのかわからないので答えにくいというか。経路にいて、そいつらが記号を含むメールアドレスを拒絶する」リスクはありそうです。使わざるを得ないユーザーにおいて問題があるかもしれません。インジェクション脆弱性のあるシステムがバグるかもしれませんが、それはそれ、バグっているほうが悪いっすね。誰がエスケープして誰が危険から逃れられるのかがが微妙に不明です。それはオイラたち一般「使う側ユーザー」が頑張って対処することではないと思いますし、バグっているソフトを使い続けているコンテンツ提供側が悪いっす。メールが使えない可能性は0ではない、でしょうか。個の銅バッジ質問者が挙げられたASCII記号はRFC822の頃からvalidです。さん、「リスク」が何を指しているか曖昧というのはおっしゃる通りで、自分としても「多分大丈夫だと思うのだけど禁止する理由が分からない、あるとすればセキュリティか歴史的理由?」くらいの気持ちで書いているのでそこまで明確に考えられている訳ではないです。含むことができるようです。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。