[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]