[PREVIOUS CHAPTER] [NEXT CHAPTER]

8 used address

    8.1	Address for commands

    In config.ph makefml created, you see

    	$CONTROL_ADDRESS = "Elena-ctl\@$DOMAINNAME";

    $CONTROL_ADDRESS is an address for commands. This variable is used in
    header of reply mails but not concerned with MTA's configurations.
    "makefml newml" creates examples based on $CONTROL_ADDRESS.  MTA's
    configuration is another problem, e.g. sendmail is controlled by
    /etc/aliases. Please set up /etc/aliases properly.

    For $CONTROL_ADDRESS addr-spec style is preferable. But both below for
    $CONTROL_ADDRESS are available.

    	'Elena-ctl';
    	'Elena-ctl@axion.phys.titech.ac.jp';

    8.2	Member check and automatic registration

    We assume as a design policy that ML should be a method for private
    communication. It is preferable to check whether a sender to ML is a
    member or not. ML maintainers should edit and control member list
    manually for subscription requests. It is default but you can change
    this policy in config.ph.

    Just when "makefml newml" is done, default state, FML can permit a
    post and command mail from members registered to ML.

    If you want to change this configuration, you can use "makefml
    config", editing cf or config.ph manually.  Automatic registration is
    available when you set $REJECT_COMMAND_HANDLER to be "auto_regist".

    Access control and the reaction is controlled by $REJECT_*_HANDLER
    variables, like a

    [$REJECT_COMMAND_HANDLER]

    	$REJECT_COMMAND_HANDLER = "auto_regist"; (default "reject")

    The default value is "reject". If ML receives mail from a not
    member, ML rejects the request and sends back warning to a sender.  If
    you set it to be "auto_regist", FML do automatic registration.

    This is a typical case of "automatic registration".

    	$CONTROL_ADDRESS               = "elena-ctl\@$DOMAINNAME";
    	$PERMIT_COMMAND_FROM           = "members_only";
    	$REJECT_COMMAND_HANDLER        = "auto_regist";

    If $PERMIT_COMMAND_FROM is "members_only" and mail (subscribe
    request) comes from a not member, fml.pl calls $REJECT_COMMAND_HANDLER
    function. In default $REJECT_COMMAND_HANDLER is "reject", so fml.pl
    notifies denial of service to the requester.  If
    $REJECT_COMMAND_HANDLER is "auto_regist", fml.pl calls auto_regist
    hander to sets in the automatic registration routine.

    [$PERMIT_POST_FROM    permit post from whom ?]
    [$PERMIT_COMMAND_FROM permit command from whom ?]

    * member check

    fml.pl compares From: address and entries in $MEMBER_LIST
    (@MEMBER_LIST if defined).

    fml.pl denies mail from $REJECT_ADDR e.g. root, mailer-daemon. It is
    useful to check mail error loops and also to deny mail from public
    users (mail from "nobody"? who are you?) since we assume ML is private
    communication.

    When $PERMIT_POST_FROM == "moderator", please see 6.0.

    * Automatic registration

    See the chapter 5.0 for more details of automatic
    registration.

    Described above, if $PERMIT_COMMAND_FROM == "members_only", mail
    (subscribe request) comes from a not member and
    $REJECT_COMMAND_HANDLER == "auto_regist", fml.pl calls auto_regist
    hander to set in the automatic registration routine.

    $AUTO_REGISTRATION_TYPE controls actions of routines.  If request
    succeeds, fml.pl add From: address to $FILE_TO_REGIST (default is
    $MEMBER_LIST).

    ATTENTION: In automatic registration, fml.pl delivers mail to
    members in $MEMBER_LIST not $ACTIVE_LIST. This is historical (but I
    cannot change it for backward compatibility;-). It does not annoy you
    if you do not edit member lists by hand. Please see 5.0
    for several subscription styles ($AUTO_REGISTRATION_TYPE).

[PREVIOUS CHAPTER] [NEXT CHAPTER]