MIMEヘッダエンコーディングは複雑すぎてつらい - tmtms のメモ
これは NSEG Advent Calender の7日目の記事です(内容は NSEG とも長野とも関係ありませんが…)。 www.adventar.org メールの送信者(From)や件名(Subject)は本来ASCII(の一部の文字)しか書くことができないんですが、MIME(RFC2047)の登場によって日本語等の非ASCII文字を記述することができるようになりました。 とは言ってもメールアプリから見て日本語が表示できているだけで、内部的にはASCII文字にエンコードされています。MIMEヘッダエンコーディングと呼ばれています。 たとえば、「日本語」という文字列は =?utf-8?b?5pel5pys6Kqe?= や =?iso-2022-jp?b?GyRCRnxLXDhsGyhC?= に変換されています。 この処理が実は非常に複雑で、正しくエンコードされてない場合がかなりあります。
意外と知られてないメールの7つの決まり事 -到達率のいいメールの書式設定の話- - 業界最安値、高到達率のメルマガ配信システムを作った
前置き メールの決まり事って言っても「目上の人に対してお疲れ様です。」を言わない、「ちゃんと、冒頭で名乗る」とかそういうことじゃなく。。。 電子メールは1970年ごろに開発されてから色々と仕様をインターネットを作ってきた偉い人達があれやこれやと決めてきました。 その、仕様をちゃんと守ってメールを作りましょうね。という話を書きます。 一括送信ガイドライン - Gmail ヘルプ にも、そのことは明記されています。相変わらずごちゃごちゃと書いていますので、話を抽出すると。 RFC5322に従ってね HTML規格に従ってね メールには Message-IDを付けてね メールヘッダに Precedence: bulk って付けて一括送信メールって教えてね リンク先ページやメールの送信者を隠蔽しないでね 本文に関係のある件名を付けてね ドメインは正しく書いてね という感じです。 いつものように一つ一
「メールアドレスのルール」なんて使ってはいけない3つの理由 - めもおきば
定期的に繰り返される話題ですがまた盛り上がっているのできちんと書いておきます。 「通るべきメールアドレスが弾かれると激おこ」という前提で話を進めます。 問題点1. メールアドレスに関して、RFCなんてそもそも守られていない 2009年以前に登録されたDoCoMo携帯のメールアドレスなど、quoted-stringじゃないのにピリオド連続するものが実在している以上、彼らを許容するべきです。 今そこにある実装 >>(越えられない壁)>> RFC です。 問題点2. メールアドレスの国際化 @の左側(addr-spec)でUTF-8を利用できるようにするRFC5335が発行されています。これにより、通すべき文字が一気に増えます。 RFC5335 Internationalized Email Headers JPRSが国際化電子メールアドレスの標準化活動に貢献 / 株式会社日本レジストリサービス
「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若くない何かの悩み
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
