まだインストールしてみただけなんですが - 秀丸メール情報交換会議室 - スレッド00179, 2001/04/01

まだインストールしてみただけなんですが

えるさん　01/04/01 21:56

・[設定|全般的な設定]

[送受信][送信と受信の順番]

デフォルトで [送信が先] ですが、POP=>SMTP がそこそこ普及してきて
いるので、ユーザのトラブルを避けるためには [受信が先] をデフォル
トにしておくほうがよいかと思います。
＃ [送信が先] でアカウントの設定が [POP before SMTP] になっていると、
＃どのように動作しているのかな？という気もしますが、ユーザが自分が
＃ POP before SMTP を必要としていることを知らない場合も多いです。

[特別][鶴亀メールで MessageID を生成]

問題のある MessageID を付与するサーバが存在することは、ネットワー
ク管理者の設定の問題ですが、問題のある MessageID が付与されたメー
ルを発生させるのはユーザ環境の問題になります。
ユーザ環境で常にまともな MessageID が生成できるとは思いませんので、
デフォルトは OFF にしておくべきかと思います。
特に、この設定は [特別] などに分類されていて、ユーザが変更しない可
能性が高そうに思えます。

[設定|全般的な設定][特別][鶴亀メール起動時のパスワード]

POP の認証と同期できませんかね？ (要望)

・アカウントの新規作成

[Bcc ヘッダに自分のアドレスを入れる]

Fcc ( 指定したメールフォルダに送信したメールを保存する )
のほうが良い感じがするのですが。
＃その時に送信済にもコピーが残るかどうかは難しいところかも

[テンプレート]

挿入ボタンを押したときのメニューが非常に大きいです。
Win9x だとリソース面でも厳しくなってきます、メニューの
階層化を考えてもよい量になっているのではないでしょうか？

他の方もかかれていましたが、

・特定のサイズを超えたメールは受信しない

はほとんどのメーラが実装していて必須かと思います。

RE:00179 まだインストールしてみただけなんですが

"y.iida" さん　01/04/01 22:52

> [送受信][送信と受信の順番]
>
> デフォルトで [送信が先] ですが、POP=>SMTP がそこそこ普及してきて
> いるので、ユーザのトラブルを避けるためには [受信が先] をデフォル
> トにしておくほうがよいかと思います。

これは、送信の方が先が良いです。
早く送りたいのに（送信だけ押せば良いだろう！という話もありますが）
うっかり癖で押してしまってから、長々と受信を待つのは苦です。

> ＃ [送信が先] でアカウントの設定が [POP before SMTP] になっていると、
> ＃どのように動作しているのかな？という気もしますが、

文字通り内部ではログインしてから送り出しています。

> ユーザが自分が
> ＃ POP before SMTP を必要としていることを知らない場合も多いです。

これは、そもそもエラーになるし、一般的なISPでは
設定マニュアルにも絵入りで書かれていると思います。
もし知らないとすれば「送信（だけ）」という処理は不要という事になるし。

> [特別][鶴亀メールで MessageID を生成]
>
> 問題のある MessageID を付与するサーバが存在することは、ネットワー
> ク管理者の設定の問題ですが、問題のある MessageID が付与されたメー
> ルを発生させるのはユーザ環境の問題になります。
> ユーザ環境で常にまともな MessageID が生成できるとは思いませんので、
> デフォルトは OFF にしておくべきかと思います。

基本的にボクも賛成ですが
この場合、MessageIDを振れないサーバーでは
どのようになるのでしょうか？

> [設定|全般的な設定][特別][鶴亀メール起動時のパスワード]
>
> POP の認証と同期できませんかね？ (要望)

レジストリを見ていただければ分かると思うので
POPパスワードと同じという事であれば絶対に反対です。

RE:00180 Message-IDについて

なんと さん　01/04/01 23:23

なんとです。

> > [特別][鶴亀メールで MessageID を生成]
> >
> > 問題のある MessageID を付与するサーバが存在することは、ネットワー
> > ク管理者の設定の問題ですが、問題のある MessageID が付与されたメー
> > ルを発生させるのはユーザ環境の問題になります。
> > ユーザ環境で常にまともな MessageID が生成できるとは思いませんので、
> > デフォルトは OFF にしておくべきかと思います。
>
> 基本的にボクも賛成ですが

僕は反対です。理由は↓

