京都府で防災メールの未着トラブル発生、原因は500文字超の長い行 90
ストーリー by hylom
意外と知られていないメールの仕様 部門より
意外と知られていないメールの仕様 部門より
あるAnonymous Coward 曰く、
京都府では登録者に対し防災情報を配信するメールサービスを提供しているが、14日に発生した地震の情報を同サービスが配信したところ、NTTドコモのメールアドレスを登録していた利用者にはこのメールが届かなかったという問題が発生したそうだ(読売新聞)。また、KDDIの一部の機種では全文を表示できなかったという。
不具合の原因は、約500文字(全角換算だと思われる)を超える行があったためだという。メールのメッセージフォーマットを規定しているRFC 2822では、1行の文字数はRLFを除いて998文字以下でなければならず(MUST)、78文字以下であるべき(SHOULD)とされている。
これを受けて、府防災・原子力安全課は500文字未満で自動改行するようシステムを修正したとのこと。
RFC822 → RFC2822 → RFC5322 (スコア:4, 参考になる)
Internet Message Formatの最新はRFC5322 [ietf.org]だったような。
Re: (スコア:0)
読んでみたけど、最新でも変更なかったよ。
Re:RFC822 → RFC2822 → RFC5322 (スコア:2)
RFC822を眺めたことがありますが、行の長さに関する規定はなく。998文字[MUST]制限はRFC2822からですね。78文字[SHOULD]制限も。
で、RFC金科玉条主義者の巣くうグループに「なんで80けたで改行入れなきゃだめなの?教えて教えて」って投稿したら「ぐぬぬ」ってなってた気配が。「VT100を知ってますか」とか悔し紛れの的外れなフォローが返ってきただけでした。もちろん「そういうしきたりである」と答えればすむ話でしたが、連中にそういう発想はなかったようで。
でも今はめんどくさいんで「RFC5322にも書いてあるしそういうもんだ」って説明省略しちゃいますけどね。VT100から説き起こすのはちょっと疲れるから。
Jubilee
Re:RFC822 → RFC2822 → RFC5322 (スコア:2)
VT100以前にパンチカードって物が・・・
#私?当然1行は132文字以内ですって
Re:RFC822 → RFC2822 → RFC5322 (スコア:2)
「この規定に根拠はありません。私の強権に基づいています」みたいな。それが割と良い手の場合なのに使わない人がたまにいてもにょるみたいな?
Re:RFC822 → RFC2822 → RFC5322 (スコア:1)
たぶんDEC VT100の画面表示が80桁だったからでしょう。VT100が何かということは、すみませんが自力で調べてください。
そのあたりで80桁の長さの行に引用符号やらを入れる余地を設けて70桁前後で折り返すべしという「しきたり」ができたのだと思っています。
さすがにVT100の実機を見たことはないんですが。
Jubilee
Re:RFC822 → RFC2822 → RFC5322 (スコア:2)
ていうか、80文字×24行の源泉はvt100じゃなくてIBM3270じゃなかろうか?
Re:RFC822 → RFC2822 → RFC5322 (スコア:2)
Re:RFC822 → RFC2822 → RFC5322 (スコア:1)
うーむメタギャグが通じなかったか。
「何が何でも~じゃなきゃだめ」的な物言いをする人達をからかっただけですよ。そういう人達は当時よくRFCを拠り所にして「パソ通出身」みたいな下々の者を見下した物言いをしていましたしね。コンシューマ向けOSがインターネットに対応する以前の状況を知らない人(まあ40代後半以降かな)には分かりにくいかもしれませんが。
私自身は「いわゆる全角35文字前後で改行せよ」教を一貫して布教しています。もちろんメールはISO-2022-JPで。UTF-8にも「下品ですよ」みたいな。RFC3676も嫌い。
Jubilee
Re: (スコア:0)
2822のときはうまく末尾3桁揃ったもんだと思った(覚えやすい)けど、今も末尾2桁は揃ってるんだ。
Re:RFC822 → RFC2822 → RFC5322 (スコア:1)
おっさんホイホイ (スコア:1)
メールで長文書いたことない世代が現場に出てくるようになったんだなあとしみじみ……。
LIVE-GON(リベゴン)
Re:おっさんホイホイ (スコア:1)
『長文だった』のが原因なのではなく『1行が長すぎた』のが原因ですから、ずれてませんか?
# いずれにせよ、そんな長い1行にしていた点は理解不能ですが。
Re:おっさんホイホイ (スコア:1)
ちゃうちゃう。自分が原因だったと言っているのは、開発者がメールで長文を書いたことがないんだろうなあ、という間接的な背景のこと。年齢が上だと、それなりの割合の人間が、「おい、お前のメールの後ろ、切れてるぞ」を経験してるだろうと思うから。
LIVE-GON(リベゴン)
Re:おっさんホイホイ (スコア:1)
「ケータイ」ってのもなんか懐かしい響きですね。
Jubilee
Re:おっさんホイホイ (スコア:1)
まさにそういうことー(笑)
LIVE-GON(リベゴン)
Re: (スコア:0)
発生した地震の各地域による震度情報を何も考えず単に列挙したんじゃないかなぁ
Re: (スコア:0)
改行を画面上右側にスペース連打で行うタイプの人が作ったとか。
Re: (スコア:0)
ながいURL載せちゃったとか
でも携帯メールでは下手な改行は嫌われたりするからなぁ
Re: (スコア:0)
原因つうか、メールで長文をしょっちゅう書いてると誰もがハマる罠って意味じゃねーかなぁ
すんごい長文書いてドヤって送った時にエラーで返ってくるあの切ない感じ
Re:おっさんホイホイ (スコア:1)
それってMUAがなんとかすべき問題ですよね。
このサービス作った人、仕様書(RFC)読まずに作ってるんだろうか。
Re:おっさんホイホイ (スコア:2)
メールで長文送った時に、メーラが改行追加してくれてるのにも気付いてないだろう。
Re: (スコア:0)
むしろ「メール=携帯電話orスマートフォン」「メール≠PC」の世代が現場に出てくるようになった、
と見るべきなのではないか。
Re: (スコア:0)
ホイホイに引っ掛かってみようか。
しばらく前、長い行を含むメール(独自規格)をインターネットに流す際に、行をぶった切る処理をコーディングしたっけなぁ。
制御コードとかあるんでいろいろ配慮してさ。
80文字 (スコア:1)
メール打つ時は80文字程度で改行!というのが今でも刷り込まれているので
横長になった時代でも、ブラウザのコメント入力でも
80文字近くになると切りのいいところで改行入れてしまう悲しい習性
半角と全角 (スコア:2)
500文字は全角の事で、998文字と78文字は半角換算ですよね。
#同一文書内では単位系をそろえて欲しいと思うのは元理系のわがまま。
パソ通とかメール使いだしたころは「7x文字で改行」ルールが色々あったっけ。
わたしゃ習慣的に78文字くらいで改行しなきゃなと刷り込まれてます。
ワープロやWindowsから入っててコンソール端末をあまり使わなかった人や携帯文化圏の人たちだと全角と半角をあまり意識して使い分けないような印象があります。
#2chは知らん
私は空白や数字やアルファベットは半角に統一してしまうんだけど、そういう人たちから来る文書は全角半角が混在してたりしてコピペで使いまわそうとするときによく戸惑います。
#論文にはコピペしてないよ
Re:半角と全角 (スコア:4, 参考になる)
昨今はUTF-8なメールも増えてるから、500「文字」制限だとバイト数的にまだ多すぎな状況が出てくる可能性があるかと。
そのへんも考慮すると、日本語の場合1行は330文字ぐらいが上限?
まあRFC5322の原文に当たると
・Message BodyはUS-ASCIIの文字列
・文字数は1行998文字以内
って書いてあるから、US-ASCII以外の文字コード使う場合はそもそもMIMEエンコードしろって話もあるわけですが。
Re:半角と全角 (スコア:1)
UTF-8くらいならまだいいです。ときどきGB2312のメールが届きます。全部が全部spamなわけじゃなくて、中国人と仕事のやりとりしていて巻き込まれたものがそのままになって届いたりして。それでも化けずに表示できるから今どきのUnicodeマシンは大したものです。
RFC1468を置き換えるRFCってまだ出てないんですよね?
Jubilee
全角500文字未満でもオーバーするんじゃない? (スコア:0)
半角998文字をそのまま全角にすると499文字だけど、
全角文字列をエンコードしていたら使用できる文字数が減るよね。
Re: (スコア:0)
K-In/Outがあるからな
正直狙うのは無理だと思う。気分の問題だな。
Re: (スコア:0)
K-In/OutはISO-2022-JPのことだと思いますが、最近はUTF-8が多いのではないでしょうかね(最近のメール事情はわかりませんが)。
それでも3バイトの文字がありますので、やっぱり「500文字」という表現はおかしいと思いますが。
Re:全角500文字未満でもオーバーするんじゃない? (スコア:1)
そして、一般にはUTF-8 で符号化した方が ISO-2022-JP で符号化した場合より長い傾向にあります。 また、UTF-8 で日本語で使用される漢字を符号化すると、もれなく 3 バイト以上になります。
Re: (スコア:0)
カタカナIn/Outだったりしてね?
某J,V,S的な社名変更した会社のメールは、絵文字In/Outのコードと
半角カタカナIn/Outのコードが付加された記憶がある。
Re:全角500文字未満でもオーバーするんじゃない? (スコア:1)
UTF-8 の場合、「1文字」の定義がそもそも難しい。
「U+30AB U+309A」とか、音符とか。
Re: (スコア:0)
K-In/Outと書いたのが適当で突っ込まれてて申し訳ない
何と言ってもこの辺いじったのは10年以上前なので適切な用語が思い出せなくて・・・
ここ以下に書き込んでいる方は皆さん理解してらっしゃるようなのでよかったですが、
そのほかの方は嘘用語を覚えないようにしてくださいませ。
ごめんなさいね。
なお個人的にはUTF-8はあんまり好きじゃないなぁ。
データ長くなるし
改行は適当に(全角)40文字ぐらいで入れてます
Re:80文字縛り(おふとぴ) (スコア:1)
規約を決めた人はきっとIBM3270やVT100系/220系実機を大事に大事に使っている人だったんだよ。
#上位機なら132桁が、というツッコミは却下するものとする。
そもそも携帯キャリアのメールって (スコア:0)
RFCに色々と反している!
というのは昔から方々で言われてませんでしたっけ?
それを抜きにしても世間のメールシステムだってアドレスのコメントとか問題なくても不正扱いされたりするし
Re: (スコア:0)
RFC違反のメールアドレスより、PCを一律受信拒否してるのにネットショップで携帯アドレス入れるのやめてくれ
Re: (スコア:0)
自分でメールフィルタ管理出来ない人がたくさんいるからしょうがない。
悪いのは迷惑メールを防げないキャリア側だと思う。Gmail並にうまくスパム排除してくれたら、そもそもフィルタリングなんか不要。
Re: (スコア:0)
拒否と許可のフィルターがどういう順序で適用されるのか、よく分からんよ。
Re:そもそも携帯キャリアのメールって (スコア:1)
過剰フィルタリングしてしまったかどうか
知るすべのないdocomoのi-mode mail。
即時その場でエラー返しで廃棄するそうで。
だから、一度引っかかったものをホワイトリストに加える…ってこともできません。
直接の原因はMIMEにしてないことじゃないの (スコア:0)
MIMEにすることで一行が長いメールを送ることは可能なはず。原因はMIMEにする必要があるのに、やっていないということでは。
Re:直接の原因はMIMEにしてないことじゃないの (スコア:4, 参考になる)
MIMEで規定されているものはたくさんあるのに、そのどれのことかを指さずに「MIME」って一言で片付けちゃってるからすれ違いが発生してる感じですね。
RFC1468 に従うと、本文は Content-Type: text/plain; charset=ISO-2022-JP になる。
これは 7bit で伝送可能なので、Content-Transfer-Encoding を base64 や quoted-printable にしなくてもいい。というのが
> RFC 1468によるとメールの本文はMIMEエンコードするなということになっている。
この文章の意図かな。
一方、元コメの
> MIMEにすることで一行が長いメールを送ることは可能なはず。
についてですが、MIMEの規格に従うと、text/plain、Content-Transfer-Encoding: 7bit のままでも、RFC3676で規定された format=flowed; delsp=yes; [geocities.jp]を使えば、RFC1468に反しない形式で一行998文字を超えたテキストを表現できます。
これは、行が長いテキストは、送信時に「スペースと改行」を適宜埋め込み、受信側では「スペースと改行」は取り除く、というもの。
非対応な旧来のMUAでみた場合には「自動的に改行整形されたテキスト」に見えるし、対応MUAなら元の長大行が復元される、というしくみです。
今回の問題の場合、相手は携帯電話ですが、古い携帯電話だとUTF-8とかquoted-printableには非対応な機種もあります。
quoted-printableやbase64でも長大行は実現できますが、そうではなくRFC1468の範囲内で対応するのが無難でしょう。
Re:直接の原因はMIMEにしてないことじゃないの (スコア:1)
RFC3676は互換性を考慮した規格ですよ。
UTF-8 や quoted-printable なメールは、非対応のMUAで受信すると文字化けしてしまいますが、
format=flowedなメールは、非対応なMUAでも文字化けなく受信することができます。
そもそも、RFC1468自体、「MIME の規定に従った形式」で「MIME登場前の旧来の日本語MUAで問題なく受信できる日本語のメール」を送信するにはどうすれば良いのか、というMIME登場以前のMUAからすれば後付けのRFCです。
RFC3676を飛び道具と言うなら、RFC1468だってMIME非対応な古いメーラから見れば飛び道具になってしまいますな。
公務員だからしょうがない (スコア:0)
メールに関わらず相手の事を考えないからこういう仕事になる。
やればいいんでしょ感がすごい。
作ったのは下請けじゃね? (スコア:0)
作ったのはたぶんSIerでその下請けだと思われ。まあ公務員よりもさらに↓だけど
Re: (スコア:0)
お前、何読んでるんだ?
キャリアはいかれたメールを捨てただけ。
気象庁は完全に無関係。
Re: (スコア:0)
"府"防災センターですよ
どこもでしょう、たぶん (スコア:1)
本当に「みんな」ですか?RFC3676形式で長い行に見えているだけじゃなくて?
わりと最近も998文字制限に引っかかるメールを書いたユーザーから「メールが文字化けする」って相談を受けた覚えがあります。
Jubilee
Re:誰も突っ込まないけど (スコア:2)
メールの改行記号は CRLF だよ。 RFC 2822 や RFC 5322 に書いてある。