メールアドレスに国際（英語以外）の文字を含めることはできますか？

Question 1

可能であれば、ユーザーからのそのような電子メールを受け入れる必要があり、そのようなアドレスにメールを送信するときにどのような問題が予想されますか？

Question 2

公式には、RFC6532に準拠-はい。

簡単な説明については、このテーマに関するウィキペディアをチェックしてください。

Question 3

2015年の更新：RFC6532を使用

実験5335は、現在使用されていません：6532と
これが後の「カテゴリー：標準化過程」に設定されている、
作ることの標準。

3.2節（への構文の拡張RFC 5322は）し、ほとんどのテキストフィールドを更新しました
（正しい）UTF-8が含まれます。

The following rules extend the ABNF syntax defined in [RFC5322] and
[RFC5234] in order to allow UTF-8 content.

VCHAR   =/  UTF8-non-ascii
ctext   =/  UTF8-non-ascii
atext   =/  UTF8-non-ascii
qtext   =/  UTF8-non-ascii
text    =/  UTF8-non-ascii
             ; note that this upgrades the body to UTF-8
dtext   =/  UTF8-non-ascii

The preceding changes mean that the following constructs now
allow UTF-8:
   1.  Unstructured text, used in header fields like
       "Subject:" or "Content-description:".
   2.  Any construct that uses atoms, including but not limited
       to the local parts of addresses and Message-IDs. This
       includes addresses in the "for" clauses of "Received:"
       header fields.
   3.  Quoted strings.
   4.  Domains.

Note that header field names are not on this list; these are still
restricted to ASCII.

ドメインが明示的に含まれていることに注意してください。
そして、ヘッダー名の明示的な除外。

NFKCについても注意してください：

The UTF-8 NFKC normalization form SHOULD NOT be used because
it may lose information that is needed to correctly spell
some names in some unusual circumstances.

そしてセクション3の始まり：

Also note that messages in this format require the use of the
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.

Question 4

問題は、一部のメールクライアント（サーバーツールやデスクトップツール）がそれをサポートしておらず、たとえばumlautsを含むアドレスにメールを送信しようとすると、「無効なメール」例外がスローされることです。

完全なサポートが必要な場合は、電子メールアドレスの部分を「punycode」に変換することでトリックを実行できます。これにより、ユーザーは通常の方法でアドレスを入力できますが、サポートされているレベルの方法で保存できます。

例：müller.com»xn--mller-kva.com

どちらも同じことを指しています。

Question 5

多くのトップレベルドメインはすでにドメインに非ASCII文字を許可しており、ドメインは電子メールアドレスの一部であるため、完全に可能であるため、「はい」と思います。このようなドメインの例はwww.öko.deです。

Question 6

短い答え：はい

ユーザー名だけでなく、ドメイン名も許可されます。

Question 7

未だに。IEEEはこれを行うことを計画しています： H-オンライン記事：国際化された電子メールアドレスを計画しているIEFT、ここにRfC：国際化された電子メールアドレスのためのSMTP拡張があります

H-Onlineからの引用（ダウンしたとき）：

インターネット技術特別調査委員会（IETF）は、ASCII文字セット外の記号を含む電子メールアドレスヘッダーの標準化に関する3つの重要なドキュメントを公開しています。つまり、すぐに、メッセージの本文だけでなく、電子メールアドレスでも漢字、フランス語のアクセント、ドイツ語のウムラウトを使用できるようになります。したがって、あなたの名前がZoëで、ファサードを製造する会社で働いている場合は、新しい電子メールアドレスに興味があるかもしれません。しかし、プロバイダーの代表はすでにうめき声を上げています。彼らは、Unicode標準UTF-8が、現在一般的な電子メール言語として使用されている情報交換のための米国標準コード（ASCII）に取って代わる場合、「アップグレードマニア」が必要になると述べています。

RFC 5335は、事実上すべての電子メールヘッダーでのUTF-8の使用を指定しています。SMTPクライアント、SMTPサーバー、メールユーザーエージェント（MUA）、メーリングリスト用のソフトウェア、他のメディアへのゲートウェイ、および電子メールが処理または渡されるその他すべての場所に変更を加える必要があります。RFC 5336は、SMTP電子メールトランスポートプロトコルを拡張します。プロトコルのレベルでは、拡張にはUTF8SMTPというラベルが付いています。

アップグレードされていないシステムによって受信者に到達する前にUTF-8電子メールがスローされた場合に、UTF-8電子メールがソフトランディングするように、新しいヘッダーフィールドが一種の「緊急パラシュート」として追加されます。「OldAddress」は純粋にASCIIアドレスです。ただし、OldAddressは、2回目の転送試行のチャネルとして使用されるのではなく、フィードバックが確実にホームに送信されるようにするために使用されます。

最後に、RFC5337は、非ASCII電子メールの配信ステータスに関連する正しいメッセージが送信されることを保証します。それ以上の輸送が拒否された場合でも、到達不能な宛先の正しいアドレスを返送する必要があります。電子メールアドレス国際化（EAI）ワーキンググループは、さまざまなヘッダーフィールドとエンベロープの多数の「ダウングレードメカニズム」にも取り組んでいます。可能であれば、元のヘッダー情報を「パッケージ化」して保存します。

それにもかかわらず、「。de」ドメインのレジストラであるドイツのDeNICは、これを前進させています。「私たちにできることは本当に多くありません」とDeNICのスポークスマンKlausHerzigは説明しました。代わりに、DeNICは、IETFが国際ドメインの標準（RFC3490、または時々知られているIDNA2003）のために取り組んでいる更新にもっと注意を払っています。「下位互換性がないため、私たちはそれについてそれほど満足していません」とHerzig氏は説明しました。更新が行われると、DeNICは、これまで見過ごされてきたシンボル「ß」（別名estzett）の背後に重みを置くと述べています。ドイツのレジストラは、下位互換性がないことを考慮して、切り替える前に少し待つ可能性があるとも述べています。

対照的に、専門家は、中国と台湾の中国のレジストラが国際化された電子メールの変更を迅速に実装すると信じています。CNICとTWNICの代表者は、規格の作成者です。現在、中国のユーザーは、すでに国際化されている中国のドメインの場合、@の左側にASCIIで、右側に漢字でメールを作成する必要があります。

（モニカ・エルマート）

Question 8

答えは「はい」ですが、特別にエンコードする必要があります。

これを見てください。電子メールヘッダーとRFC2047に言及している部分を読んでください。