> この場合、MessageIDを振れないサーバーでは
> どのようになるのでしょうか？

以前、まさにMessage-IDがないメールが届いてきたことがありました
(^^;。サーバーがつけてくれるものとは限りません。その代表たる
Qmailも最近増えてきてますし。

またこういった資料もあります。
http://www.emaillab.org/essay/message-id.html#where

それに鶴亀が生成してくれないと、自分が送ったものを残しておいて
もスレッド表示ができないのでは？

> > ユーザ環境で常にまともな MessageID が生成できるとは思いませんので、

というのは、要は鶴亀が環境によらずユニークなMessage-IDを生成で
きればいいのでは？

RE:00181 Message-IDについて

"y.iida" さん　01/04/01 23:33

> なんとです。

毎度です。

> 以前、まさにMessage-IDがないメールが届いてきたことがありました
> (^^;。サーバーがつけてくれるものとは限りません。その代表たる
> Qmailも最近増えてきてますし。

やっぱ空なんですね。それはとってもマズイ！

> というのは、要は鶴亀が環境によらずユニークなMessage-IDを生成で
> きればいいのでは？

そうなんですけど、このユニークというのが曲者でして
ボクしては、アカウントなどのＩＤを含んで欲しくないのです。
ＭＬなどでメアドが分かるのは良いのですが（仕方がない事だし）
そこから何処に転送されているか分からないし・・・。

RE:00179 まだインストールしてみただけなんですが

ひろさん　01/04/02 00:23

　えるさん今日は、ひろです。
> [送受信][送信と受信の順番]
>
> デフォルトで [送信が先] ですが、POP=>SMTP がそこそこ普及してきて
> いるので、ユーザのトラブルを避けるためには [受信が先] をデフォル
　「送信が先」をデフォルトにしておくことが何故ユーザのトラブルを招く
事になるのか不明です。

> ユーザ環境で常にまともな MessageID が生成できるとは思いませんので、
> デフォルトは OFF にしておくべきかと思います。
　逆に MUA が付けないと、宛先が複数指定されている場合、宛先毎に異なる
Message-Id を付けてしまう場合もあるようです。ですからどちらが良いと
は単純には決められません。また Message-Id はユニークであればよいわけ
で、同じハードウェアを使う限り、えるさんの心配は杞憂ではないでしょう
か? (異なるハードウェアを使うなら、時計を合わせば済みます)

> [設定|全般的な設定][特別][鶴亀メール起動時のパスワード]
>
> POP の認証と同期できませんかね？ (要望)
　セキュリティのことを考えるなら、こういったパスワードは本来各々別々
にするものです。よって単純に同期は、出来ないほうが反って良いと思いま
す。

> [Bcc ヘッダに自分のアドレスを入れる]
>
> Fcc ( 指定したメールフォルダに送信したメールを保存する )
　この 2 つの気のは似て非なるものではありませんか?
　Bcc は送信先で、Bcc ヘッダの内容が見られないだけでそれ以外は、To,
Cc ヘッダと何の違いもありません。次に Fcc は RFC で定義されているヘッ
ダなのでしょうか? これは鶴亀の場合、この機能は「送信済み」フォルダそ
の物であり、送信時に移動を行いたい場合、「振り分け」機能を使えばよい
と思います。

RE:00182 Message-IDについて

なんと さん　01/04/02 00:36

なんとです。

> そうなんですけど、このユニークというのが曲者でして
> ボクしては、アカウントなどのＩＤを含んで欲しくないのです。
> ＭＬなどでメアドが分かるのは良いのですが（仕方がない事だし）
> そこから何処に転送されているか分からないし・・・。

あれ、そのメールのFromアドレスを利用している（と僕には見えます）
のですから、どういった場合にまずいでしょうか…？

RE:00179 まだインストールしてみただけなんですが

tnobu2 さん　01/04/02 01:06

>[送受信][送信と受信の順番]
>
>デフォルトで [送信が先] ですが、POP=>SMTP がそこそこ普及してきて
>いるので、ユーザのトラブルを避けるためには [受信が先] をデフォル
>トにしておくほうがよいかと思います。
>＃ [送信が先] でアカウントの設定が [POP before SMTP] になっていると、
>＃どのように動作しているのかな？という気もしますが、ユーザが自分が
>＃ POP before SMTP を必要としていることを知らない場合も多いです。

同列に扱っている場合も多いですが、「POP before SMTP」と「受信
してから送信する」は厳密には違います。
「POP before SMTP」の場合は、単に「POPサーバにログインして認証
を受けること」が重要なので実際に受信する必要はありません。

もしデフォルトで「受信が先」とするようになっていても、単に「送信」
のみの場合は「受信」動作を伴わないので、「POP before SMTP」の設定
は必須です。

むしろ「POP before SMTP」をデフォルトONにしておく方がいいのではない
でしょうか？

RE:00187 Message-IDについて

"y.iida" さん　01/04/02 07:56

> あれ、そのメールのFromアドレスを利用している（と僕には見えます）
> のですから、どういった場合にまずいでしょうか…？

ネチケットやマナーの問題を含みますが（ここで議論する気はありません）

MessageIDを引用する場合で（引用者が悪いとは一口に言いませんが）
それにドンドン、レスがついてボクの発言じゃなくなっているのに
いつの間にか、ボクが書いたようになって、そのまま引用され続けて、
あげくの果てには、ＤＭまで来る始末で・・。
それ以来、MessageIDをサーバーが振るのを確認した上でサーバーに
振らせています。

RE:00188 まだインストールしてみただけなんですが

えるさん　01/04/02 08:40

>「POP before SMTP」の場合は、単に「POPサーバにログインして認証
>を受けること」が重要なので実際に受信する必要はありません。

ええ、わかっています。

>むしろ「POP before SMTP」をデフォルトONにしておく方がいいのではない
>でしょうか？

それでも良いかもしれないですね。

ありうるパターンとしては、
1) 単純な SMTP
2) POP before SMTP でユーザが理解していない
3) POP before SMTP でユーザが理解している

