アカウント名:
パスワード:
>昔は8ビット目をクリアしてしまう中継者がたくさん居ました。そこでUTF-7ですよ。
Content-Transfer-Encoding: base64 という手もありますね。
というか、たれ込みの時点で文字集合と符号化を混同しているような気がします。
シフトJISでもUTF-8でもbase64で符号化したら7bitで通せますよね。
> そのような中継者が絶滅したと言い切れないのであれば、
これはいわゆる悪魔の証明ではなくて？
某所のリストを見ると年明けの段階でも結構ありますな少数とはいえ無視できないところもあるようだ
>> これはいわゆる悪魔の証明ではなくて？
その通りでしょう。だからこそ普通は
>> iso-2022-jp を使うべきです。
という話になるわけで。「どうせ証明できないんだから、もう証明できたことにしちゃえばいいじゃん」というのは暴論だ、という指摘はもっともだと思いますが？
本来は下手にメール本文に手を加えるMTAに問題があり（MTAの本文はメールの転送であり、改竄ではありません）、責められるべきはそこなんですけどね。 なのにメール送るだけの人にどうこう言うのは、どーかなーって思います。その勢いでMTAの管理者にもの申すべきですよ。
対処療法として送受信者間でどうにかするのはわかりますが。
そのためにUTF-7とかあるのに。
> # もう絶滅したよね、と思ってたら2006年に遭遇しました…。> # いい加減滅ぼしてくれよ。そうですね、今どきオープンリレーなんていい加減滅ぼしてほしいです。オープンじゃないリレーなら広い意味で受信者に含まれるでしょう。そもそもBase64でエンコードすれば8bit目を落とされても問題ありません。
>しかしまあ、なんという番号付けだろう。最初の821はともかく、>次は2000を足して2821、そのは8を5と3に分解して5321だもんなあ
ここ笑うとこ？
# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
2006年の話でしょ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
受け取れない奴が悪い (スコア:2, すばらしい洞察)
どうしても読みたいなら適切なクライアントを用意するはず。
大体、すべてiso-2022-jpで来ることを期待するなんて設計や思想そのものが間違っている。
「送る場合は厳密に、受け取る場合は寛容に」なんて送受信を行う上での基本でしょ。
というのは暴論でしょうか。
Re:受け取れない奴が悪い (スコア:5, 興味深い)
e-mail の場合、送信者と受信者だけでなく中継者も考えに入れる必要があります。
昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
運悪くそのような中継者に当たってしまうと、文字化けします。
そのような中継者が絶滅したと言い切れないのであれば、
iso-2022-jp を使うべきです。
# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
# いい加減滅ぼしてくれよ。
Re:受け取れない奴が悪い (スコア:4, おもしろおかしい)
>昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
そこでUTF-7ですよ。
Re:受け取れない奴が悪い (スコア:3, すばらしい洞察)
Content-Transfer-Encoding: base64 という手もありますね。
HIRATA Yasuyuki
Re:受け取れない奴が悪い (スコア:3, すばらしい洞察)
というか、たれ込みの時点で文字集合と符号化を混同しているような気がします。
シフトJISでもUTF-8でもbase64で符号化したら7bitで通せますよね。
Re:受け取れない奴が悪い (スコア:1)
base64のデコードくらいは別途コマンドなどでも可能なのですが、よほど重要な(人からの)メールじゃない限り読み飛ばしてしまうでしょうね。
Best regards, でぃーすけ
Re:受け取れない奴が悪い (スコア:1, すばらしい洞察)
> そのような中継者が絶滅したと言い切れないのであれば、
これはいわゆる悪魔の証明ではなくて？
Re:受け取れない奴が悪い (スコア:1, 興味深い)
某所のリストを見ると
年明けの段階でも結構ありますな
少数とはいえ無視できないところもあるようだ
Re:受け取れない奴が悪い (スコア:1, すばらしい洞察)
>> これはいわゆる悪魔の証明ではなくて？
その通りでしょう。だからこそ普通は
>> iso-2022-jp を使うべきです。
という話になるわけで。「どうせ証明できないんだから、もう証明できたことにしちゃえばいいじゃん」というのは暴論だ、という指摘はもっともだと思いますが？
Re:受け取れない奴が悪い (スコア:1)
本来は下手にメール本文に手を加えるMTAに問題があり（MTAの本文はメールの転送であり、改竄ではありません）、責められるべきはそこなんですけどね。
なのにメール送るだけの人にどうこう言うのは、どーかなーって思います。その勢いでMTAの管理者にもの申すべきですよ。
対処療法として送受信者間でどうにかするのはわかりますが。
Re:受け取れない奴が悪い (スコア:3, すばらしい洞察)
の
Re:受け取れない奴が悪い (スコア:1)
Re: (スコア:0)
そのためにUTF-7とかあるのに。
Re: (スコア:0)
Re: (スコア:0)
そういういいかげんな考え方の(自称)MTA管理者が多いから一向にスパム屋が減らないんだと思う。
「Eメールは7bitでないといけない教」を信奉していて、
7bitしか通さないMTAを7bitしか通さない状態を故意に維持したまま、
セキュリティやパフォーマンスを完璧にメンテナンスしてるというのならまた話は別ですが。
Re:受け取れない奴が悪い (スコア:2, 興味深い)
7bit しか透過しないネットワークや機器を考慮してそうなったのだと思いますが。
TomOne
Re: (スコア:0)
> # もう絶滅したよね、と思ってたら2006年に遭遇しました…。
> # いい加減滅ぼしてくれよ。
そうですね、今どきオープンリレーなんていい加減滅ぼしてほしいです。
オープンじゃないリレーなら広い意味で受信者に含まれるでしょう。
そもそもBase64でエンコードすれば8bit目を落とされても問題ありません。
Re:受け取れない奴が悪い (スコア:1)
送信元MUA→自社部署内MTA→自社MTA→どこか→他社MTA→他社部署内MTA→宛先MUA
という感じだとオープンリレーなしで中継者たくさん、という状況になり得ます。
この場合、自社MTAを受信者に含めると話がしにくいと思います。
で、こういう経路のどこかで8ビット目が捨てられてしまったとしましょう。
すると、どこで捨てられたかわからないし、
誰に文句言ったらいいのかもわからないという状況になります。
# 文句言うと逆に怒られそう。
このような状況が考えられる中で
「受け取れない奴が悪い」と言うのはまずいと思います。
> そもそもBase64でエンコードすれば8bit目を落とされても問題ありません。
はい。常時7ビットの符号にしておくのが無難です。
Re:受け取れない奴が悪い (スコア:1)
Re: (スコア:0)
>しかしまあ、なんという番号付けだろう。最初の821はともかく、
>次は2000を足して2821、そのは8を5と3に分解して5321だもんなあ
ここ笑うとこ？
Re: (スコア:0)
# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
2006年の話でしょ。