<!--
 $FML: recipes.subscribe.sgml,v 1.4 2008/08/18 02:23:59 fukachan Exp $
-->

<qandaset>

<qandaentry>

<question>
<para>
subscribe の登録作業は手動でしたい
(&fml4; の closed + confirm 相当)
</para>
</question>

<answer>
<para>
&fml8; の subscribe は confirmation つきの自動登録がデフォルトです。
<screen>
[config.cf のデフォルト値]

subscribe_command_auth_type      = confirmation

subscribe_command_operation_mode = automatic
</screen>
</para>

<para>
「手動操作」併用方式にするには、次のような設定があります。
<screen>
[config.cf]

subscribe_command_auth_type      = confirmation

subscribe_command_operation_mode = manual
</screen>
と設定した場合は、次のような挙動になります。
(1) &fml8; が confirmation を行ないリクエストの正当性を確認します。
「正当性を確認した」という報告を管理者へ行ないます。
(2) 一方、アドレスの登録作業は自動では行なわれません。
管理者へは登録作業を依頼するメールが &fml8; から出されます。
そのメールを見たら、
管理者は登録作業(admin コマンド、CUI、GUI)を手動でして下さい。
</para>

<para>
ようするに登録過程の最終段階が「自動」から「手動」に変わっただけです。
</para>

<para>
confirmation も登録も管理者が自ら行なう場合は次のようにして下さい。
この場合、ＭＬドライバを使う意義がないような気もしますが、
いや SPAM よけになるから若干の意味があるでしょう。
<screen>
[config.cf]

subscribe_command_auth_type      = manual

subscribe_command_operation_mode = manual
</screen>
</para>

</answer>

</qandaentry>


<qandaentry>

<question>
<para>
unsubscribe コマンドでも confirmation を使いたい
</para>
</question>

<answer>
<para>
&fml8; では confirmation がデフォルトの挙動です。
<screen>

</screen>

</para>
</answer>

</qandaentry>


<qandaentry>

<question>
<para>
unsubscribe の登録作業は手動でしたい
(&fml4; の closed + confirm 相当)
</para>
</question>

<answer>
<para>
unsubscribe は confirmation つきの自動登録がデフォルトです。
<screen>
[config.cf のデフォルト値]

unsubscribe_command_auth_type      = confirmation

unsubscribe_command_operation_mode = automatic
</screen>
</para>

<para>
<screen>
[config.cf]

unsubscribe_command_auth_type      = confirmation

unsubscribe_command_operation_mode = manual
</screen>
と設定した場合は、次のような挙動になります。
(1) &fml8; が confirmation を行ないリクエストの正当性を確認します。
管理者へ作業依頼のメールが &fml8; から出されます。
(2) 一方、アドレスの登録作業は自動では行なわれません。
管理者へは登録作業を依頼するメールが &fml8; から出されます。
そのメールを見たら登録作業(admin コマンド、CUI、GUI)をして下さい。
</para>

<para>
ようするに登録過程の最終段階が「自動」から「手動」に変わっただけです。
</para>

<para>
confirmation も登録も管理者が自ら行なう場合は次のようにして下さい。
この場合、ＭＬドライバを使う意義がないような気もしますが、
いや SPAM よけになるから意味がありますね。
<screen>
[config.cf]

unsubscribe_command_auth_type      = manual

unsubscribe_command_operation_mode = manual
</screen>
</para>

</answer>

</qandaentry>


<qandaentry>

<question>
<para>
chaddr コマンドでも confirmation を使いたい。
</para>
</question>

<answer>
<para>
&fml8; では confirmation がデフォルトの挙動です。
<screen>

</screen>

</para>
</answer>

</qandaentry>


<qandaentry>

<question>
<para>
chaddr の登録作業は手動でしたい
(&fml4; の closed + confirm 相当)
</para>
</question>

<answer>
<para>
chaddr は confirmation つきの自動登録がデフォルトです。
<screen>
[config.cf のデフォルト値]

chaddr_command_auth_type      = confirmation

chaddr_command_operation_mode = automatic
</screen>
</para>

<para>
<screen>
[config.cf]

chaddr_command_auth_type      = confirmation

chaddr_command_operation_mode = manual
</screen>
と設定した場合は、次のような挙動になります。
(1) &fml8; が confirmation を行ないリクエストの正当性を確認します。
(2) 一方、アドレスの登録作業は自動では行なわれません。
    管理者へは登録作業を依頼するメールが &fml8; から出されます。
    そのメールを見たら登録作業(admin コマンド、CUI、GUI)をして下さい。
</para>

<para>
ようするに登録過程の最後が「自動」から「手動」に変わっただけです。
</para>

<para>
confirmation も登録も管理者が自ら行なう場合は次のようにして下さい。
この場合、ＭＬドライバを使う意義がないような気もしますが、
いや SPAM よけになるから意味がありますね。
<screen>
[config.cf]

chaddr_command_auth_type      = manual

chaddr_command_operation_mode = manual
</screen>
</para>

</answer>

</qandaentry>


<qandaentry>

<question>
<para>
自動登録と自己紹介を同時に行ないたい
</para>
</question>

<answer>
<para>
未実装です。
<screen>

</screen>

</para>
</answer>

</qandaentry>


<qandaentry>

<question>
<para>
特定のメールアドレスのみを自動登録可能にする。
</para>
</question>

<answer>
<para>
未実装です。
<screen>

</screen>

</para>
</answer>

</qandaentry>


<qandaentry>

<question>
<para>
fml 3.0 以前の auto_regist を使い続けたい
</para>
</question>

<answer>
<para>
&fml4; では auto_regist を指定した場合 fml 3.0 以前の挙動になります。
これはメンバーリストにも配送のリストにも members ファイルだけを使うと
いうものです。
</para>

<para>
いまさら、この機能の需要があるとは思えませんが、一応、解説します。
</para>

<para>
これをエミュレーションするには、とりあえず
<screen>
primary_recipient_map = $primary_member_map 
</screen>
とすればよいことになります。
ただ、自動登録時にエラーがでます(すでにメンバーですから)。エラーを回避
するため登録対象である primary_recipient_map はそのままダミーのファイ
ルとして残し、実際の配送リスト(recipient_maps)は members になるように
してしまうのがよいでしょう。
<screen>
recipient_maps = $primary_member_map 
</screen>
この場合 recipients というファイルにも登録作業が行なわれていますが、
実際の挙動には関係ありません。配送リストには members が使われます。
</para>

</answer>

</qandaentry>


</qandaset>