の程度で、3) のユーザが非常に少なく 2) のユーザが非常に多いです。
なので、デフォルト値は 1) ～ 3) のユーザが困らないような設定が好ましいです。

A) 送信 -> 受信, POP before SMTP off
B) 受信 -> 送信, POP before SMTP off
C) POP before SMTP on

のうち、A) の場合、つまり現在のデフォルトだけが、2) のユーザを
救うことができないことになり、トラブル量が多いといえます。

なので、デフォルトを B) にしてみては？という話だったのですが、
C) のほうが良い案かもしれないですね。

RE:00181 Message-IDについて

えるさん　01/04/02 09:16

>それに鶴亀が生成してくれないと、自分が送ったものを残しておいて
>もスレッド表示ができないのでは？

「自分が送ったメール」が「スレッド表示の対象」になりうるんですか？
少なくとも、それを受信した後じゃないとスレッド表示の対象にならない
から、(MTA が) Message-ID は存在しているように思います。

>>> ユーザ環境で常にまともな MessageID が生成できるとは思いませんので、
>というのは、要は鶴亀が環境によらずユニークなMessage-IDを生成で
>きればいいのでは？

そうですね、それが可能であれば全然問題はないのですが...今日のインター
ネット環境の現状では可能な範囲が限られてしまいます。
（このへんはなんとさんが記載されている URL にも書いてあります）

1) メーラ(MUA) が Message-ID を付与して問題がある内容が流れる
2) Message-ID を持たないメールが流れる

の２つを比較すると、Message-ID は Optional Field なので、2) は
ルールに反していませんが、1) は Message-ID の内容に関するルール
に反することになります。

あくまでインストール時のデフォルト値として、という意味で鶴亀で
は生成しないようにしておくほうが問題のない状態を提供しやすく
なるのではないか？といったところです。

現状の鶴亀はメールアドレスと内部で管理可能な値を利用した Message-Id
のようですが、メールアドレスの @ の右側がユニークな値としてリザーブ
された文字列を持っているとは限りません。
＃少なくとも、私が就職したことある会社はすべて NG

RE:00181 RFC2822

えるさん　01/04/02 09:30

>またこういった資料もあります。
>http://www.emaillab.org/essay/message-id.html#where

RFC2822 の話もありますね。
日本語で見たのは初めてかも（探してないからか）

鶴亀は新しい（最近の、という意味で）メーラなので、RFC2822 に
できるだけ準拠してあると良いかもしれませんね。

仕事で手がけたメーラは数百万円の売上は出たみたいですが、いつ
になってもサポートしそうにないです（笑）

