スレッドメモ

MLやNewsのスレッドをメモする試み。

2003|01|02|04|05|06|07|08|10|11|
2004|01|04|05|06|07|08|09|11|12|
2005|01|02|04|08|09|
2006|01|03|04|08|
2007|01|05|
2009|05|

2005-09-26 (月)

[linux-users] f2cに関する質問

[105659] Takeshi TAKIYAMA (9/27)

> g?0d8-g?4d9?c?'c??c

h??d?!c? i??c?c?*c?#c?&g?3c??h(3c??c??c??c?>c??c??c?'c??c??c
c??c?*c??c?>c?.e$?f?0c?.e>!f?h& c??c?
c? c?(c??c??c??c??c?>c??c??c

Content-Transfer-Encoding: 8bit

最近よく8bitで出で来られているようですが、私には全く読めません。他の人から指摘がないので、私の環境がおかしい(古い)のでしょうか?

[105665] Nobuhiko ENDO (9/28)

やれ 7bit とか 8bit とか、いにしえとは利用されているメール関係 ツールも変化してきているということで、多少は多めに見えもらえない でしょうかねぇ。

もちろん、多くの人から様々な意見を頂きたいと思うのならば、文字コ ードやら何らかの慣習をある程度尊重しないといけないとは思うのです が、多少の過ちというか知識不足に目くじらを立てるのは止めませんか?

と思う、元 linux-users ML 関東第二サーバ管理人なのでした。

[105666] Takeshi Kusune (9/28)

今回に関していえば、ヒステリックに責めたりする人は別にいなくて、 冷静に事象の確認および原因の考察をしているだけですから、 その指摘は筋違いに思います。

[105667] inouem@omron (9/28)

まあ、良い悪いは別として、読めないメールは意味がないですが。

> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: 8bit

が読めないメーラを使ってるのが悪いのでしょうか。:-P

[105668] Haruhiko Okumura (9/28)

8ビットUTF-8でもEmacs+Mewでちゃんと読めていますが,当該のメールについ ては,途中経路で最上位ビットが落ちているみたいですね(少なくともうちで は)。

[105669] ogochan (9/28)

> が読めないメーラを使ってるのが悪いのでしょうか。:-P

そうじゃないですか?

間違ったencodeのものが読めないのは、まぁしょうがないにしても、正しい encodeのものが読めないのは「悪い」のではないかと。

[105686] 野宮 賢 / NOMIYA Masaru (9/29)

瀧山さん> 私には全く読めません。
瀧山さん> 他の人から指摘がないので、私の環境がおかしい(古い)のでしょうか?

User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7
(Sanj) APEL/10.6 Emacs/21.2 (i386-vine-linux-gnu) MULE/5.0 (賢木)

ですと、Mule-UCS 0.84 をインストールし、.emacs の最初の方に、

と書き込んで如何でしょうか?

でも、メールは、ISO-2022-JP にして欲しい....
namazu でのインデクサの作成が大変。(:_;)

[105689] Haruhiko Okumura (9/29)

野宮さんのメールは UTF-8 7bit (quoted-printable) ですね。これが読めて元 のメールが読めなかったかたは,メーラが悪いのではなく,配送サーバが古かっ たのでしょう。

Linux だから UTF-8 は読めないというのでは世の中から取り残されるので,ぜ ひ皆さんがんばって設定してください。と同時に,ESMTP のしゃべれる MTA を お願いします。

[105700] Haruhiko Okumura (9/29)

> で、linux-users-ML の配送サーバの一つが原因なのでしょうか?分散配送なの
> で、他サーバーの人には問題が分らないのですよ。

例えば私も8ビット目が落ちて配送されている一人なのですが,大里さんからの メールのヘッダは次のようになっています。このEなしのSMTPなサーバが怪しそ うです。

Received: from echo-one.osaka-sandai.ac.jp (scan.osaka-sandai.ac.jp [133.64.2.21])
 by postman.osaka-sandai.ac.jp (8.11.7p1+Sun/3.7W-Postman) with SMTP id j8T6F4c12382
 for <lu-kansai@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>; Thu, 29 Sep 2005 15:15:04 +0900 (JST)
Received: (qmail 12463 invoked from network); 29 Sep 2005 15:20:03 +0900
Received: from unknown (HELO lists.linux.or.jp) (210.171.226.47)
 by echo-one.osaka-sandai.ac.jp with SMTP; 29 Sep 2005 15:20:03 +0900
Received: from lists.linux.or.jp (localhost [127.0.0.1])
 by lists.linux.or.jp (Postfix) with ESMTP id 60EB25FD0C;
 Thu, 29 Sep 2005 15:25:16 +0900 (JST)

[105701] T.SHIOZAKI (9/29)

# 下らないメールとか老害メールとかが多い中、
# 建設的な内容のメールには心が癒されますね。

とりあえず echo-one.osaka-sandai.ac.jp の SMTP サーバは ちゃんと EHLO に応答して 8BITMIME にも対応しているように見えるので、 lists.linux.or.jp がイニシエーションで HELO をしゃべっているのが 問題っぽいですね。設定の問題ですかねぇ。

[105706] T.SHIOZAKI (9/29)

> しかしながら、ESMTP サポートしてるのにわざわざ 7bit 目を落とすような
> SMTP サーバってあるんですかねぇ(パラノイア?)。

という疑問があったので、

Received: (qmail 12463 invoked from network); 29 Sep 2005 15:20:03 +0900
Received: from unknown (HELO lists.linux.or.jp) (210.171.226.47)
 by echo-one.osaka-sandai.ac.jp with SMTP; 29 Sep 2005 15:20:03 +0900

というあたりをヒントに qmail のソースを引っ張ってきて読んでみたら、

などと書いてあるので、Received: については

- HELO/EHLO にかかわらず、不正なホスト名が来たら (HELO ....) とくっつける
- ESMTP でもおかまいなしに with SMTP と書き出す

という感じみたいです。したがって、どうもこのメッセージから 「ESMTP ではない」と解釈するのは早計なようです。

[105710] T.SHIOZAKI (9/29)

> そういう意味では初心者呼ばわりも仕方が無いものと思います。
> 以後、気をつけます。

悪いのは仕組みのほうですから、気に病むこともないでしょう。

ここの ML の方針というのはとりあえず置いておくとしても、 「ISO-2202-JP で送ったほうがいい」というような話については、 本来はユーザが意識する必要のないたぐいの話であって、いちいち そんなことを意識しなければならないシステムの方が壊れてると言えます。 これは、特定のクライアントソフトのせいとかそういうことではなくて、 インターネット初期からある古いシステムを騙し騙し使っていることに 原因があります。文字コード問題しかり、spam の大量発生しかり。

しかしながら、壊れているシステムをこれからも使いつづけていかなければ ならないのも事実ですから、「気をつける」という心構えは良いと思います。

[105711] K Hanai (9/30)

最近のメーラは iso-2202-jp を指定していても、対応できな い文字が含まれていると、utf-8 にしてしまうものが多いです。 対応できない文字といっても、別に特殊なものでなくて、 Windows user あたりが普通に使う文字なんですよね、、、


2003|01|02|04|05|06|07|08|10|11|
2004|01|04|05|06|07|08|09|11|12|
2005|01|02|04|08|09|
2006|01|03|04|08|
2007|01|05|
2009|05|