10

問題は次のとおりです。名前の部分にASCII以外の文字が含まれるメールアドレス（müller@example.comなど）を受け入れないサードパーティのメール配信サービスを使用しています。

そのようなアドレスをPunycodeでエンコードする：

http://en.wikipedia.org/wiki/Punycode

http://idnaconv.phlymail.de/index.php?decoded=m%C3%BCller%40example.com&idn_version=2008&encode=Encode+%3E%3E&lang=de

このアドレスを生成します：

xn--mller-kva@example.com

そして、サービスを介してそれにメールを送信することはうまくいくようです。

ただし、誰かが「xn--mller-kva@example.com」を直接登録できなかったため、「müller@example.com」宛てのメールを受信できたかどうかはわかりません。

この衝突は可能ですか？この問題に対する他の解決策はありますか？

アップデート

答えてくれてありがとう。これが私たちが学んだことの要約です：

  • 電子メールアドレスのローカル部分のパニーコーディングは機能し、そのようなエンコードされたアドレスとの間で送受信できます（もちろん）
  • ただし、プロバイダーまたはメールクライアントがエンコードを理解する、または自動的に実行するという保証はまったくありません。したがって、衝突が発生する可能性があり、アイデア全体が適切ではありません:)
  • 仕様に従って、ASCII以外の名前の部分を許可または受け入れないという、他のすべての人が行うことを単純に実行する必要があります。
  • そして最後に、サードパーティのサービスはとにかくそのようなシェナニガンを禁止していることがわかりました。
4

5 に答える 5

9

電子メールアドレスのローカル部分では、ASCII以外の文字は使用できません。限目。Punycodeはドメイン専用であり、メールアドレスのローカル部分用ではありません。

ただし、IETFは、国際化されたローカルパーツを可能にする標準を採用している可能性が非常に高いです。ただし、この標準はおそらくpunycodeに基づいていません。

于 2011-10-27T19:45:48.063 に答える
4

私は退屈して今夜これを研究していました、そして明らかにこれは拡張SMTP標準、特にRFC 6531に従ってSMTPUTF8で成文化されています。http：//en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8を参照してください。

絵文字メールボックス名を使用した簡単な実験では、Gmail経由で送信すると次のエラーが返されました。

ローカル-エンベロープの一部にutf8が含まれていますが、リモートサーバーはSMTPUTF8を提供していません

これは、アドレスの絵文字バージョンとpunycodeバージョンのどちらを使用したかに関係なく同じです。

于 2015-05-26T06:12:19.170 に答える
3

次のような形式を使用して、メールヘッダーフィールドのセクションをさまざまな文字エンコードにエンコードできます。=？UTF-8？B？w6HDq8O0？=これにより、ウムラウトなどを埋め込むことができますが、実際のアドレス部分。

これらの文字を使用して住所を作成できない理由はありません。RFC5322は、セクション3.4のアドレス部分に表示される可能性のある文字を定義しており、上記で使用するすべての文字が有効です。ただし、他のコメントが追加したように、送信先のメールクライアントがこの形式を解析できない場合は、すべて少し無駄になります。

一部のSMTPサーバーは、「誤って」ウムラウトを許可する場合がありますが、サポートされている文字範囲内にないため、リスクを冒すことはありません。

于 2011-09-22T08:24:26.997 に答える
3

電子メールアドレスのローカル部分で非ASCII文字を送信する唯一の標準的な方法は、rfc6532（国際化された電子メールヘッダー）およびrfc6531（SMTPUTF8のSMTP拡張機能）を使用することです。

私の知る限り、特に電子メールアドレスのローカル部分で非ASCII文字をエンコードする標準的な方法はありません。

  • Punyコードはドメイン名専用であり、ローカル部分用ではありません。しかし、ある文字列の小さなエンコーディングのように見えるローカル部分を持つことができますが、それは小さなエンコードされた形式で表示される必要があります。メールプログラムが小さなデコードの後に​​それを表示することを決定した場合、それは非標準的な動作です。

  • =?utf-8?Q?foobar?=回答の1つ（ thing）で言及されているエンコードされた単語のエンコードメカニズムは、メールアドレスのローカル部分には適用できず、メールボックスの表示名にのみ適用されます（これは別のものですが、関連しています。つまり、メールプログラムの可能性があります。メールアドレスの代わりに表示します）。

結局、これは、müler@example.comとxn--mler-0ra@example.com が完全に無関係な2つの電子メールアドレスであり、ドメインである場合は同じ意味を持つことを意味します（ただし、衝突する可能性はありません）。

理論的には、今（2019）までにすべてのメールサーバーがSMTPUTF8をサポートし、すべてのクライアントが国際化されたメールをサポートすることを期待できますが、残念ながら、それが重要である場合は期待しません。

ところで。メールアドレスのローカル部分だけがメール標準でus-ascii以外の文字を使用したい場合があり、それをエンコードする方法はありません（私が知る限り）。他のすべての部分には、エンコードされた単語、puny、percent、base64、quoted-printable、またはその他の形式のエンコードメカニズムがあります。

于 2019-04-02T12:45:53.540 に答える
2

いくつかのテストを行いました。ローカル部分のウムラウトは、特定の設定で機能するようです。私のMUA（爪）もアウトバウンドリレー（exim）も受信MTA（postfix）も文句を言ったり、punycode変換を行ったりしませんでした。ただし、GmailやHotmailなどのプロバイダーは、umlautsをまったく許可していません（テスト済みのWebメールと直接の送受信SMTP）。ローカルパーツのpunycodingを示唆するこのケースに関するドキュメントは見つかりませんでした。ドキュメント化されておらず、誰もそれを行わないため、衝突の問題はありません:-)

結論：そもそもローカル部分でウムラウトを受け入れるべきではなく、それらのアドレスに電子メールを送信しようとさえすべきではありません。（大手企業がそれを行わず、RFCによって文書化/サポートされていない場合、なぜそうする必要がありますか？）

于 2011-09-21T13:04:22.383 に答える