RE:00179 まだインストールしてみただけなんですが

秀まるお2 さん　01/04/02 10:41

　えるさんどうも。

> [送受信][送信と受信の順番]

　一応、他のメールソフトでも普通送信が先だったと思うので、こうしておきます。

> [特別][鶴亀メールで MessageID を生成]

　Message-IDを鶴亀メール側で生成しないでおくと、送信したメールと受信したメー
ルのスレッド表示がうまくいかなくなるので、鶴亀側で生成しないとまずいです。

　Message-IDにメールアドレスが入ってしまう件（y.iidaさんの件）は、改良してみ
ます。

> Fcc ( 指定したメールフォルダに送信したメールを保存する )
> のほうが良い感じがするのですが。

　Fccってヘッダとして存在するのかどうか知りませんが、送信したメールを受信フ
ォルダ配下に振り分けるなら、一応「アカウント毎の設定・振り分け」で指定するこ
とが出来ます。（コピーするって動作は出来ないですけど）

> [テンプレート]
>
> 挿入ボタンを押したときのメニューが非常に大きいです。

　いろいろ追加してるうちに大きくなってしまいました。今はちゃんとヘルプも付い
ているので要らなさそうな物は削除してみます。

RE:00199 まだインストールしてみただけなんですが

Awaniko さん　01/04/02 12:01

Awaniko@沖縄島です

"秀まるお2"さん

秀まるお2<xxxxxxxxxx@maruo.co.jp> さんが
Mon, 02 Apr 2001 10:41:54 +0900 日に書かれた
<xxxxxxxxxxxxxx@maruo.co.jp>
hidesoft.8:00199| RE 00179 まだインストールしてみただけなんで
すがについて

>> [送受信][送信と受信の順番]
>
>　一応、他のメールソフトでも普通送信が先だったと思うので、こうしておきます。
悩むところですね。
実際の所、最近では SPAM メールやら悪戯対策のために、受信で認証
をしたあと一定時間送信可能としているところが多いというか、標準
的になってきているし....

「今まで」は、確かに送信がデフォルトで良かったのですが....

まぁ、何でもかんでもバカチョンにしてしまうと「なんでじゃ？」と
何でそうなのか？お勉強しないと言うか...そう言う人も増えるし
と、なるとデフォルトは今までの標準？送信後受信で、ちょっとお
勉強して貰うと言うのもいいかも。

2001/04/02(月) 11:55:36
M.Usui xxxxxxx@email.com
鶴亀メールVer1.02
-------------------------
沖縄島 OkinawaLifeML
http://form.easyml.com/easyml/okinawalife-c8.php3

RE:00190 Message-IDについて

なんと さん　01/04/02 12:33

> ネチケットやマナーの問題を含みますが（ここで議論する気はありません）
>
> MessageIDを引用する場合で（引用者が悪いとは一口に言いませんが）
> それにドンドン、レスがついてボクの発言じゃなくなっているのに
> いつの間にか、ボクが書いたようになって、そのまま引用され続けて、
> あげくの果てには、ＤＭまで来る始末で・・。

うむむ。それはお疲れさまなことでしたとは思うんですが、たとえば
Fromアドレス部分の引用が独り歩きしても同様の問題になるわけで。
ある意味、マナー・ネチケットのせいにするしかないと思うんですが。

でも秀まるおさんが対処してくださりそうで(^^)

RE:00194 Message-IDについて

なんと さん　01/04/02 12:33

なんとです。

> 「自分が送ったメール」が「スレッド表示の対象」になりうるんですか？

メーリングリストに投げたメールだけじゃなくって、個人対個人でや
りとりしている時に、こちらで送信済みのメールと相手からの返信を
同じフォルダに入れて、スレッド表示にしたりしますよね。

> 少なくとも、それを受信した後じゃないとスレッド表示の対象にならない
> から、(MTA が) Message-ID は存在しているように思います。

ちょっとこれは意味不明なんですが、えるさんのところではたまたま
MTAがMessage-IDを付けてくれるのですが（付けてくれるものの方が
まだ多いようですが）、そうでないところもあるってことで。

> 1) メーラ(MUA) が Message-ID を付与して問題がある内容が流れる
> 2) Message-ID を持たないメールが流れる
>
> の２つを比較すると、Message-ID は Optional Field なので、2) は
> ルールに反していませんが、1) は Message-ID の内容に関するルール
> に反することになります。

