web-dev-qa-db-ja.com

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

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

emailinternationalizationnon-english
74
User

公式には、 RFC 6532 -Yesに従って。

簡単な説明については、この件について wikipedia をご覧ください。

49
Yuval Adam

アップデート2015： RFC 6532 を使用

実験的な 5335 は廃止されました： 6532 および
これは後で「Category：Standards Track」に設定され、
標準化it。

セクション3.2 （ RFC 5322 の構文拡張）は、ほとんどのテキストフィールドを
include（適切な）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.

explicitドメインを含めることに注意してください。
およびヘッダーnamesの明示的な除外。

[〜＃〜] 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.

そして セクション start：

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

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

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

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

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

8
pduersteler

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

5
André

未だに。 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のスポークスマンであるKlaus Herzig氏は説明しました。その代わり、DeNICは、IETFが国際ドメインの標準（RFC3490またはIDNA2003で知られていることもあります）に取り組んでいる更新にもっと注意を払っています。 「後方互換性がないため、私たちはそれについてそれほど満足していません」とHerzig氏は説明しました。更新が来ると、DeNICは、これまで見落とされていたシンボル「ß」（estzettとしても知られている）の後ろに重さを投げかけると言います。ドイツのレジストラはまた、後方互換性の欠如を考慮して、切り替える前に少し待つかもしれないと言います。新しい標準が安定して実行され、レジストラとプロバイダーがそれを採用すると、ßが追加されます。

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

（モニカ・エルマート）

1
guerda

短い答え：はい

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

1
Luixv

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

これを見てください 。電子メールヘッダーとRFC 2047を参照する部分を読んでください。

0
idrosid