From: yamaoka Date: Tue, 8 Nov 2005 12:38:47 +0000 (+0000) Subject: Fix translations. X-Git-Tag: ngnus-0_4-doc-ja~92 X-Git-Url: http://git.chise.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b8b885ac1542395c9f394da689efd87e1b7b0a29;p=elisp%2Fgnus-doc-ja.git Fix translations. --- diff --git a/gnus-ja.texi b/gnus-ja.texi index 6cbf161..d20cb90 100644 --- a/gnus-ja.texi +++ b/gnus-ja.texi @@ -22449,23 +22449,27 @@ Gnus はスコア付け、スレッドの形成、およびスレッドの比較などを行なうとき @cindex UCE @cindex unsolicited commercial email -ここ最近の USENET では、宣伝のハゲタカどもが、彼らの詐欺や製品を押し付け -るための電子メールアドレスを探そうとして、気違いのようにニュース上をうろ -ついて grep しまくっています。これに対する反動として、多くの人々 -が @code{From} 行に無意味なアドレスを入れはじめるようになってしまいまし -た。これは非生産的なことだと私は思います---あなたが書いたことに対する返 -信として正当なメールを送ることを面倒にさせ、また誰が書いたものなのかを分 -かりづらくします。こんな書き換えは結局は、押し付け宣伝メールそれ自身より +ここ最近の USENET では、宣伝のハゲタカどもが彼らの詐欺や製品を押し付ける +ための電子メールアドレスを探そうとして、気違いのようにニュース上をうろつ +いて grep しまくっています。これに対する反動として、多くの人々が無意味な +アドレスを @code{From} 行に入れはじめるようになってしまいました。私はこ +れは逆効果を招くと思います---あなたが書いたことに対する返信として人々が +正当なメールを送ることを面倒にさせるだけでなく、誰が書いたものなのかを分 +かりづらくします。こんな書き換えは、結局は押し付け宣伝メールそれ自身より も大きな脅威となるかもしれません。 私にとっての spam メールの最大の問題は、嘘の口実で入ってくるからです。私 -が @kbd{g} を押したとすると、Gnus は十通の新着メールがありますと陽気に私 -に教えてくれます。私は「おおっ、わーい! 僕って幸せ!」と言ってメールグルー -プを選択します。しかしそこには、二つのネズミ講と、七つの広告 (「最新! 奇 -跡の増毛トニック、ふさふさでつやつやの髪を、あなたのつま先まで!」) と、 -悔い改め神を信じよ、という一つのメールがあるだけなのです。 +が @kbd{g} を押すと、Gnus は十通の新着メールがありますと陽気に私に教えて +くれます。私は「おおっ、わーい! 僕って幸せ!」と言ってメールグループを選 +択します。しかしそこには、二つのネズミ講と、七つの広告 (「最新! 奇跡の育 +毛トニック、ふさふさでつやつやの髪をあなたのつま先(※)に!」) と、悔い改 +め神を信じよ、という一つのメールがあるだけなのです。 -これは不愉快です。あなたがそれに関してできることがあります。 +これは迷惑千万です。あなたがそれに関してできることがあります。 + +@quotation +訳注※: ホビット族用の育毛トニック。たぶん。 +@end quotation @menu * The problem of spam:: 背景、そして解決 @@ -22498,25 +22502,25 @@ Commercial E-mail---望まれない商用電子メール---の頭文 Spam は種々さまざまな出どころからやって来ます。有用なメッセージを捨てず にすべての spam を単に始末することは不可能です。良い例は TMDA (訳注: 送 -信する度にユニークなアドレスを使う) システムで、それはあなたが知らない送 -信者に、彼らの電子メールが届く前に彼らが正当な送信者であることの確認を求 -めます。正当な出どころからの電子メールが TMDA システムによってそれらの出 -どころが確認できない、または行なわれない場合は捨てられてしまうかもしれな -いというマイナス面は、TMDA の技術的な側面に立ち入らなくても明白です。も -う一つの TMDA の問題は、電子メールの配送と処理への基本的な理解を利用者に -求めていることです。 +信する度にユニークなアドレスを使う) システムで、それは、あなたが知らない +送信者からの電子メールがあなたのもとに届くことができる前に、彼らに対して +彼ら自身が正当な送信者であることの確認を求めます。正当な出どころからの電 +子メールが、それらの出どころが TMDA システムを通して確認できない、または +行なわれない場合は捨てられてしまうかもしれないというマイナス面は、 +TMDA の技術的な側面に立ち入らなくても明白です。もう一つの TMDA の問題は、 +電子メールの配送と処理への基本的な理解を、利用者に求めていることです。 Spam の除去 (filtering) への最も単純な取り組みは、メールサーバーで、ある いは入ってきたメールを分類するときに濾過すること (filtering) です。毎 日 @samp{random-address@@vmadmin.com} から 200通の spam メッセージを受け -取るのならば、@samp{vmadmin.com} を阻止すればよろしい。 -@samp{バイアグラ} に関するメッセージを 200通受け取るのならば、 -@samp{バイアグラ} を含むすべてのメッセージを捨ててしまえばよろしい。例え -ばブルガリアからたくさんの spam がやって来るのならば、ブルガリアの IP か -ら来るすべてのメールを濾過すればよろしい。 +取るのならば、@samp{vmadmin.com} を阻止すれば良いでしょう。「バイアグラ」 +に関するメッセージを 200通受け取るのならば、「バイアグラ」を含むすべての +メッセージを捨ててしまえば良いでしょう。例えばブルガリアからたくさんの +spam がやって来るのならば、ブルガリアの IP から来るすべてのメールを濾過 +すれば良いでしょう。 これは、残念ながら正当な電子メールを捨てるためのすぐれた方法です。あなた -に接触しようとする国 (ブルガリア、ノルウェー、ナイジェリア、中国、等) 全 +に連絡しようとする国 (ブルガリア、ノルウェー、ナイジェリア、中国、等) 全 体、または大陸 (アジア、アフリカ、ヨーロッパ、等) さえも封じ込めてしまう 危険は明らかなので、あなたに選択権があるのならば、そんなことはしないで下 さい。 @@ -22533,35 +22537,35 @@ Clearinghouse---@uref{http://www.rhyolite.com/anti-spam/dcc/}) がそのよ が、ガーナ、エストニアあるいはカリフォルニアにあるマシ ン @var{X} が spam 電子メールを送出していることを認めたら、それ ら @var{N} 個のシステムは @var{X} または @var{X} からやって来た spam メー -ルをデータベースに記入します。Spam 検出の基準は変わります。それは送られ -たメッセージの数やメッセージの内容などであるかもしれません。メッセージ -が spam かどうかを分散処理システムの利用者が知りたい場合、彼はそれら -の @var{N} 個のシステムのうちの一つを調べます。 - -分散型 spam 処理は同時に多くのメッセージを送る spammers と非常によく戦っ -てくれますが、それは利用者がかなり複雑なチェックを設定することを求めます。 -商用と、フリーな分散型 spam 処理システムがあります。分散型 spam 処理は、 -それ自体の危険もはらんでいます。例えば、正当な送信者が spam を送ったかど -で非難され、彼らのウェブサイトやメーリングリストがその事件のために暫くの -間閉鎖されてしまう、とか。 - -Spam 濾過への統計的な取り組みもまた普及しています。それは過去の spam メッ -セージの統計分析に基づいています。通常その分析は、おそらく単語の対か三つ -の単語の組合せの合成による、単語の出現頻度の単純な計数です。Spam の統計 -分析はほとんどの場合にとてもよく働くのですが、時として正当な電子メール -を spam として分類してしまうことがあります。分析には時間がかかります。す -べてのメッセージを分析しなければなりません。そして利用者は spam を分析す -るためのデータベースを用意しなければなりません。サーバーでの統計分析は人 -気を得ています。これには、利用者は単にメールを読めば良いという長所と、し -かしサーバーにそれが過ってメールを分類したことを伝えるのが困難だという短 -所があります。 +ルをデータベースに記入します。Spam 検出の基準は一様ではありません。それ +は送られたメッセージの数やメッセージの内容などであるかもしれません。メッ +セージが spam かどうかを分散処理システムの利用者が知りたい場合、彼はそれ +らの @var{N} 個のシステムのうちの一つを調べます。 + +分散型 spam 処理は一度にたくさんのメッセージを送る spammers と非常によく +戦ってくれますが、それには利用者がかなり複雑なチェックを設定することが必 +要です。商用とフリーな分散型 spam 処理システムがあります。分散型 spam 処 +理は、それ自体の危険もはらんでいます。例えば、正当な送信者が spam を送っ +たかどで非難され、彼らのウェブサイトやメーリングリストがその事件のために +暫くの間閉鎖されてしまう、とか。 + +Spam の濾過への統計的な取り組みもまた普及しています。それは過去 +の spam メッセージの統計的な分析に基づいています。通常その分析は、おそら +く単語の対か三つの単語の組合せの合成による、単語の出現頻度の単純な計数で +す。Spam の統計分析はほとんどの場合にとてもよく働くのですが、時として正 +当な電子メールを spam として分類してしまうことがあります。分析には時間が +かかります。すべてのメッセージを分析しなければなりません。そして利用者 +は spam を分析するためのデータベースを蓄えなければなりません。サーバーで +の統計分析は人気を得ています。これには、利用者は単にメールを読めば良いと +いう長所と、しかしサーバーにそれが過ってメールを分類したことを伝えるのが +困難だという短所があります。 余人の言を待たずとも、spam との戦いは楽ではありません。ママからの電子メー ルとバイアグラ広告を区別する魔法のスイッチはありません。人々は 非-spam と spam を区別するのに手を焼いているというのに。それは、 spammers が懸命にそれらをママだと思わせようとしているのが本質だからです。 Spamming は、世界が彼らに恩義があると思っている人々の一団からの、腹立た -しく、無責任で、ばかげた行為です。以下の各項が spam なる疫病との戦いの助 +しく、無責任で、ばかげた行為です。以下の各章が spam なる疫病との戦いの助 けになることを望みます。 @node Anti-Spam Basics @@ -22574,21 +22578,21 @@ Spamming は、世界が彼らに恩義があると思っている人々の一団からの、腹立た Spam に対処する一つの方法は、Gnus にすべての spam を @samp{spam} メール グループに分離させてしまうことです (@pxref{Splitting Mail})。 -最初に、あなたに到達性のある正しいメールアドレスを一つ選び、それをすべて -のあなたのニュース記事の @code{From} ヘッダーに入れます。(ここで -は @samp{larsi@@trym.ifi.uio.no} を選びましたが、 -@samp{larsi+usenet@@ifi.uio.no} 形式のたくさんのアドレスの方が良い選択で -す。あなたのサイトの sendmail の設定がメールアドレスのローカル部としてど -んなキーワードを受け付けるかは、あなたのサイトのシステム管理者に聞いて下 -さい。) +最初に、あなたに連絡することができる正しいメールアドレスを一つ選び、それ +をすべてのあなたのニュース記事の @code{From} ヘッダーに入れましょう。(こ +こでは @samp{larsi@@trym.ifi.uio.no} を選びましたが、 +@samp{larsi+usenet@@ifi.uio.no} の形式のたくさんのアドレスの方が良い選択 +です。あなたのサイトの sendmail の設定がメールアドレスのローカル部として +どんなキーワードを受け付けるかは、あなたのサイトのシステム管理者に聞いて +下さい。) @lisp (setq message-default-news-headers "From: Lars Magne Ingebrigtsen \n") @end lisp -そして @code{nnmail-split-fancy} に以下の分離規則を入れま -す (@pxref{Fancy Mail Splitting})。 +そして @code{nnmail-split-fancy} に以下の分割規則を入て下さ +い (@pxref{Fancy Mail Splitting})。 @lisp (... @@ -22599,18 +22603,18 @@ Spam に対処する一つの方法は、Gnus にすべての spam を @samp{spa ...) @end lisp -この意味は、このアドレスに届いたすべてのメールをまず疑いますが、 +この意味は、このアドレスに届いたすべてのメールが疑わしいが、 @samp{Re:} で始まる @code{Subject} が付いているか、@code{References} ヘッ ダーが付いていればおそらく OK だろう、ということです。残りはすべ -て @samp{spam} グループに行きます (このアイデアはおそらく Tim Pierce 氏 -によるものです)。 +て @samp{spam} グループに行きます。(このアイデアはおそらく Tim Pierce 氏 +によるものです。) これに加えて、多くのメール spam 屋は、あなたのところの @acronym{SMTP} サー -バーと直接話し、@code{To} ヘッダーにあなたのメールアドレスが明示されない -ようにします。なんでそんなことをするのかはわかりませんが---おそらく私た -ちの裏をかく機構の裏をかくためかな? どちらにしても、対処は簡単なことで -す---あなた宛てでないものを全部 @samp{spam} グループにいれるだけです。こ -れはお好み分離規則の最後にこんな風に入れることでできます。 +バーと直接話して、@code{To} ヘッダーにあなたのメールアドレスが明示されな +いようにします。なんでそんなことをするのかはわかりませんが---もしかした +ら、この裏をかく機構の裏をかくためかな? どちらにしても、対処は簡単なこと +です---特級分割規則を以下のように終端させることによって、あなた宛てでな +いものを全部 @samp{spam} グループに入れるだけです: @lisp ( @@ -22619,16 +22623,17 @@ Spam に対処する一つの方法は、Gnus にすべての spam を @samp{spa "spam") @end lisp -私の経験では、これで事実上すべてが正しいグループに分類されます。まあ、そ -れでもときどき @samp{spam} グループをチェックして、正しいメールがあるか -チェックしなくてはいけませんけどね。もしあなたは自分が良いネットワーク市 -民であると思っているなら、それぞれの押し付け宣伝メールの関係当局に苦情を -送り付けることさえもできます---暇なときにでもね。 +私の経験では、これで実質的にはすべてが正しいグループに分類されます。まあ、 +それでもときどき @samp{spam} グループをチェックして、正しいメールがある +かチェックしなくてはいけませんけどね。あなたが自分が良いネットワーク市民 +であると思っているなら、それぞれの押し付け宣伝メールの関係当局に苦情を送 +り付けることさえもできます---暇なときにでもね。 これで私のところでは動いています。これでみんなは簡単な方法で私に連絡を取 ることができ (普通に @kbd{r} を押すだけでできる)、私は spam に煩わされる -ことはまったくありません。得々状態です。私の意見としては、@code{From} ヘッ -ダーを偽造して存在しないドメインに送らせるのはキタナイです。 +ことはまったくありません。お互いに有利な状況です。私に言わせれば、 +@code{From} ヘッダーを偽造して存在しないドメインに送らせるのはすごく良く +ないです。 この手法には注意して下さい。Spammers はそれに気付いています。