問題があるというのは、「ユニークでない」ということだと考えてよ
ろしいですか？だとすると
・現在の鶴亀の生成法でも同一Message-IDを生成してしまう可能性は
ほぼ無いに等しい
・違うマシンで同一Fromアドレスを使って同一時刻にメールを発信し
た時に、同一Message-IDを作ってしまう可能性はあるが、これだっ
てかなりの小確率。
・仮に重なっても、現実問題としてはあまり問題にならない（あまり
いい考え方じゃないですけど）
・それよりも、手元のメールにMessage-IDがないと、最初に書いたよ
うな状況の場合、不便。特に初心者ユーザーから「スレッドがつな
がりません」という質問が相次ぐ可能性がある。
という理由で、やっぱりMessage-IDは付けるべきだと思います。

RE:00208 まだインストールしてみただけなんですが

ながさわ さん　01/04/02 14:58

こんにちは、長澤です。

>実際の所、最近では SPAM メールやら悪戯対策のために、受信で認証
>をしたあと一定時間送信可能としているところが多いというか、標準
>的になってきているし....

受信で認証ではありません、POPサーバで認証です。受信動作をするか否かは別です。
従って「送信が先云々」と「POP BEFORE SMTP」は関係ありません。

>と、なるとデフォルトは今までの標準？送信後受信で、ちょっとお
>勉強して貰うと言うのもいいかも。

何を勉強するんですか？

RE:00226 まだインストールしてみただけなんですが

Awaniko さん　01/04/02 15:11

M.Usui@沖縄島です。

[ ながさわ <xxxxxxxxxx@maruo.co.jp> ] さんが
[ Mon, 02 Apr 2001 14:58:48 +0900 ] に書かれた
[ hidesoft.8:00226| RE 00208 まだインストールしてみただけなんですが ] について

> 受信で認証ではありません、POPサーバで認証です。受信動作をするか否かは別です。
> 従って「送信が先云々」と「POP BEFORE SMTP」は関係ありません。
どうも失礼しましたね。
単純に、受信を行うためにサーバーに ID/PASS を必要とし
ID/PASS があっている→正式なアクセスと認めて送信もOK。

> 何を勉強するんですか？
解らなくて聞いている？馬鹿にして聞いている？
先の文面からは、解らなくてとは思えませんけど。
なんで、送信できない？とか、どうして受信後じゃないと送信でき
ないの？等です。

2001-04-02 15:01 JST
M.Usui xxxxxxx@email.com

RE:00227 まだインストールしてみただけなんですが

ながさわ さん　01/04/02 16:36

こんにちは、長澤です。

すみません、どーも文章表現が拙くて、勘ぐらせてしまいました。

>> 何を勉強するんですか？
>解らなくて聞いている？馬鹿にして聞いている？

『勉強なんか、果たして必要ですか？』ってことでした。
フールプルーフで、他人の迷惑にならない、且つそこそこ使える設定になっていれば、
それでいいんじゃないですか？　それで物足りなさを感じたり、いろいろ深く探って
みようとしたヒトが勉強すればいいと思います。
つまずいている状態から勉強するのは、大変敷居が高くストレスがあるものです。は
じめっから『勉強しよう！』と思っているならば、それらはかなり低くなるでしょう
けど。
そのストレスを強要することは、SEとしては避けたいところですし、ストレスを如何
に軽減させるかも、SEの腕の見せ所の一つです。

あと、フールプルーフでない場合は『他人に迷惑を掛けることも考えられる』という、
非常に大きなデメリットがあります。

てなワケで、勉強を強要させるのは反対です。

……ってことを言いたかったのです。

RE:00227 まだインストールしてみただけなんですが

秀まるお2 さん　01/04/02 16:45

　なんか話が変な方向に行ってますが、どっちにしても、

POP before SMTPを知らない人が、たまたまうまく受信できることを期待する
ために「受信が先」がいい。

　という話は無しとさせていだだきます。（もともとそういう要望だったかどうかも
別として）

　ちなみにうちのプロバイダー（mitene）では、プロバイダーの用意するアクセスポ
イントにダイヤルアップしてないと送信できないというセキュリティです。

　将来的にはESMTPを使う方向に行くとは思いますけど。

