diff options
22 files changed, 409 insertions, 258 deletions
diff --git a/fml/doc/ja/tutorial/customize/autoreply.sgml b/fml/doc/ja/tutorial/customize/autoreply.sgml index fd3eba50..e3eb5607 100644 --- a/fml/doc/ja/tutorial/customize/autoreply.sgml +++ b/fml/doc/ja/tutorial/customize/autoreply.sgml @@ -11,12 +11,14 @@ <para> 配送プロセス( /usr/local/libexec/fml/distribute )を改造し、 どんなときでも /some/where/help ファイルを送り返すことを考えます。 -たとえば help@fml.org ＭＬを作り、このアドレスにメールを送ると +たとえば help@fml.org ＭＬを作り、 +このアドレスにメールを送ると (うむをいわさず:-)ヘルプファイルを送り返すというものです。 </para> <para> -この場合 config.cf (e.g. /var/spool/ml/help/config.cf)の例は、 +この場合 +config.cf (e.g. /var/spool/ml/help/config.cf)の例は、 次のようになります。 <screen> article_post_restrictions = permit_anyone @@ -47,8 +49,8 @@ $curproc->stop_this_process(); <para> 正確には「身のある処理は何も実行されません」が、 -reply_message() メソッドでメッセージキューに入れられたメッセージを -送信する処理は行なわれるので、メッセージの送信は行なわれます。 +reply_message() メソッドで、 +メッセージキューに入れられたメッセージを送信する処理が行なわれます。 </para> diff --git a/fml/doc/ja/tutorial/customize/case_studies.sgml b/fml/doc/ja/tutorial/customize/case_studies.sgml index 693baaf6..e1cc8145 100644 --- a/fml/doc/ja/tutorial/customize/case_studies.sgml +++ b/fml/doc/ja/tutorial/customize/case_studies.sgml @@ -9,9 +9,16 @@ </title> <para> -以下の設定を /usr/local/etc/fml/site_default_config.cf に書き、全ＭＬ -に反映させてください。このファイルに設定を書けば、今あるＭＬも今後作る -すべてのＭＬも同じ仕様になります。 +会社などでは、 +共通の設定をオフィスの全メーリングリストに適用したい需要があります。 +そういった想定でのカスタマイズ例です。 +</para> + +<para> +以下の設定を /usr/local/etc/fml/site_default_config.cf に書き、 +全ＭＬに反映させてください。 +このファイルに設定を書けば、 +今あるＭＬも今後作るすべてのＭＬも同じ仕様になります。 </para> <para> @@ -42,13 +49,14 @@ outgoing_mail_header_x_ml_name = office#$ml_name <screen> article_post_restrictions = permit_anyone </screen> -この例では root さんからのシステムメールなども許していることに注意して -ください(root などシステムからのメールを弾きたい場合は -reject_system_accounts permit_anyone です)。 +この例では +root さんからのシステムメールなども許していることに注意してください +(root など特別なシステムアカウントからのメールを弾きたい場合は +reject_system_accounts permit_anyone を追加してください)。 </para> <para> -そして、「社内用途のＭＬなのでフィルタの多くは不要」です。 +そして「社内用途のＭＬなのでフィルタの多くは不要」です。 正確には「フィルタを使うと問題だらけ」になります;) <screen> use_article_filter = no @@ -65,7 +73,8 @@ use_article_text_plain_filter = no <para> 記事のスプールを考えます。 -仕事のメールは数が多いので、長期的な展望をふまえるなら、 +仕事のメールは数が多いので、 +長期的な展望をふまえるなら、 数万通単位で記事を保存するという仮定が必要です。 よって、記事のスプールは subdir 形式としました。 <screen> @@ -78,11 +87,17 @@ spool_type = subdir <screen> use_command_mail_function = no </screen> -コマンドメールそのものを禁止するには、aliases から該当するエントリを省 -くことが確実ですが、ＭＬを作成するたびに、aliases から削除することはミ -ス操作を誘い易いでしょう。また、CGI 操作の場合、CGI 操作者が aliases -の細かな操作をするのは難しいです。そこで、コマンドメール用のプログラム -が一度は起動しても、すぐ終るという設定にしているわけです。 +コマンドメールそのものを禁止するには、 +aliases から該当するエントリを省くことが確実ですが、 +ＭＬを作成するたびに、 +aliases から削除することはミス操作を誘い易いでしょう。 +また、CGI 操作の場合、 +CGI 操作者が aliases の細かな操作をするのは難しいです。 +そこで、 +まんがいち、 +コマンドメールを受け取ったとしても、 +「コマンドメール用のプログラムが起動して即座に終了する」 +設定にしています。 </para> </sect1> @@ -94,9 +109,16 @@ use_command_mail_function = no </title> <para> -以下の設定を /usr/local/etc/fml/site_default_config.cf に書き、全ＭＬ -に反映させてください。このファイルに設定を書けば、今あるＭＬも今後作る -すべてのＭＬも同じ仕様になります。 +会社などでは、 +共通の設定をオフィスの全メーリングリストに適用したい需要があります。 +そういった想定でのカスタマイズ例です。 +</para> + +<para> +以下の設定を /usr/local/etc/fml/site_default_config.cf に書き、 +全ＭＬに反映させてください。 +このファイルに設定を書けば、 +今あるＭＬも今後作るすべてのＭＬも同じ仕様になります。 </para> <para> @@ -132,5 +154,12 @@ $command_verify_request_end_hook = q{ </screen> </para> +<para> +追記: +ちなみに +IO::Adapter で PCRE が使えるので、 +それを使う方が楽です。 +</para> + </sect1> diff --git a/fml/doc/ja/tutorial/customize/chapter.command.sgml b/fml/doc/ja/tutorial/customize/chapter.command.sgml index a2f251f0..43694af1 100644 --- a/fml/doc/ja/tutorial/customize/chapter.command.sgml +++ b/fml/doc/ja/tutorial/customize/chapter.command.sgml @@ -19,16 +19,18 @@ elena ＭＬに独自の help コマンドを作ることを考えます。 </para> <para> -独自の help コマンドは、独自のモジュール help.pm を用意して、ＭＬロー -カルのライブラリパスへおくだけで OK です。 +独自の help コマンドは、 +独自のモジュール help.pm を用意して、 +ＭＬローカルのライブラリパスへおくだけで OK です。 同じ名前のモジュール（つまり同じコマンド)でも、 -サーチパスの優先順位にしたがって、この独自モジュールのほうが使われます。 +サーチパスの優先順位にしたがって、 +この独自モジュールのほうが使われます。 </para> <para> -モジュールは、オリジナルの help.pm を参考にして、 -独自の help.pm を作りってください。 -そして、以下のパスにおいてください。 +モジュールは、 +オリジナルの help.pm を参考にして、 +独自の help.pm を作り、以下のパスに置いてください。 <screen> 例: elena ＭＬの場合 diff --git a/fml/doc/ja/tutorial/customize/chapter.config.sgml b/fml/doc/ja/tutorial/customize/chapter.config.sgml index 7997f4f3..ce6cd7ec 100644 --- a/fml/doc/ja/tutorial/customize/chapter.config.sgml +++ b/fml/doc/ja/tutorial/customize/chapter.config.sgml @@ -15,7 +15,9 @@ </title> <para> -設定を /usr/local/etc/fml/site_default_config.cf に書いて下さい。 +設定を +/usr/local/etc/fml/site_default_config.cf +に書いて下さい。 フォーマットは .cf 形式、つまり config.cf と同様です。 </para> @@ -41,15 +43,15 @@ </question> <answer> - <para> - 全部の変数を表示する +<para> +全部の変数を表示するには <screen> % /usr/local/bin/fmlconf elena </screen> - </para> +</para> - <para> - デフォルト値と異なる変数を表示する +<para> +デフォルト値と異なる変数を表示するには <screen> % /usr/local/bin/fmlconf -n elena </screen> diff --git a/fml/doc/ja/tutorial/customize/chapter.message.sgml b/fml/doc/ja/tutorial/customize/chapter.message.sgml index 6c98e22d..aad295e4 100644 --- a/fml/doc/ja/tutorial/customize/chapter.message.sgml +++ b/fml/doc/ja/tutorial/customize/chapter.message.sgml @@ -30,8 +30,9 @@ elena ML (ML のホームが /var/spool/ml/elena)の場合、 <para> 補足: -各関数の中では「_arg_変数名」に値を入れてハッシュをメッセージ生成関数へ -渡します。 +各関数の中では +「_arg_変数名」 +に値を入れてハッシュをメッセージ生成関数へ渡します。 そして、メッセージ内では「$_arg_変数名」という特殊な変数名を使い、 それを渡されたハッシュの値で置換したものが送り返されるメッセージです。 </para> diff --git a/fml/doc/ja/tutorial/customize/command_permit_anyone.sgml b/fml/doc/ja/tutorial/customize/command_permit_anyone.sgml index 4a2a7704..1522a5d4 100644 --- a/fml/doc/ja/tutorial/customize/command_permit_anyone.sgml +++ b/fml/doc/ja/tutorial/customize/command_permit_anyone.sgml @@ -9,8 +9,9 @@ </title> <para> -command_mail_restrictions はコマンドメールの利用を許すメンバーを定義してい -ます。 +変数 +command_mail_restrictions +はコマンドメールの利用を許すメンバーを定義しています。 <screen> command_mail_restrictions = permit_anyone </screen> @@ -18,8 +19,9 @@ command_mail_restrictions = permit_anyone </para> <para> -こんな設定していいのか？ -いつ使うんだ？というのはありますが、理論上、設定は可能です。 +こんな設定をしていいのか？ +いつ使うんだ？ +というのはありますが、理論上、設定は可能です。 </para> @@ -53,7 +55,7 @@ command_mail_restrictions = permit_anyone <question> <para> -システムアカウントを除き誰でもコマンドメールが使える +システムアカウントをのぞいて、誰でもコマンドメールが使える </para> </question> diff --git a/fml/doc/ja/tutorial/customize/command_rejectall.sgml b/fml/doc/ja/tutorial/customize/command_rejectall.sgml index 0deedcca..925aa1b7 100644 --- a/fml/doc/ja/tutorial/customize/command_rejectall.sgml +++ b/fml/doc/ja/tutorial/customize/command_rejectall.sgml @@ -14,15 +14,16 @@ </para> <para> -コマンドメールのプロセスが起動しても、即効で終了するようにすることがで -きます。これが(aliases を編集することをのぞけば)一番確実な方法です。 +コマンドメールのプロセスが起動しても、 +即座に終了するよう設定できます。 +これが(aliases を編集することをのぞけば)一番確実な方法です。 <screen> use_command_mail_function = no </screen> </para> <para> -プロセスが動いてしまうのですが、別解として次のやり方もアリでしょう。 +プロセスが動いてしまうのですが、別解として次の設定もアリでしょう。 <screen> use_command_mail_function = yes @@ -39,9 +40,11 @@ command_mail_restrictions = reject <para> 注: -この解答は「コマンドメールが使えないことを教えてあげる」ことを想定して -います。社内ＭＬなどでは、これで問題ないと思いますが、一般のＭＬでは、 -SPAM メールに対して応答してしまうため親切がアダになります。 +この解答は +「コマンドメールが使えないことを教えてあげる」 +ことを想定しています。 +社内ＭＬなどでは、これで問題ないと思いますが、 +一般のＭＬでは、SPAM メールに対して応答してしまうため親切がアダになります。 そこで、 &fml8; 2008/08/17 以降のバージョンでは isolate (SPAM の隔離)命令が推奨です。 <screen> diff --git a/fml/doc/ja/tutorial/customize/mailmagazine.sgml b/fml/doc/ja/tutorial/customize/mailmagazine.sgml index df2d17a3..fd5baabf 100644 --- a/fml/doc/ja/tutorial/customize/mailmagazine.sgml +++ b/fml/doc/ja/tutorial/customize/mailmagazine.sgml @@ -12,12 +12,13 @@ <warning> <para> ここではメールヘッダによる認証しか取り上げていませんが、 -安全のため、もっと厳しい設定をしてください。 +安全のため、もっと厳しい設定を検討してください。 </para> <para> -たとえば、そもそもインターネット側に SMTP インターフェイスがないような -サーバの設定、およびサーバの設置場所の選定などを行なうべきです。 +たとえば、 +そもそもインターネット側に SMTP インターフェイスがないようなサーバの設定、 +およびサーバの設置場所の選定などを行なうべきです。 </para> <para> @@ -25,7 +26,8 @@ fml8 単体で処理できる <link linkend="config.post.check.pgp"> PGP 認証 </link> -が理想ですが、この場合、 +が理想ですが、 +この場合、 メールマガジンの担当者に PGP/GPG を使える技術力が要求されます。 ここが PGP 話のネックです。 </para> @@ -35,13 +37,15 @@ PGP 認証 <para> メールマガジンは -「投稿可能なメンバーリストをカスタマイズ」することで行なえます。 +「投稿可能なメンバーリストをカスタマイズ」 +することで行なえます。 </para> <para> -$member_maps から $primary_member_map を抜き、 -代わりに投稿可能なメンバーのリスト(ここでは -$ml_home_dir/members-mailmag ファイルとしましょう)を +$member_maps から +$primary_member_map を抜き、 +かわりにメールマガジンを送信可能なメンバーのリスト +(ここでは $ml_home_dir/members-mailmag ファイルとしましょう)を $member_maps に追加します。 <screen> member_maps = $ml_home_dir/members-mailmag @@ -59,10 +63,17 @@ subscribe コマンドの仕方を変更するといったやり方で実装していません。 それを使う方法が subscribe コマンドを変更するより簡単です。 </para> </footnote> -というのは subscribe や unsubscribe コマンドは「 $primary_member_map -や$primary_recipient_map に対する変更を加える」という仕様だからです。 -一方、メンバー認証時の探索には member_maps や recipient_maps を使うの -です。なお、それぞれのデフォルト値は次のようになっています。 +というのは subscribe や unsubscribe コマンドは +「 $primary_member_map +や +$primary_recipient_map に対する変更を加える」という仕様だからです。 +一方、 +メンバー認証時の探索には +member_maps +や +recipient_maps +を使うのです。 +なお、それぞれのデフォルト値は次のようになっています。 <screen> member_maps = $primary_member_map $admin_member_maps @@ -70,10 +81,11 @@ member_maps = $primary_member_map recipient_maps = $primary_recipient_map file:$ml_home_dir/actives </screen> -$recipient_maps に actives ファイルが入っているのは互換性のためです( -&fml8; では、actives ファイルを使いませんが、&fml4; のディレクトリ構造 -そのままでも動作するようにするための互換性です)。 -よって、これらの値をうまく設定すれば、 +$recipient_maps に actives ファイルが入っているのは互換性のためです +(&fml8; では、actives ファイルを使いませんが、 +&fml4; のディレクトリ構造そのままでも動作するようにするための互換性です)。 +よって、 +これらの値をうまく設定すれば、 こういった設定が容易という具合になっているわけです。 </para> @@ -97,9 +109,12 @@ members ファイルは認証時の探索に使われません。 </para> <para> -一方、配送は recipients ファイル($primary_recipient_map)を元に、 +一方、 +配送は recipients ファイル($primary_recipient_map)を元に、 subscribe したユーザ宛にたいして行なわれます。 -ここの部分は普通のＭＬと一緒です。 +この部分は普通のＭＬと一緒です。 +このように map が細かく設定されていることを利用すれば、 +メールマガジンが簡単に実装できます。 </para> <para> @@ -121,8 +136,9 @@ members には投稿可能なアドレスだけを書きます。 </title> <para> -2004/06 後半以降: キューイングシステムの改変により、「わざとエラーにし -てメールキューに落し、メールの中身を確認してから flush する(配送する)」 +2004/06 後半以降: キューイングシステムの改変により +「わざとエラーにしてメールキューに落し、 +メールの中身を確認してから flush する(配送する)」 技が可能になりました。 </para> @@ -175,16 +191,22 @@ flushq が打ちづらいので flush コマンドも作ってみました。 <para> 社内向けに、 ＭＬのキューファイルを WWW サーバで見せるようにしておき、 -OK なら、そのシェルスクリプトを CGI で実行可能にしておくという方法も -よいでしょう。 +OK なら、 +そのシェルスクリプトを CGI で実行可能にしておくという方法もよいでしょう。 生のキューファイル名が見えてしまって、？？？になるとは思いますが、 こんなシステムなら一瞬で作れますよね？ </para> <para> -さらに「配送 OK 」を出すのが「送信者と異なる人」にしておけば、より優れ -たメールマガジンの運用になります。というのは、送信者が自分で自分に OK -を出すと、検査が甘くなるからです。 +さらに +「配送 OK 」 +を出すのが +「送信者と異なる人」 +という運用にすれば、 +より安全なメールマガジンの運用になるでしょう。 +というのは、 +送信者が自分で自分に OK を出すと、 +内容の審査/検査が甘くなるからです。 </para> </sect1> diff --git a/fml/doc/ja/tutorial/customize/ml.hier.sgml b/fml/doc/ja/tutorial/customize/ml.hier.sgml index 6239c7e9..5ebb4965 100644 --- a/fml/doc/ja/tutorial/customize/ml.hier.sgml +++ b/fml/doc/ja/tutorial/customize/ml.hier.sgml @@ -11,7 +11,7 @@ </title> <para> -メンバー制限をする普通のＭＬ群があたっとして、それらの階層化を考えます。 +メンバー制限をする普通のＭＬ群があるとし、それらの階層化を考えます。 ( <ulink url="http://www.oreilly.co.jp/BOOK/fml/"> fml バイブル @@ -64,10 +64,11 @@ article_post_restrictions = permit_anyone </para> <para> -しかしながら、MySQL なりで組織図とメール配送のリストを管理するほうが現 -代的ではあるでしょう。準備も保守も、それなりに必要となりますが、すでに -そういった認証システムがあるなら、それと連携するように設計してみてくだ -さい。 +しかしながら、 +MySQL なりで組織図とメール配信先リストを管理するのが現代的でしょう。 +準備も保守も、それなりに必要となりますが、 +すでにそういった認証システムがあるなら、 +それと連携するように設計してみてください。 </para> <para> diff --git a/fml/doc/ja/tutorial/customize/post_check_article_thread.sgml b/fml/doc/ja/tutorial/customize/post_check_article_thread.sgml index 7a8bc40b..0806c4a6 100644 --- a/fml/doc/ja/tutorial/customize/post_check_article_thread.sgml +++ b/fml/doc/ja/tutorial/customize/post_check_article_thread.sgml @@ -9,28 +9,34 @@ </title> <para> -「メンバー以外からの投稿」を受けて「投稿が拒否される」ケースが結構あり -ます。 +「メンバー以外からの投稿」 +を受けて +「投稿が拒否される」ケースが、けっこうあります。 </para> <para> -もちろん自分の使っているアドレスを変更したのを忘れたとか、サブドメイン -があったりなかったりなど、適当な使い方をしていたためのエラーもあれば、 +もちろん自分の使っているアドレスを変更したのを忘れたとか、 +サブドメインがあったりなかったりなど、 +メールの使い方の間違いもあれば、 転送先で読んで、そこから返事を書いてエラーになるケースもあります。 </para> <para> -そこで、2004/10/28 以降の article_post_restrictions には、特定の条件を -満たせば短時間だけ From: のアドレス(認証に使うメールアドレス)に関わら -ず投稿可能なオプション機能が追加されています。 +そこで、2004/10/28 以降の article_post_restrictions には、 +特定の条件を満たせば短時間だけ +From: のアドレス(認証に使うメールアドレス)にかかわらず、 +投稿可能なオプション機能が追加されています。 </para> <para> -現在の実装は「本ＭＬの記事を受けていて、その記事に対してのリプライをす -るのであれば通してやろう」というものです。ただし時間制限つきです。 -具体的には、In-Reply-To: もしくは References: で過去(一週間以内)の記事 -の message-id: を参照しているメールに対しては、(From: のメールアドレス -に関わらず)記事の投稿を許します。 +現在の実装は +「本ＭＬの記事の配送先のユーザが、 +その記事に対してのリプライをするのであれば通してやろう」 +というものです。 +ただし時間制限つきです。 +具体的には、In-Reply-To: もしくは References: で、 +過去(一週間以内)の記事の message-id: を参照しているメールに対しては、 +(From: のメールアドレスに関わらず)記事の投稿を許す機能です。 </para> @@ -91,7 +97,7 @@ article_post_restrictions = isolate_system_special_accounts <para> ま、ようは cookie みたいなもんですよね。 -ですが、課題は色々あります。 +課題は色々あります。 </para> <para> @@ -99,12 +105,13 @@ article_post_restrictions = isolate_system_special_accounts <screen> article_post_article_thread_lifetime = 86400 </screen> -$article_post_article_thread_lifetime という変数で制御できるようにして -みました。デフォルトでは一日です。 +$article_post_article_thread_lifetime +という変数で制御できるようにしてみました。 +デフォルト値は一日です。 </para> <para> -それより、時間制限って、いつからいつまでだ？ +それより、時間制限って、いつからいつまでが妥当なのでしょうか？ スレッドの始まった時からＮ秒？ それとも スレッドで最後に投稿された記事からＮ秒？ @@ -113,7 +120,7 @@ $article_post_article_thread_lifetime という変数で制御できるようにして <para> 2) subject: とスレッドの依存関係両方をチェックすると、 - かなり偽造するのが大変になるだろうとは思う。 + かなり偽造するのが大変になるだろうと思います。 <footnote> <para> 真面目に確率計算をしてくれると、 @@ -124,14 +131,16 @@ $article_post_article_thread_lifetime という変数で制御できるようにして </para> <para> -もっとも、たいてい message-id の方が長いことが多いから、From: -偽造よりこっちのほうが突破は難しいですかね？ +もっとも、 +たいてい message-id の方が長いことが多いので、 +From: 偽造よりこっちのほうが突破は難しいですかね？ </para> <para> -でもでも、駄目駄目な message-id をつける mailer だと、逆に弱く -なるけどねぇ。UNIXタイム@ホスト(FQDNじゃない) みたいなへぼいや -つだと、予測する範囲がすごく小さいや。 +でも、でも、駄目駄目な message-id をつける mailer だと、 +逆に弱くなりますね。 +UNIXタイム@ホスト(FQDNじゃない) みたいなへぼいやつだと、 +予測する範囲がすごく小さくなりますよね… </para> </sect2> @@ -159,9 +168,13 @@ $article_post_article_thread_lifetime という変数で制御できるようにして </para> <para> -たとえば次のような設定です。こうすると、疑似的に「スレッドをたてる小数 -の人(管理者) + スレッドへのリプライをする管理者以外の人たち」という運 -用になりますね。 +たとえば次のような設定です。 +こうすると、 +疑似的に +「スレッドをたてる小数の人(管理者) ++ +スレッドへのリプライをする管理者以外の人たち」 +という運用になりますよね。 </para> <para> @@ -179,23 +192,28 @@ reject ではなく isolate (SPAM の隔離)が推奨です。 <para> まず members-thread-init に登録されている人だけは -「いつでも投稿」できます。これ以外のメンバーは、通常、投稿を拒否されます。 -しかし、投稿されたメールに返信をした場合にかぎり -check_article_thread 命令で投稿が許されるという仕組みです。 +「いつでも投稿」できます。 +これ以外のメンバーは、通常、投稿を拒否されます。 +しかし、 +投稿されたメールに返信をした場合は(その場合にかぎり) +check_article_thread +命令で投稿が許されるという仕組みです。 </para> <para> -つまり、最初に管理者の人が話題をふる。その話題へのフォローだけはＭＬに -流れる。ようするに、管理者の人だけが「新規の話題を紹介する」ことが出来 -る仕組みです。モデレータ風だけど、少し違う仕掛けです。 +つまり、最初に管理者の人が話題をふる。 +その話題へのフォローだけはＭＬに流れる。 +ようするに、 +管理者の人だけが「新規の話題を紹介する」ことが出来る仕組みです。 +モデレータ風だけど、技術的には少し違う仕掛けです。 </para> <para> -このほうがモデレータより簡単で便利だと思うんですが、どうですかね？ +このほうがモデレータより簡単で便利だと思うんですが、どうでしょうか？ </para> <para> -また、ネタふりをする人の認証も PGP を使うとより良いです。 +なお、ネタふりをする人の認証も PGP を使うとより良いでしょう。 <screen> member_maps = $tmp_dir/members-thread-init diff --git a/fml/doc/ja/tutorial/customize/post_check_pgp_signature.sgml b/fml/doc/ja/tutorial/customize/post_check_pgp_signature.sgml index 6a472e46..2dc609a3 100644 --- a/fml/doc/ja/tutorial/customize/post_check_pgp_signature.sgml +++ b/fml/doc/ja/tutorial/customize/post_check_pgp_signature.sgml @@ -72,16 +72,21 @@ article_post_restrictions = reject_system_special_accounts <para> PGP のキーリングは、 -動作条件ごとに別に保存するようになっています。たとえば記事投稿 -用のキーは $ml_home_dir/etc/pgp-article-post-auth/ ディレクトリ以下に、 -リモート管理用のキーは $ml_home_dir/etc/pgp-admin-command-mail-auth/ +動作条件ごとに別に保存するようになっています。 +たとえば記事投稿用のキーは +$ml_home_dir/etc/pgp-article-post-auth/ +ディレクトリ以下に、 +リモート管理用のキーは +$ml_home_dir/etc/pgp-admin-command-mail-auth/ ディレクトリ以下に置くといった具合です。 </para> <para> -これらのキーは pgp2 pgp5 gpg コマンドで操作してください。ただ、デフォ -ルトのディレクトリではないこと、モードごとに異なるディレクトリを使うた -め、fmlpgp などのユーティリティプログラム( wrapper )を利用すると便利です。 +これらのキーは pgp2 pgp5 gpg コマンドで操作してください。 +ただ、 +デフォルトのディレクトリではないこと、 +モードごとに異なるディレクトリを使うため、 +fmlpgp などのユーティリティプログラム( wrapper )を利用するほうが便利です。 <screen> 例: elena ML で記事投稿で使うキーの生成 diff --git a/fml/doc/ja/tutorial/customize/post_permit_anyone.sgml b/fml/doc/ja/tutorial/customize/post_permit_anyone.sgml index 5bd76c20..2a50fd9e 100644 --- a/fml/doc/ja/tutorial/customize/post_permit_anyone.sgml +++ b/fml/doc/ja/tutorial/customize/post_permit_anyone.sgml @@ -9,24 +9,27 @@ </title> <para> -article_post_restrictions 変数は「記事の投稿を許すメンバー」を定義して -います。これを permit_anyone とすると、だれでも投稿可能になります。 +article_post_restrictions 変数は +「記事の投稿を許すメンバー」を定義しています。 +これを permit_anyone とすると、だれでも投稿可能になります。 <screen> article_post_restrictions = permit_anyone </screen> </para> <para> -&fml4; と異なり、上のように書くと本当に「誰でも投稿可能」となることに -注意して下さい。 -*_restrictions 変数には reject_system_special_accounts という root な -どを弾くルールが別途あります。デフォルトでは、それらを明示的に指定して -います(&fml4; では、このあたり曖昧でした)。 +&fml4; と異なり、 +上のように書くと本当に「誰でも投稿可能」となることに注意して下さい。 +*_restrictions 変数には +reject_system_special_accounts という root などを弾くルールが別途あります。 +デフォルトでは、それらを明示的に指定しています +(&fml4; では、このあたり曖昧でした)。 </para> <para> -&fml4; のように、root などシステムの特別なアカウントは弾き、それ以外の -ユーザからのメールは受け付けるという場合、次のようにします。 +&fml4; のように、 +root などシステムの特別なアカウントは弾き、 +それ以外のユーザからのメールは受け付けるという場合、次のようにします。 <screen> article_post_restrictions = reject_system_special_accounts permit_anyone @@ -40,23 +43,26 @@ article_post_restrictions = isolate_system_special_accounts </para> <para> -ちなみに 2008/08/17 以前 の article_post_restrictions のデフォルトは -&fml4; 互換のため、次のようになっています +ちなみに 2008/08/17 以前 の +article_post_restrictions のデフォルトは &fml4; 互換のため、 +次のようになっています <screen> article_post_restrictions = reject_system_special_accounts permit_member_maps reject </screen> この意味は -「root などシステムの特別なアカウントは弾き」 -「member_maps にあるユーザであれば投稿を許す」 -いづれにもマッチしないなら「投稿を拒否する」 +「root などシステムの特別なアカウントからの投稿は拒否」し、 +「member_maps にあるユーザであれば投稿を許可」 +そうでないなら +「投稿を拒否する」 となります。 </para> <para> -なお「reject_なになに」および「permit_なになに」という命令は、マッチし -たところで処理が終りになります。マッチしない場合には次の条件を試します。 +なお「reject_なになに」および「permit_なになに」という命令は、 +マッチしたところで処理が終りになります。 +マッチしない場合には次の条件を試します。 </para> <para> @@ -87,13 +93,14 @@ article_post_restrictions = isolate_system_special_accounts <answer> <para> -&fml4; のように HOOK でグローバル変数をいじくり回すといった -危ないことは出来せん。 +&fml4; のように +HOOK でグローバル変数をいじくり回すといった危ないことは出来せん。 </para> <para> -IO::Adapter の pcre サポートを利用すれば example.co.jp ドメインからの -投稿を許し、それ以外からの投稿を拒否する restrictions が書けます。 +IO::Adapter の PCRE (Perl互換正規表現)サポートを利用すれば +example.co.jp ドメインからの投稿を許し、 +それ以外からの投稿を拒否する restrictions が書けます。 <screen> [/var/spool/ml/elena/config.cf] diff --git a/fml/doc/ja/tutorial/customize/recipes.auth.sgml b/fml/doc/ja/tutorial/customize/recipes.auth.sgml index 144b2512..77d062df 100644 --- a/fml/doc/ja/tutorial/customize/recipes.auth.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.auth.sgml @@ -66,20 +66,22 @@ From アドレス認証以外に PGP/GPG 認証を使うことも出来ます。 use_address_compare_function = no </screen> -とすれば From アドレス認証の際に、メールアドレスに関わらず正当なアドレ -スとみなされます(常に認証が成功します）。 +とすれば、 +From アドレス認証の際に、 +メールアドレスに関わらず正当なアドレスとみなされます(常に認証が成功します）。 </para> <para> -もちろん、これは From アドレス認証にまつわる部分だけで、PGP/GPG 認証な -どとは別の話です(つまり、この変数を no にしても PGP/GPG 認証を使うこと -が出来ます)。 +もちろん、 +これは From アドレス認証にまつわる部分だけで、 +PGP/GPG 認証などとは別の話です +(つまり、この変数を no にしても PGP/GPG 認証を使うことが出来ます)。 </para> <para> また、 各 restrictions で permit_anyone を指定すると、 -実質認証をしていないので「アドレス認証していない」設定になります。 +実質認証をしないので「アドレス認証していない」設定と同等になります。 </para> </answer> diff --git a/fml/doc/ja/tutorial/customize/recipes.autoreply.sgml b/fml/doc/ja/tutorial/customize/recipes.autoreply.sgml index 2cfc2020..d082de51 100644 --- a/fml/doc/ja/tutorial/customize/recipes.autoreply.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.autoreply.sgml @@ -33,8 +33,9 @@ </para> <para> -このためには次のように HOOK で常に guide コマンドを実行するようにする -とよいでしょう。なお、この例では通常の処理は行なわないようにしています。 +このためには、 +次のように HOOK で常に guide コマンドを実行するようにするとよいでしょう。 +なお、この例では通常の処理は行なわないようにしています。 <screen> $distribute_run_start_hook = q{ @@ -55,9 +56,12 @@ $distribute_run_start_hook = q{ $command_mail_run_start_hook = $distribute_run_start_hook; </screen> -&fml4; と異なり、配送用とコマンドメール用それぞれのプロセスごとに HOOK -が分かれていることに注意して下さい。このため最後に同じ内容のコマンドメー -ル用の HOOK も定義する必要があります(コピーしてください)。 +&fml4; と異なり、 +配送用とコマンドメール用それぞれのプロセスごとに +HOOK が分かれていることに注意して下さい。 +このため上のように、 +最後に同じ内容のコマンドメール用の HOOK も定義する必要があります +(次のように変数をコピーすれば十分です)。 <screen> $command_mail_run_start_hook = $distribute_run_start_hook; </screen> @@ -113,6 +117,7 @@ $distribute_run_start_hook = q{ # ＭＬのメンバーでないならガイドを送り返します。 # ＭＬのメンバーに対しては普通のＭＬとなります。 + # この HOOK により、ガイドを送り返す機能が"追加されている"状態です。 unless ($cred->is_member($sender)) { # guide コマンドを呼び出します。 @@ -133,4 +138,3 @@ $distribute_run_start_hook = q{ </qandaset> - diff --git a/fml/doc/ja/tutorial/customize/recipes.body.sgml b/fml/doc/ja/tutorial/customize/recipes.body.sgml index 82d88a9e..2f4278be 100644 --- a/fml/doc/ja/tutorial/customize/recipes.body.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.body.sgml @@ -29,8 +29,8 @@ </para> <para> -もっともメンバーリストの管理だけを &fml8; で行なうことには意味があるか -もしれません。 +もっともメンバーリストの管理だけを +&fml8; で行なうことには意味があるかもしれません。 </para> <para> diff --git a/fml/doc/ja/tutorial/customize/recipes.command.admin.sgml b/fml/doc/ja/tutorial/customize/recipes.command.admin.sgml index f0c47246..07d1b01b 100644 --- a/fml/doc/ja/tutorial/customize/recipes.command.admin.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.command.admin.sgml @@ -34,7 +34,9 @@ admin コマンドでＭＬのメンバーリストを一気に削除/登録 <answer> <para> いまのところ、便利なコマンドは作ってないので、 -「admin useradd アドレス」や「admin userdel アドレス」 +「admin useradd アドレス」 +や +「admin userdel アドレス」 を書き連ねる方法しかありません _o_ </para> @@ -87,8 +89,8 @@ FML::Restriction::Base をみてください。 </para> <para> -subscribe 可能な人を特定のドメインだけに限りたいといった機能は未実装です( -いや HOOK を使えば出来ますけど)。 +subscribe 可能な人を特定のドメインだけに限りたいといった機能は未実装です +(いや HOOK を使えば出来ますけど)。 </para> </answer> @@ -111,7 +113,9 @@ subscribe 可能な人を特定のドメインだけに限りたいといった機能は未実装です( </para> <para> +<ulink url="http://www.fml.org/software/fml8/"> http://www.fml.org/software/fml8/ +</ulink> </para> </answer> diff --git a/fml/doc/ja/tutorial/customize/recipes.command.sgml b/fml/doc/ja/tutorial/customize/recipes.command.sgml index 05ee211f..a511ee25 100644 --- a/fml/doc/ja/tutorial/customize/recipes.command.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.command.sgml @@ -34,8 +34,8 @@ help などのメッセージをアップグレードする <answer> <para> &fml8; をアップグレードすれば自動的にアップグレードされます。 -&fml4; と異なり &fml8; では help コマンドのメッセージテンプレートは -次のようなパスに存在するからです。 +&fml4; と異なり &fml8; では +help コマンドのメッセージテンプレートは次のようなパスに存在するからです。 <screen> /usr/local/share/fml/$VERSION/message/euc-jp/user/help /usr/local/share/fml/$VERSION/message/us-ascii/user/help @@ -45,8 +45,7 @@ help などのメッセージをアップグレードする <para> ただしＭＬのホームディレクトリに help ファイルがある場合は それが help コマンドの返事に使われています。 -よって help ファイルを自分で用意しているなら -自分で編集してください。 +よって help ファイルを自分で用意している場合、自分で編集してください。 </para> </answer> @@ -64,9 +63,10 @@ help メッセージの元ファイルをカスタマイズする。 <answer> <para> -&fml8; では help コマンドのメッセージテンプレートは次のようなパスに存 -在します。これを編集してしまうというのが第一案。ただし、これをするとバー -ジョンアップをした際に変更点が無効になってしまいます。 +&fml8; では +help コマンドのメッセージテンプレートは次のようなパスに存在します。 +これを編集してしまうというのが第一案。 +ただし、これをするとバージョンアップをした際に変更点が無効になってしまいます。 <screen> /usr/local/share/fml/$VERSION/message/euc-jp/user/help /usr/local/share/fml/$VERSION/message/us-ascii/user/help @@ -95,6 +95,7 @@ help メッセージの元ファイルをカスタマイズする。 自分で編集してください。 この場合も、常にこのファイルが使われるので、 バージョンアップしても内容は変わりません。 +バージョンアップした場合、変更点を自分でファイルに反映させないといけません。 逆に言えば、それが欠点です。 </para> @@ -142,14 +143,15 @@ $ml_home_dir/news というファイルがあるとしましょう。 </para> <para> -一番簡単な作り方は help コマンドをぱくることです:) +一番簡単な作り方は help コマンドを参考に news コマンドを作成することでしょう。 たとえば FML::Command::User::help モジュール( /usr/local/lib/fml/$VERSION/FML/Command/User/help.pm -)をコピーして +) +をコピーして FML::Command::User::news ( /usr/local/lib/fml/site_local/FML/Command/User/news.pm ) -モジュールをつくってください。 +モジュールを作ってください。 そして、news.pm の中の help という文字列を news に変えるだけです。 <screen> [例] @@ -214,11 +216,13 @@ get コマンドを mget mp と同じ意味にする <answer> <para> -&fml8; ではデフォルトで、その意味(MIME/Multipart モード)になっています。 +&fml8; ではデフォルトで、 +その意味(MIME/Multipart モード)になっています。 </para> <para> -正確には、get と mget は同じコマンドで、get コマンドのファイルモードは +正確には、get と mget は同じコマンドで、 +get コマンドのファイルモードは (いまのところ) MIME/Multipart しかありません。 </para> </answer> @@ -260,8 +264,8 @@ command status report を抑制したい <para> (2) コマンドメール自体のコピーを受けとる。 -たとえば、コマンドメールを受けとる設定のところに管理者も追加しておくと -いった具合です。 +たとえば、 +コマンドメールを受けとる設定のところに管理者も追加しておくといった具合です。 <screen> elena-ctl: :include:/var/spool/ml/elena/include-ctl, elena-admin </screen> diff --git a/fml/doc/ja/tutorial/customize/recipes.delivery.sgml b/fml/doc/ja/tutorial/customize/recipes.delivery.sgml index 88227282..f09cf11c 100644 --- a/fml/doc/ja/tutorial/customize/recipes.delivery.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.delivery.sgml @@ -23,12 +23,14 @@ maintainer = アドレス maintainer = admin@example.co.jp </screen> +もちろん、 設定するアドレス( admin@example.co.jp )でメールを受けとれるように -しておいてください。 +MTA の設定をしてください。 </para> <para> -なおメールサーバによってはメールの送信者が自ドメイン以外からの場合、 +なおメールサーバによっては、 +メールの送信者が自ドメイン以外からの場合、 受信を拒否することがあるので注意して下さい。 </para> @@ -36,22 +38,27 @@ maintainer = admin@example.co.jp 単にエラーメールなどの受取先を変えたいだけなら、 maintainer ( elena ML なら elena-admin@fml.org ) のフォワード先を変更する方が簡単です。 -その設定は /etc/mail/aliases を変更するか、 -$maintainer_recipient_maps で行なえます。 +その設定は +/etc/mail/aliases を変更するか、 +$maintainer_recipient_maps の変更で行なえます。 </para> <para> 前者は MTA がフォワード先を変更していますが、 -後者では一度 elena-admin 宛のメールを &fml8; が受け、 +後者では、 +一度 elena-admin 宛のメールを &fml8; が受け、 &fml8; が $maintainer_recipient_maps にしたがって再配送を行ないます。 </para> <para> -”エラーメール”を &fml8; が再配送するという意味で若干不安のある実装で -すが、エラーメールを受けとる管理者リストを MTA ではなく &fml8; 側で管 -理するために必要なので実装されています。これは、たとえば WWW インター -フェイスでエラーメールを受けとる管理者リストを設定するといったケースを -想定した機能です。 +後者は、 +”エラーメール”を &fml8; が再配送するという意味で若干不安のある実装ですが、 +エラーメールを受けとる管理者リストを MTA ではなく +&fml8; 側で管理するために必要なので実装されています。 +これは、 +たとえば WWW インターフェイスで +「エラーメールを受けとる管理者リストを設定する」 +といったケースを想定した機能です。 </para> </answer> @@ -95,9 +102,9 @@ Subject のキーワードによって受信者を切替えることを考えます。 </para> <para> -たとえば Subject に「資料請求」とあるメールであれば、ＭＬドライバが直 -接資料請求を担当する人たちへフォワードしてあげると効率がよい。 -そういうケースです。 +たとえば Subject に「資料請求」とあるメールであれば、 +ＭＬドライバが直接資料請求を担当する人たちへフォワードしてあげると効率がよい。 +そういったケースです。 </para> <para> @@ -109,10 +116,10 @@ $distribute_run_start_hook = q{ my $header = $curproc->incoming_message_header(); my $subject = $header->get('subject') || ''; - use Mail::Message::String; - my $sbj = new Mail::Message::String $subject; - $sbj->charcode_convert_to_internal_code(); - $buf = $sbj->as_str(); + use Mail::Message::Subject; + my $sbj = new Mail::Message::Subject $subject; + $sbj->mime_header_decode(); + my $buf = $sbj->as_external_form(); my $map = ''; # 注意: このファイルは EUC-JP で書いて下さい @@ -131,8 +138,10 @@ $distribute_run_start_hook = q{ }; </screen> -ここで $ml_home_dir/recipients.info (/var/spool/ml/elena/recipients.info) -には資料請求を担当する人たちのアドレスが書かれています。 +ここで +$ml_home_dir/recipients.info (/var/spool/ml/elena/recipients.info) +には、 +資料請求を担当する人たちのアドレスが書かれています。 </para> </answer> @@ -193,16 +202,20 @@ $distribute_run_start_hook = q{ <answer> <para> -&fml8; の IO は IO::Adapter による抽象化をしています。たとえば受信者を -グループ fml に含まれるユーザ宛にするには次のようにするだけで十分です。 +&fml8; の IO は IO::Adapter による抽象化をしています。 +たとえば受信者を、 +グループ fml に含まれるユーザ宛にするには、 +次のようにするだけで十分です。 <screen> [config.cf] recipient_maps = unix.group:fml </screen> -ただし、他ドメインには送れないし、そのサーバにアカウントかエイリアス設 -定がないと配送できないので注意して下さい。 +ただし、 +簡単でよいかわりに、 +他ドメインには送れないし、 +そのサーバにアカウントかエイリアス設定がないと配送できないので注意して下さい。 </para> </answer> @@ -221,8 +234,9 @@ recipient_maps = unix.group:fml <answer> <para> -この機能が必要なのは、送信したメールの記録が残るメールリーダを使ってい -る場合、ＭＬから戻ってくる記事は必要ないと思う人がいるからだそうです。 +この機能が必要なのは、 +送信したメールの記録が残るメールリーダを使っている場合、 +ＭＬから戻ってくる記事は必要ないと思う人がいるからだそうです。 </para> <para> diff --git a/fml/doc/ja/tutorial/customize/recipes.filter.sgml b/fml/doc/ja/tutorial/customize/recipes.filter.sgml index 131737fc..908535e5 100644 --- a/fml/doc/ja/tutorial/customize/recipes.filter.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.filter.sgml @@ -59,8 +59,8 @@ $article_filter_start_hook = q{ <answer> <para> -たとえば特定のドメイン(\S+\@example.co.jp)は全部はじきたいといった -フィルタのことです。 +たとえば、 +特定のドメイン(\S+\@example.co.jp)を全て拒否するフィルタのことです。 内蔵フィルタの一部として実装しようと考えていますが、 残念ながら未実装です _o_ </para> @@ -110,22 +110,29 @@ multipart/* !text/plain reject <answer> <para> -&fml8; は、あらかじめ入力されたメッセージを解析し、メモリ上に鎖状の -Mail::Message オブジェクトの形で持っています。そこで、MIME/Multipart +&fml8; は、 +あらかじめ入力されたメッセージを解析し、 +メモリ上に鎖状の Mail::Message オブジェクトの形で持っています。 +そこで、 +MIME/Multipart の各部分のヘッダを取り出して、正規表現で順に確認すればよいだけです。 </para> <para> HOOK でなんとかする/ごまかす例は次の通りです。 -どちらの例でも、マッチした場合、stop_this_process() 命令で、 +どちらの例でも、 +マッチした場合、stop_this_process() 命令で、 それ以上の処理を止めています。 -また、この例では何もエラーメッセージを返そうとしていないため、 +また、 +この例では何もエラーメッセージを返そうとしていないため、 結果として、このメッセージは無視されて終りになっています。 </para> <para> -返事をしてあげたいなら、 reply_message() で、何か返事を返してあげてく -ださい…が、たぶんウィルスとかなので返事をしないほうが良いでしょう。 +返事をしてあげたいなら、 +reply_message() で、何か返事を返してあげてください。 +ただ、こういったメールはウィルスなどの可能性が高いので、 +返事をしないほうが良いでしょう。 </para> <para> @@ -223,7 +230,7 @@ article_filter_reject_notice_recipient = maintainer sender <para> -返送する先を送信者( From: のアドレス )にするには +返送する先を送信者( From: のアドレス )"のみ"にするには <screen> article_filter_reject_notice_recipient = sender </screen> @@ -274,7 +281,7 @@ spamassassin で SPAM メールを無視する。 </para> <para> -1. 内蔵フィルタの方の設定です。 +1. 内蔵フィルタの設定例です。 <screen> use_article_spam_filter = yes article_spam_filter_drivers = spamassassin @@ -282,7 +289,8 @@ article_spam_filter_drivers = spamassassin </para> <para> -2. HOOK でなんとかする/ごまかす例は次の通りです。 +2. 上と同様に spamassassi を呼び出すのですが、 +それを HOOK でなんとかする/ごまかす例は次の通りです。 <screen> $distribute_verify_request_end_hook = q{ my $spamassassin = '/usr/pkg/bin/spamc -c'; @@ -409,14 +417,17 @@ $article_filter_end_hook = q{ <para> HOOK でなんとかすることは出来ます。 -「記事に ML 独自の Message-ID: をつけたい」というレシピを参照して下さい。 +「記事に ML 独自の Message-ID: をつけたい」 +というレシピを参照して下さい。 </para> <para> -&fml4; では「In-Reply-To: や References: をつけてくれない MUA があるた -めにスレッドがうまく扱えない」という問題を解決するために、ＭＬ独自の -Message-ID: をつけて矯正するという機能がありました。現代では、そういっ -た MUA も死に絶えたでしょうから &fml8; では考慮しないことにします。 +&fml4; では +「In-Reply-To: や References: をつけてくれない MUA があるために、 +スレッドがうまく扱えない」という問題を解決するために、 +ＭＬ独自の Message-ID: をつけて矯正するという機能がありました。 +現代では、そういった MUA も死に絶えたでしょうから +&fml8; では考慮しないことにしています。 </para> </answer> diff --git a/fml/doc/ja/tutorial/customize/recipes.header.sgml b/fml/doc/ja/tutorial/customize/recipes.header.sgml index 2d510e4d..2e3a6b27 100644 --- a/fml/doc/ja/tutorial/customize/recipes.header.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.header.sgml @@ -16,8 +16,9 @@ Subject: に [elena:00100] のようなタグをつける <answer> <para> デフォルトではタグはつきません。 -また &fml8; ではタグを sprintf などで使われる形式で指定することになっています -(strftime(3) を参照)。 +また &fml8; では、 +タグを +sprintf などで使われる形式(strftime(3) を参照)で指定することになっています。 <screen> [/var/spool/ml/elena/config.cf] @@ -44,8 +45,8 @@ Subject: [elena:00100] の数字部分(00100)の桁数を変える <answer> <para> -&fml8; ではタグを sprintf 形式で指定することになっています -(strftime(3) を参照)。 +&fml8; ではタグを +sprintf 形式(strftime(3) を参照)で指定することになっています。 たとえば７桁なら %07 などとすればよいだけです。 <screen> [/var/spool/ml/elena/config.cf] @@ -150,7 +151,8 @@ Subject に [日付] というタグをつけたい。 <answer> <para> -YYYYMMDD (20060101) のような日付をつけたいなら、以下のようにして下さい。 +[YYYYMMDD] (e.g. [20060101]) のような日付をつけたい場合、 +以下のようにして下さい。 <screen> $distribute_verify_request_start_hook = q{ @@ -161,7 +163,7 @@ $distribute_verify_request_start_hook = q{ }; </screen> なお strftime(3) では様々なフォーマットが利用できます。 -詳しくは Unix マニュアル strftime(3) を参照。 +詳しくは Unix マニュアル strftime(3) を参照してください。 </para> </answer> @@ -283,7 +285,8 @@ $article_header_rewrite_end_hook = q{ <question> <para> -To: と Cc: の中にある &fml8; が管理しているＭＬのアドレスだけを +To: と Cc: の中にある +&fml8; が管理しているＭＬのアドレスだけを Reply-To: に設定する。 </para> </question> @@ -361,15 +364,16 @@ Sender: を X-Sender: にコピーする。 <para> 投稿されたメールの Sender: を X-Sender: にコピーしておきます。 -配送後、どこかで Sender: が変更されたとしても、オリジナルの送信者が -分かるということです。 +&fml8; の配送後、 +配送経路上のどこかで Sender: の変更が行われたとしても、 +オリジナルの送信者が分かるようにしたいということです。 </para> <para> もっとも Sender: をつけない人もいるので、 そういったメールに対しては対応できません。 -Sender: がないなら From: を X-Sender: にコピーしておくといった -条件文も必要かもしれません。 +Sender: がない場合 +From: を X-Sender: にコピーしておくといった条件文も必要かもしれません。 </para> <para> @@ -429,10 +433,16 @@ article_header_rewrite_rules -= rewrite_reply_to </para> <para> -デフォルトでは Reply-To: のないメールヘッダに対し「Reply-To: 投稿用ア -ドレス」が追加されます。これは $article_header_rewrite_rules にある -rewrite_reply_to 命令によります。よって、これをルールから削除してしま -えば「Reply-To: に対する書き換えルールが無効となる」というわけです。 +デフォルトでは +Reply-To: のないメールヘッダに対し +「Reply-To: 投稿用アドレス」が追加されます。 +これは +$article_header_rewrite_rules にある +rewrite_reply_to +命令によります。 +よって、これをルールから削除してしまえば +「Reply-To: に対する書き換えルールが無効となる」 +というわけです。 </para> </answer> @@ -453,7 +463,8 @@ To: Cc: Reply-To: を全部そのまま素通しにする。 </para> <para> -To: と Cc: は元々素通しです。そのため config.cf で +To: と Cc: は元々すどおしです。 +そのため config.cf で <screen> article_header_rewrite_rules -= rewrite_reply_to </screen> @@ -518,7 +529,7 @@ $article_header_rewrite_end_hook = q{ </para> <para> -もともとは某ＭＬで遊び心で始めた話が元ネタ。 +ノート: もともとは某ＭＬで遊び心で始めた話が元ネタです。 </para> </answer> @@ -565,9 +576,14 @@ $article_header_rewrite_end_hook = q{ <screen> outgoing_mail_header_reply_to = アドレス </screen> -でレポートメールの Reply-To: を指定できるのですが、 +変数で、 +レポートメールの Reply-To: を指定できるのですが、 これは今の実装が間違っていますね _o_ </para> + +<para> +(これは使わないでください) +</para> </answer> </qandaentry> @@ -627,21 +643,25 @@ In-Reply-To: か References: を強制したい。 <answer> <para> -記事への返信であるにも関わらず In-Reply-To: も References: もないメー -ルを送ってくる人が現実にいます。 -これをされると、いくつかの問題が生じます。 +記事への返信であるにも関わらず +In-Reply-To: も References: もないメールを送ってくる人が現実にいます。 +これ(スレッド情報の削除)をされると、いくつかの問題が生じます。 </para> <para> 第一に、メール間のスレッド関係が分からなくなるので見づらいです。 第二に、通常そういったメールは無い(少ない)ので、 -そういったメールは「普通のメール」ではなく -「SPAM メール」などの可能性が高いとみなされます。 +そういったメールは +「普通のメール」 +ではなく +「SPAM メール」 +などの可能性が高いとみなされます。 </para> <para> -Subject に返事の印( Re: など)がなく、In-Reply-To: または References: -ヘッダがないなら拒否する HOOK です。 +以下の例は +Subject に返事の印( Re: など)がなく、 +In-Reply-To: または References: ヘッダがないなら拒否する HOOK です。 <screen> $article_post_verify_request_end_hook = q{ my $header = $curproc->incoming_message_header(); diff --git a/fml/doc/ja/tutorial/customize/recipes.subscribe.sgml b/fml/doc/ja/tutorial/customize/recipes.subscribe.sgml index 2eb08ce3..dc513f8d 100644 --- a/fml/doc/ja/tutorial/customize/recipes.subscribe.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.subscribe.sgml @@ -277,8 +277,8 @@ fml 3.0 以前の auto_regist を使い続けたい <answer> <para> &fml4; では auto_regist を指定した場合 fml 3.0 以前の挙動になります。 -これはメンバーリストにも配送のリストにも members ファイルだけを使うと -いうものです。 +これは、 +メンバーリストにも配送のリストにも members ファイルだけを使うというものです。 </para> <para> @@ -291,10 +291,10 @@ fml 3.0 以前の auto_regist を使い続けたい primary_recipient_map = $primary_member_map </screen> とすればよいことになります。 -ただ、自動登録時にエラーがでます(すでにメンバーですから)。エラーを回避 -するため登録対象である primary_recipient_map はそのままダミーのファイ -ルとして残し、実際の配送リスト(recipient_maps)は members になるように -してしまうのがよいでしょう。 +ただ、自動登録時にエラーがでます(すでにメンバーですから)。 +エラーを回避するためには、 +登録対象である primary_recipient_map はそのままダミーのファイルとして残し、 +実際の配送リスト(recipient_maps)は members にしてしまうのがよいでしょう。 <screen> recipient_maps = $primary_member_map </screen> diff --git a/fml/doc/ja/tutorial/customize/recipes.www.sgml b/fml/doc/ja/tutorial/customize/recipes.www.sgml index eb5b113c..913e4254 100644 --- a/fml/doc/ja/tutorial/customize/recipes.www.sgml +++ b/fml/doc/ja/tutorial/customize/recipes.www.sgml @@ -20,7 +20,7 @@ </para> <para> - でも、そもそも記事を HTML 化しないほうがより安全です。 + でも、そもそも記事を HTML 化機能を停止すれば、より安全です。 <screen> [config.cf] @@ -44,7 +44,7 @@ <screen> Alias /mlarchive/ "/home/fml/public_html/" </screen> - とかすれば OK だと思うのですが、それじゃ駄目ですかね？ + とかすれば OK だと思うのですが、それでは駄目でしょうか？ </para> </answer> </qandaentry> @@ -60,14 +60,17 @@ <answer> <para> -はじめから HTML 化された記事が用意されています。そもそもデフォルトで -HTML 化されているので、あえて HTML 化機能を無効にしていなければ、公開 -するために WWW サーバを設定すれば良いだけです。 +はじめから HTML 化された記事が用意されています。 +そもそもデフォルトで HTML 化されているので、 +あえて HTML 化機能を無効にしていなければ、 +公開するために WWW サーバの設定変更をすれば良いだけです。 </para> <para> -一度 HTML 化を無効にしていて、ふたたび有効にしたくなった場合が問題ですが、 -fmlhtmlify コマンドで記事の HTML 化をすることができます。 +一度 HTML 化を無効にしていて、 +ふたたび有効にしたくなった場合が問題ですが、 +この場合は +fmlhtmlify コマンドで記事の再 HTML 化をすることができます。 <screen> % fmlhtmlify 記事のあるディレクトリ HTMLを置くディレクトリ @@ -85,7 +88,7 @@ fmlhtmlify コマンドで記事の HTML 化をすることができます。 <question> <para> -HTML 化をやりなおす +HTML 化をやりなおす(再生成する)には？ </para> </question> @@ -120,25 +123,20 @@ fmlhtmlify コマンドを使って下さい。 <screen> % rsync -av ~fml/public/fml/mlarchive/ドメイン/ＭＬ 他のマシン:/パス/ </screen> -rsync over ssh を自動で実行するには少し特殊な ssh の設定が必要ですので -注意して下さい。 +rsync over ssh を自動で実行するには、 +少し特殊な ssh の設定が必要ですので注意して下さい。 </para> <para> -案 2 は他のマシンの側に HTML を実行するコマンド(たとえば mhonarc )を仕 -掛けておくというものです。 +案 2 は他のマシンの側に +HTML を実行するコマンド(たとえば mhonarc)を仕掛けておくというものです。 </para> <para> -案 3 として WWW サーバのファイルシステムに NFS 経由でアクセスするとい -うのもありえますが、NFS サーバがインターネットから見える場所にあるよう -なネットワーク構成はいけません。構成を良く考える必要があります(裏ネッ -トワーク経由でアクセスするように設計しましょう)。 -</para> - -<para> -案 4 は iSCSI とかでサーバ間をつなぐか？ -ぼくはやったことがありません(NetBSD 4.0 は iSCSI target にしかなれないから) +案 3 として +WWW サーバのファイルシステムにネットワークごしにアクセスする案もありえますが、 +ファイルシステムがインターネットから見えるネットワーク構成は推奨されません。 +少なくとも裏ネットワーク経由でアクセスするように設計してください。 </para> </answer> |