RE:00208 まだインストールしてみただけなんですが

こにさん　01/04/02 23:39

こにです。

鶴亀とはまったく関係ないことですが。

> まぁ、何でもかんでもバカチョンにしてしまうと「なんでじゃ？」と

これは差別用語ですから、やめてほしいです。

RE:00254 まだインストールしてみただけなんですが

Awaniko さん　01/04/03 07:22

M.Usui <xxxxxxx@email.com>@沖縄島です。

"こに" さんおはようございます。

こに<xxxxxxxxxx@maruo.co.jp>さんが
2001/04/02に書かれた
<xxxxxxxxxxxxxx@maruo.co.jp>
hidesoft.8:00254| RE 00208 まだインストールしてみただけなんで
すがについて

>こにです。
>鶴亀とはまったく関係ないことですが。
>> まぁ、何でもかんでもバカチョンにしてしまうと「なんでじゃ？」と
>これは差別用語ですから、やめてほしいです。

そう言うからには、「こういう事」と具体的に意味を述べて頂いた方
が説得力があると思いますが。

「ちょん」自体には実は民族差別の意味はないのですが「ちょん」と
いう言葉には、「知恵が少し足りないこと」という古くからの意味が
あり元々はそういう意味での「チョン」で、これが別な意味の「チョ
ン」にすり替えられたようですけど。

とらえようじゃないですかね？

2001/04/03(火) 07:14:33
M.Usui e-mail: xxxxxxx@email.com
鶴亀メール Ver1.02
------------
沖縄島 OkinawaLifeML
http://form.easyml.com/easyml/okinawalife-c8.php3

RE:00257 まだインストールしてみただけなんですが

秀まるお2 さん　01/04/03 09:07

　なんかまた話がそれてますけど、僕自身は「バカチョン」を差別用語だとは知りま
せんでした。

　昔、僕が「秋葉原を徘徊した」と書き込んだら、「徘徊という言葉を差別的意味で
言っているのですか？」と指摘されたことがありました。「徘徊する」というのはマ
ニアの間では普通に使われてる言葉だったと思うんですが、老人介護で苦労してる人
が見た場合にはきつい言葉だったようです。

　あと、とあるセミナーで、僕がコンピュータ関係の仕事をしてると言ったら、「な
んだ、お前はコンピューター人間か」と言い返されたことがあって、とてもショック
に思ったことがあります。

RE:00258 まだインストールしてみただけなんですが

マイケル2 さん　01/04/03 09:25

マイケル2です。

秀まるお2さんの今朝 9時 7分の
“RE 00257 まだインストールしてみただけなんですが”について：
====

>　なんかまた話がそれてますけど、僕自身は「バカチョン」を差別用語だとは知りま
>せんでした。

言葉ってのは、その使われるシチュエーションにより違ってくると
思います。言葉の言い換えより、その人の持ってる意識や受け取る
側の意識の問題なんかなぁ。
僕も、そういうつもりじゃなく、不用意な書きかたして怒られたこ
とがあるけど…。

そうそう、以前、言葉遣いの問題でとっちめられて「俺はもう書か
ん」と筆を折った作家がいましたねぇ。

関係ないけど、その昔、“貴様”ってのは“貴殿”と同じ意味で
“あなた”より丁寧な言い方だと思ってた。(笑)

---
Miguel Thomas Lopez-Cai
TuruKame Ver.1.02

RE:00262 まだインストールしてみただけなんですが

きいろいまふらあ さん　01/04/03 11:15

逸れまくりでなんですが。

> 関係ないけど、その昔、“貴様”ってのは“貴殿”と同じ意味で
> “あなた”より丁寧な言い方だと思ってた。(笑)

もともとそう（敬称）だったんだと今でも思っています。
「ぼく（僕）」は謙譲の意味があるとかね。

RE:00258 まだインストールしてみただけ

山紫水明 さん　01/04/03 11:17

　秀まるお2さん，マイケル2さん，こんにちは。

》　なんかまた話がそれてますけど、僕自身は「バカチョン」を差別用語だとは知
》りませんでした。

　チョンというのは元々「チョンガー」という意味だということです。
で，「チョンガー」は広辞苑によれば，

(朝鮮語ch'onggakの転)
(1)朝鮮の丁年過ぎの独身男子の蔑称べつしよう。もと髪型の名称で、丁年未満
の男子は、結髪せず冠を着けず、髪を後ろに編みさげる風習があった。
(2)俗に、独身の男。

　従って，「バカチョン」というのは，かつて，日本が朝鮮を植民地支配してい
た時代に「馬鹿と朝鮮人男」，あるいは「馬鹿な朝鮮人男」という意味でもとも
と使われたと聞いています。（こう書くこと自体抵抗がありますが，やはり，こ
ういうことは知っておくべきであり，知っている人は，伝えるべきだと思い，敢
えて書きました。）
　私はこの話を聞いて以後，使わなくなりました。
　もし間違っていたらどなたかご教示ください。

　「徘徊」とか「コンピューター人間」いうような言葉とはちょっと違う種類の
言葉だと思います。

　では，　(^^)/~
山紫水明

RE:00267 皆様申し訳ありません。

Mattz さん　01/04/03 11:23

鶴亀メールとは全く関係ない話でごめんなさい。
これ以上そらすのも心が痛むのですが「貴様」と聞くと
黙ってられなくて……。

http://www.wind.co.jp/sennen/kissama.html
世界貴様統一協会

RE:00212 Message-IDについて

シオさん　01/04/06 12:58

>> ネチケットやマナーの問題を含みますが（ここで議論する気はありません）
>>
>> MessageIDを引用する場合で（引用者が悪いとは一口に言いませんが）
>> それにドンドン、レスがついてボクの発言じゃなくなっているのに
>> いつの間にか、ボクが書いたようになって、そのまま引用され続けて、
>> あげくの果てには、ＤＭまで来る始末で・・。
>
>うむむ。それはお疲れさまなことでしたとは思うんですが、たとえば
>Fromアドレス部分の引用が独り歩きしても同様の問題になるわけで。
>ある意味、マナー・ネチケットのせいにするしかないと思うんですが。
>
>でも秀まるおさんが対処してくださりそうで(^^)

DMが来るのは嫌ですね。
MessageIDに使用しているメアドの部分を
暗号化はできないでしょうか？＞秀まるおさん
これならユニークなIDが生成できそうなものです。
ただしRFCは読んでいないのでそのようにしても
よいのかどうかはわかりません。

p.s.
最近のサポートフォーラムは活発で読み切れない記事が
いっぱいです。

RE:00389 Message-IDについて

秀まるお2 さん　01/04/06 15:25

> MessageIDに使用しているメアドの部分を
> 暗号化はできないでしょうか？＞秀まるおさん

　その後、Message-ID部分の生成処理を見直してはみたんですけど、暗号化まではし
てません。あまり派手に変更しようとすると、文字列が長くなりすぎて良くないと思
うし、長くならないようにすると、今度は「固有でなければならない」という条件に
合わなくなる可能性が出てきてしまいます。

　一応、メールアドレスが盗まれるようなことは無いようにしますけど。

RE:00397 Message-IDについて

ひろさん　01/04/13 12:08

　秀まるおさん今日は、ひろです。
> 　一応、メールアドレスが盗まれるようなことは無いようにしますけど。
　この意味で今回の変更は、ちょっと中途半端な印象があります。ユニーク
な文字列を生成しなければならないので、難しいとは思いますが、再度検討
頂ければ幸いです。

　今まで私が見た例では、Message-ID の @ の後に使用しているコンピュー
タ名や、SMTP サバー名を付加している場合がありましたが、これも反って
使用環境を知らせてしまう結果となりかねない欠点があります。

　秀Term の %HIDENETPASSWORD, %NIFPASSWORD, %LASTLOGDATE で使用して
いるのと同じ様な処理 (同じでは秀Term を使うと簡単に分かってしまう(^^))
を使って、@ より前の部分全体を暗号化することで、ユニークにはならない
でしょうか? ひょっとすると、たとえユニークになっても、Message-ID で
は使用してはいけない文字列が出てきてしまうのかな?

　どなたか何か良い案はありませんか?

RE:00397 Message-IDについて

Kengo さん　01/04/13 12:54

> 　その後、Message-ID部分の生成処理を見直してはみたんですけど、暗号化まではし
> てません。あまり派手に変更しようとすると、文字列が長くなりすぎて良くないと思
> うし、長くならないようにすると、今度は「固有でなければならない」という条件に
> 合わなくなる可能性が出てきてしまいます。
>
> 　一応、メールアドレスが盗まれるようなことは無いようにしますけど。

http://hidemaru.xaxon.co.jp/software/tkhist.html
> 2001/4/12 V1.02 -> V1.03
> ・Message-ID:部分にメールアドレスがそのまま入らないように工夫した。
> 　（スパムメールの対象とならないようにするため）

って、

| Message-Id: <1xxxxxxxxxxxxxx@yyyyyy.co.jp7>

のように、「最後に数字を付ける」ってことですか？
＃他にもあるかもしれませんが。

機械的にメールアドレスを収集するようなソフトからは
「メールアドレスではない」と判断されるかもしれませんが、
人間が見たらすぐわかるような気がします。
＃それ以前に、そのようなソフトは、メールアドレスの前の
＃ランダムな文字列をちゃんとハネてくれたりするんでしょうか？

なんか、この対策ではあまり意味がないように思います。
それに、@の右がFQDNではなくなってしまうのもイヤですねぇ。
＃ユニーク性には変わりないでしょうが。

@の左、xxxxxを暗号化(?)する方がいいんじゃないでしょうか。
長くなりすぎるのも確かに困るでしょうが、アルファベット
(数字も？)をローテイトするとか。
＃IBM→HAL みたいに。
＃＃あ、ぶつかるか。それじゃぁ。

RE:00838 Message-IDについて

秀まるお2 さん　01/04/13 14:50

> 　この意味で今回の変更は、ちょっと中途半端な印象があります。

　僕も中途半端だろなぁとは思いつつも、とりあえずスパムメールを送る業者が自動
で抽出できなければそれでいいかなぁと思って今の仕様にしました。

　下手に文字列を長くしないで、しかも元のアドレスが分からなくて、しかも固有で
なければないないってのがなかなか難しいです。

　何かいい案があったら教えてください。

RE:00856 Message-IDについて

"y.iida" さん　01/04/13 15:15

>　下手に文字列を長くしないで、しかも元のアドレスが分からなくて、
> しかも固有でなければないないってのがなかなか難しいです。
>
>　何かいい案があったら教えてください。

頭13Byteはどうやって求めているのでしょうか？
アカウント情報を利用するのが安易だと思うので、
@を取ってからAccount.binに書かれているように暗号化して、
日付と時間を足すなどかしら・・？？

一瞬、MACアドレスでいけるんと思ったけどLANだけだしなぁ(^^;;;
固有とは難しいです。

RE:00397 Message-IDについて

Kengo さん　01/04/13 16:29

> 　一応、メールアドレスが盗まれるようなことは無いようにしますけど。

環境はWin98/1.06です。

鶴ビューワの上にファイルをドロップすると、そのファイルを
添付ファイルとした新規メールが亀エディタで開きます。
(この動作は仕様でしたっけ？それはともかく)

この時に生成されるMessage-IDは、旧形式に近く、メールアドレスが
そのまま含まれています。

| Message-Id: <xxxxxxxxxxxxxx@yyyyyy.co.jp>
という感じ。

頭に'c'が付いているので「まったく同じ」でもないんですけど。

私自身は「アドレスが含まれても構わない」し、Message-IDを
付けてくれるサーバーを使っているので、単なる報告です。

RE:00856 Message-IDについて

ひろさん　01/04/13 17:56

　秀まるおさん今日は、ひろです。
> 　僕も中途半端だろなぁとは思いつつも、とりあえずスパムメールを送る業者が自動
> で抽出できなければそれでいいかなぁと思って今の仕様にしました。 ^^^^
^^^^^^^^^^^^^^^^^^
という観点なら、確かに効果はありますね。

> 　下手に文字列を長くしないで、しかも元のアドレスが分からなくて、しかも固有で
> なければないないってのがなかなか難しいです。
　秀Term の暗号化だと結構長くなりますね(^^;。

> 　何かいい案があったら教えてください。
　暗号化技術に詳しい方はいらっしゃいませんか? (他力本願)

RE:00865 Message-IDについて

秀まるお2 さん　01/04/14 13:22

> この時に生成されるMessage-IDは、旧形式に近く、メールアドレスが
> そのまま含まれています。

　たしかにそこの処理は古いまま、というよりは、そもそもMessage-IDを生成する処
理が２つに分かれてること自体がおかしかったです。さっそく修正させていただきま
す。