
	how to subscribe and unsubscribe and others around it

------------------------------------------------------------
1	Overview
1.1	hand edit by default
1.2	But automatic subscribe is usual
1.3	Moderators

2	Q & A
2.1	prefer $ADMIN_MEMBER_LIST from $MEMBER_LIST

3	Registration
3.1	Manual Registration; how to handle subscribe requests
3.2	unsubscribe confirmation
3.3	change address ("chaddr" command)

4	Automatic Registration
4.1	Overview of Automatic Registration
4.2	Enable Automatic Registration
4.3	Restriction On Addresses To Register
4.4	Restrict persons who can post to ML assuming automatic registration
4.5	Type Of Automatic Registration
4.6	$AUTO_REGISTRATION_TYPE: no-keyword
4.7	$AUTO_REGISTRATION_TYPE: subject
4.8	$AUTO_REGISTRATION_TYPE: body
4.9	$AUTO_REGISTRATION_TYPE: confirmation (RECOMMENDED)
4.10	&Confirm internal hook functions
4.11	[fml 1.x, fml 2.x] File to use in automatic registration
4.12	Forward a request mail to mailing list when automatic-ly added?
4.13	+ trick; not member check nor automatic registration
4.14	One recipient address for plural sender addresses when auto registration
4.15	Automatic registration fails for request mails from localhost
4.16	Delivery Mode In Automatic Registration
4.17	$AUTO_REGISTRATION_HOOK

5	Automatic Registration
5.1	Overview of Automatic Registration
5.2	Enable Automatic Registration
5.3	Restriction On Addresses To Register
5.4	Restrict persons who can post to ML assuming automatic registration
5.5	Type Of Automatic Registration
5.6	$AUTO_REGISTRATION_TYPE: no-keyword
5.7	$AUTO_REGISTRATION_TYPE: subject
5.8	$AUTO_REGISTRATION_TYPE: body
5.9	$AUTO_REGISTRATION_TYPE: confirmation (RECOMMENDED)
5.10	&Confirm internal hook functions
5.11	[fml 1.x, fml 2.x] File to use in automatic registration
5.12	Forward a request mail to mailing list when automatic-ly added?
5.13	+ trick; not member check nor automatic registration
5.14	One recipient address for plural sender addresses when auto registration
5.15	Automatic registration fails for request mails from localhost
5.16	Delivery Mode In Automatic Registration
5.17	$AUTO_REGISTRATION_HOOK

6	Moderator
6.1	Overview
6.2	Certification ($MODERATOR_FORWARD_TYPE == 2 default)
6.3	How to Certify ($MODERATOR_FORWARD_TYPE == 1)
6.4	How to Certify ($MODERATOR_FORWARD_TYPE == 3)
6.5	classify members to 3 groups based on trust-ness
6.6	Expire moderator queue

7	Delivery, commands and access controls
7.1	Access Control and policy
7.2	Automatic registration and access control
7.3	$MAIL_LIST
7.4	Address for commands only
7.5	If $MAIL_LIST == $CONTROL_ADDRESS
7.6	Set up a special server
7.7	Access control in remote administration

8	used address
8.1	Address for commands
8.2	Member check and automatic registration

9	misc
9.1	Not Deliver From: Field Address Of In-Coming Mail. 
9.2	off and skip
9.3	disable all commands except for subscribe/unsubscribe
9.4	actionless subscribe
9.5	what file "skip" command operates?
9.6	Restrict domains of user which joins a mailing list
9.7	Example: "automatic registration" and "restrict members who can post"
9.8	%DOMAIN_ALIASES when authentication
9.9	How severely FML checks the validity of the address
9.10	$MAINTAINER
9.13	One recipient for plural addresses to post mails from
9.14	Set up listname-request as a command address
------------------------------------------------------------


1	Overview

Firstly see basic_setup/ 

	../basic_setup/index.html

1.1	hand edit by default

If MAINTAINER received subscribe request, please use makefml to add
the user. See 3 section.

% makefml add elena ADDRESS

1.2	But automatic subscribe is usual

To make fml automatic subscribe work, please tour the config menu in
this way.  See 5 for more detalis.

makefml config elena 

   MAIN MENU -> 1 -> WHEN_COMMAND_FROM_NOT_MEMBER -> auto_subscribe

1.3	Moderators

Moderators checks article before the article is distributed.
See 6 for more details.

2	Q & A

2.1	prefer $ADMIN_MEMBER_LIST from $MEMBER_LIST

Yes. Let me consider the following case: if a remote administrator,
not recipient, can post elena ML, what should he/she do?

	% makefml newml elena
	% makefml addadmin elena rudo@nuinui.fml.org

3	Registration

Technical Terms => Glossary 1.3
See 5 for automatic registration details.

3.1	Manual Registration; how to handle subscribe requests

	$MANUAL_REGISTRATION_TYPE ('confirmation' or 'forward_to_admin')

How to handle 'subscribe' request to ML modified by maintainers' hand. 
In default fml confirms the will to From: address.

     subscriber           fml            maintainers/administrators

     1 a subscriber requests 'subscribe NAME' to fml.
     subscribe request ->

     2 fml sends back a confirmation of the will.
     		<-  confirm req

     3 He/She confirms and replis it.
     confirm it       ->  

     4 Fml confirmed the will and let maintainer to know it. 
       Fml also notifies the request is forwarded to maintainers.

     		    confirmed -------> "please add this subscriber"
     		<-
     confirmed
     Please wait a little.

     5 A maintainer edits the member list by hand or sends 
       remote administration commands.

     		admin add <address>
     		approve PASSWORD add <address>

     (if $ADMIN_ADD_SEND_WELCOME_FILE == 1,
     		<-
       "welcome!" mail is also returned)

If $MANUAL_REGISTRATION_CONFIRMATION_FILE file exists, fml sends back
it to the requester. In default this template does not exist.

	$MANUAL_REGISTRATION_CONFIRMATION_FILE (default $DIR/confirm.msub)

3.2	unsubscribe confirmation

"confirmation" mode is also available in "unsubscribe". FML uses the
same routine of "confirmation" in automatic registration.  Hence you
can restrict "unsubscribe" in the same way as in the case of automatic
registration.

	$UNSUBSCRIBE_AUTH_TYPE = "confirmation";

When "unsubscribe" request comes in, FML sends back a confirmation
request to verify the will. See 5 and speculate the
action.

3.3	change address ("chaddr" command)

When you change your ISP, domain ... you need to change your address
registered in ML. To change it, there are two methods

	1. chaddr command
	2. unsubscribe once and subscribe again

* fml 2.2, fml 2.2.1 default
  Please send the following address from "old-address" to change
	old to new one registered in ML member lists.

	From: old-address
	To: list-ctl@domain

	chaddr old-address new-address

* fml 2.2.1 option "chaddr confirmation"

fml 2.2.1 and fml-current (2.2B) has an option

	$CHADDR_AUTH_TYPE = 'confirmation';

to enable "chaddr confirmation". Fml confirms the chaddr to old and
new addresses. The process is as follows:

0.	Fml receives chaddr request. Fml sends back the confirmation.

1.	If fml receives the confirmation from each of old and new
	addresses, fml does chaddr process.

	chaddr process needs

   1.1	From: old-address or From: new-address	
   1.2	either of old-address or From: new-address should be a member	

2.	Fml sends back the result to both old-address, new-address
	and ML-maintainer. 
	# If you set 
	#	@DenyProcedure('r2a#chaddr');  (in config.ph)
	# maintainer will not receive mail of the chaddr result.

NOTE: 1999/10/04

   chaddr: check the new address and the current address similarity
	For example, unless this, sub-domain change must be an error.
	e.g. chaddr foo@a.b.x.y.z foo@123.b.x.y.z
	So, we gains the ADDR_CHECK_MAX if we encounters this case.
	And we need SaveACL and RetACL to get back to the
	original state after this function calling(like Context Switch).

		chaddr foo@a.b.x.y.z foo@123.b.x.y.z

4	Automatic Registration

4.1	Overview of Automatic Registration

From the first check in time of fml (1993), the design policy has been
same. The default policy is as follows:
	* A mailing list is a private communication.
	* Only members can post and use commands of ML.
	* Manually edit member lists.

* FML's automatic registration assumes that

FML member authentication follow.

	1 compare From: address and entries in @MEMBER_LIST 
	  which is composed of
		$FILE_TO_REGIST
		$MEMBER_LIST
		...

	2 If the address is already a member, O.K.

	3 If not a member, append the address to $FILE_TO_REGIST
	  which is the same as $MEMBER_LIST in default.

	4 notifies the registration to the requester and $MAINTAINER

In "confirmation" type, fml.pl asks the From: address's person on
confirmation of subscription request in stage 3. I RECOMMEND
"confirmation" type today against a trick.

"confirmation" type differs from others is a little. We explain this
in 5.9. We explain other types here.

* Address to regist
The target address to register is the address in From: or address in
subscription request (when $AUTO_REGISTRATION_TYPE is "subject" or
"body").

or

fml.pl does not consider Reply-To: field for the address to
regist. Not to use It must be safe. Reply-To: usage is invalid from
users to users today, so we cannot trust the field. For example a user
sends a request mail with Reply-To: $MAIL_LIST. It causes mail loop if
FML adds ML itself to a member. In fact FML checks loop possibility,
so does not add ML's.

* When a user is registered, fml.pl sends the welcome file back to
him/her.

	$WELCOME_FILE	= "$DIR/guide";	# could be "$DIR/welcome"
	$WELCOME_STATEMENT = 
	"Welcome to our $ML_FN\n You are added automatically\n";

The mail body is the file $WELCOME_FILE and the subject is
$WELCOME_STATEMENT.

$WELCOME_FILE is a welcome statement. The subject in default is

	Subject: Welcome to our (Elena ML)
	 You are added automatically

where $ML_FN = "(Elena ML)".

4.2	Enable Automatic Registration

If $PERMIT_COMMAND_FROM == "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 for a not member.
If $REJECT_COMMAND_HANDLER == "auto_regist", fml.pl calls auto_regist
hander to sets in the automatic registration routine.

in config.ph(default)

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

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

re-configured config.ph for automatic registration

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

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

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

Now FML permits only members can post to ML and reject mail from a
not member. FML permits commands from a member and do automatic
registration for a subscriber request mail from a not member.

	$REJECT_POST_HANDLER           = "auto_regist";

enables that $MAIL_LIST can provide the service of automatic
registration.

4.3	Restriction On Addresses To Register

This $REGISTRATION_ACCEPT_ADDR variables can restrict registration
routine in both cases, remote-administration and automatic
registration. This variable cannot restrict "makefml add".

In default automatic registration routine can accept all addresses
except for $REJECT_ADDR. $REGISTRATION_ACCEPT_ADDR restricts
acceptable addresses to register in automatic registration.  This
restriction is used in such that you can accept only a domain users as
a ML member.

Example 1; accept subscribe request from domain.co.jp
	$REGISTRATION_ACCEPT_ADDR = 'domain.co.jp';

Example 2;
	$REGISTRATION_ACCEPT_ADDR = 'domain1.co.jp|domain2.co.jp';

4.4	Restrict persons who can post to ML assuming automatic registration

$REJECT_COMMAND_HANDLER can have a value 'auto_asymmetric_regist'. If
defined, FML uses delivery list controlled by automatic registration
and authentication list edited by hand (or makefml).

	elena/actives	delivery list (automatic registration)
	elena/members	authentication list (edit by hand)

4.5	Type Of Automatic Registration

	$AUTO_REGISTRATION_TYPE 

controls automatic registration type. The available configuration is
one of them:

	confirmation
	body
	subject
	no-keyword

See 5.9 for more details on confirmation type.

4.6	$AUTO_REGISTRATION_TYPE: no-keyword

NOT REQUIRE SPECIAL KEYWORDS NOR PROCEDURES. If From: is a new comer,
FML adds it to a member automatically. I have used this style for a
party ML since almost all articles for this ML are "I joined the
party." mails and this temporary ML is used for a few weeks.

	$AUTO_REGISTRATION_TYPE = "no-keyword";

	Extract an Email address from From: field, compare and register it
	to a member if it is a new comer. If you change the address to add 
	explicitly, you can use the syntax

		subscribe your-mail-address 

	The "subscribe" keyword is defined in

		$AUTO_REGISTRATION_KEYWORD

4.7	$AUTO_REGISTRATION_TYPE: subject

A keyword in Subject: is required. To use this type, please set

	$AUTO_REGISTRATION_TYPE = "subject";

The address to register comes from
	* address if "Subject: subscribe address"
   or
	* From: address if just "Subject: subscribe"

	If Subject: does not match this format, FML returns the error mail.

4.8	$AUTO_REGISTRATION_TYPE: body

A keyword in the mail body is required. To use this type, set  

	$AUTO_REGISTRATION_TYPE = "body";

The address to register comes from
	* address if the body is "subscribe address"
   or
	* From: address if the body has only "subscribe"

	If a request mail does not match this format, 
	FML returns the error mail.

4.9	$AUTO_REGISTRATION_TYPE: confirmation (RECOMMENDED)

If the type

	$AUTO_REGISTRATION_TYPE = "confirmation";

is defined, FML tries to verify the user (From: address)'s will.  FML
sends a confirmation mail back for a subscribe request. The flow is as
follows:

1	subscribe request

The subscribe request phrase is "subscribe Family-name First-Name".
This "subscribe" is defined as $CONFIRMATION_SUBSCRIBE.  We expect
this format causes psychological trick.

	Example: subscribe Ken'ichi Fukamachi

2	reply from fml server

A confirmation request mail is sent to From: address. If the user
agrees it, the user needs to send back a phrase

	confirm 84682771 Ken'ichi Fukamachi

This is "confirmation" request of the users'will and also against
From: fabrication. FML ignores citation, so e.g. ">confirm 84682771
Ken'ichi Fukamachi" is accepted.

In sending back, the confirmation mail includes $CONFIRMATION_FILE
($DIR/confirm in default).

3	confirmation 

If a use receives the confirmation request, he/she sends back a phrase

	confirm password(identifier) your name

to an address

	$CONFIRMATION_ADDRESS

In default $CONTROL_ADDRESS must be either listname-ctl or fmlserv.

If FML receives the confirmation, it adds From: address to a member.
"confirm" keyword is defined as $CONFIRMATION_KEYWORD.

If a user fails the confirmation, please try it again from the first
"subscribe" request. For example when you lost the confirmation
request mail (so you not have a password of confirmation), ...

If so, please start again by sending

	subscribe Ken'ichi Fukamachi

____________________________________________________________________________
user				server

subscribe		->	receives subscribe request 
			<-	confirmation request
				"confirm identifier name"

sends 			->	
"confirm identifier name"
				If "confirm identifier name" is valid
				automatic registration routine adds the 
				From: address.

			<-	send "you are added to this ML." mail
____________________________________________________________________________

4.10	&Confirm internal hook functions

	$CONFIRM_REPLAY_TEXT_FUNCTION		for test
	$CONFIRM_REPLAY_SUBJECT_FUNCTION	for subject

This function hook is to generate each subject and text in each phase
transition of confirmation routine. "unsubscribe confirmation"~is an
application of this function.

4.11	[fml 1.x, fml 2.x] File to use in automatic registration

[fml 3.0]
fml 3.0 always uses member lists as follows:

		actives		recipient list
		members		authentication list

[fml 1.x, 2.x]

Which file to regist in is defined 

	$FILE_TO_REGIST ($MEMBER_LIST in default)

$FILE_TO_REGIST is the same as $MEMBER_LIST in default. However
authentication is based on files defined in an array 

	@MEMBER_LIST

It is useful to split up delivery lists and authentication lists.  For
example, create "members-admin" and adds remote maintainers to
it. members-admin is included in @MEMBER_LIST, so FML authenticates
them even if members and actives do not exist. After this, all
operations can be done under remote administration.

In default fml.pl defines @MEMBER_LIST as

    @MEMBER_LIST = ($MEMBER_LIST, $ADMIN_MEMBER_LIST);

The default authentication lists cover member list and remote
maintainers list. It enables that you set up remote maintainers in the
first, and set up all other by remote.

Requests log is logged in

	$CONFIRMATION_LIST

The request is expired after

	$CONFIRMATION_EXPIRE

4.12	Forward a request mail to mailing list when automatic-ly added?

I want not to read only "subscribe" phrase mail;_; In default FML does
not forward subscribe request mails to ML itself but notifies "added"
to ML maintainers. If the type is "confirmation", it must be of no mean:)

It ie apparently independent between forwarding and which address to
regist. When you do not want forwarding, set 

	$AUTO_REGISTERED_UNDELIVER_P = 1;

Comment: when an address is AUTOmatic REGISTERED, UNDELIVER-PREDICATE ?;-)
Naming convention is historical.

Even when $AUTO_REGISTERED_UNDELIVER_P == 1, only "subscribe" mail is
not forwarded. Forwarding depends on the number of lines. The limit is
8, which is considered, 3 main lines + 1 null line + signature 4
lines. This parameter is defined in 

	$AUTO_REGISTRATION_LINES_LIMIT = 8; 

If lines > 8, forwarding is done. If <= 8, it is not forwarded.

If $AUTO_REGISTRATION_LINES_LIMIT = -1, all request mails are
forwarded.

4.13	+ trick; not member check nor automatic registration

Historically "+" trick technique has been existed. Today "permit
anyone to post" config is 

	$PERMIT_POST_FROM	= "anyone";

"permit anyone to use commands" config is

	$PERMIT_COMMAND_FROM	= "anyone";

4.14	One recipient address for plural sender addresses when auto registration

One recipient address is fukachan@phys.titech.ac.jp but you can post
from plural senders e.g. fukachan@phys.titech.ac.jp,
elena@phys.titech.ac.jp, Pollyanna@phys.titech.ac.jp.

If member check mode == not automatic registration, $MEMBER_LIST is
for authentication, $ACTIVE_LIST is for delivery. Hence $ACTIVE_LIST
has fukachan@phys.titech.ac.jp, $MEMBER_LIST contains fukachan, elena
and Pollyanna.

In automatic registration mode, $MEMBER_LIST == $ACTIVE_LIST.  So
asymmetric list is not available in this mode.  When automatic
registration mode, in the member list (authentication list) you can
write in the following:

	fukachan@phys.titech.ac.jp
	# 3lena@phys.titech.ac.jp	
	# Pollyanna@phys.titech.ac.jp

fukachan@phys.titech.ac.jp	matome

4.15	Automatic registration fails for request mails from localhost

FML accepts From: user@domain form not From: user without domain.  It
is based on RFC822, in which not user@domain address is invalid.

$PeerAddr which log smtp connection source address may be also
available if you permit user form within localhost smtp connection.

* hack sendmail.cf. For example, in rule set 10 

R$+			$@$1<@$S>			user w/o host

[sendmail.cf Example]

S10
R<@>			$n				errors to mailer-daemon

# append local address
R$*			$:$>11 $1

S11
R$*<@$*>$*		$@$1<@$2>$3			already qualified

# output local host as user@host.domain
R$=S			$@$1<@$j>			show exposed names
R$+			$@$1<@$S>			user w/o host

* MH configuration

* force the requester to use "subscribe address" format. However this
is unavailable in "confirmation" type.

	subscribe uja@localhost-name.uja.jp 

* Hook adjustment (trick). It is not recommended. DO THIS BY YOUR OWN
  RISK.

$START_HOOK  = q#
	if ($From_address !~ /\@/) {
	}
#;

$START_HOOK  = q#
	if ($From_address !~ /\@/) {
		$From_address = "$From_address\@LOCAL_DOMAIN";
	}
#;

4.16	Delivery Mode In Automatic Registration

	address $AUTO_REGISTRATION_DEFAULT_MODE

can set the mode default configuration for From: address user. You
need to write $AUTO_REGISTRATION_DEFAULT_MODE using FML internal
representation.

* default is "skip"

	$AUTO_REGISTRATION_DEFAULT_MODE	= "s=1"; 

* default is digest delivery once in 3 hours, with file format
MIME/Multipart.

	$AUTO_REGISTRATION_DEFAULT_MODE	= "m=3mp"; 

4.17	$AUTO_REGISTRATION_HOOK

Example: a hook

$AUTO_REGISTRATION_HOOK = q#
    $e{'GH:Reply-To:'} = $MAINTAINER;
#;

Reply-To: $MAINTAINER for welcome mail when automatic registration.

5	Automatic Registration

5.1	Overview of Automatic Registration

From the first check in time of fml (1993), the design policy has been
same. The default policy is as follows:
	* A mailing list is a private communication.
	* Only members can post and use commands of ML.
	* Manually edit member lists.

* FML's automatic registration assumes that

FML member authentication follow.

	1 compare From: address and entries in @MEMBER_LIST 
	  which is composed of
		$FILE_TO_REGIST
		$MEMBER_LIST
		...

	2 If the address is already a member, O.K.

	3 If not a member, append the address to $FILE_TO_REGIST
	  which is the same as $MEMBER_LIST in default.

	4 notifies the registration to the requester and $MAINTAINER

In "confirmation" type, fml.pl asks the From: address's person on
confirmation of subscription request in stage 3. I RECOMMEND
"confirmation" type today against a trick.

"confirmation" type differs from others is a little. We explain this
in 5.9. We explain other types here.

* Address to regist
The target address to register is the address in From: or address in
subscription request (when $AUTO_REGISTRATION_TYPE is "subject" or
"body").

or

fml.pl does not consider Reply-To: field for the address to
regist. Not to use It must be safe. Reply-To: usage is invalid from
users to users today, so we cannot trust the field. For example a user
sends a request mail with Reply-To: $MAIL_LIST. It causes mail loop if
FML adds ML itself to a member. In fact FML checks loop possibility,
so does not add ML's.

* When a user is registered, fml.pl sends the welcome file back to
him/her.

	$WELCOME_FILE	= "$DIR/guide";	# could be "$DIR/welcome"
	$WELCOME_STATEMENT = 
	"Welcome to our $ML_FN\n You are added automatically\n";

The mail body is the file $WELCOME_FILE and the subject is
$WELCOME_STATEMENT.

$WELCOME_FILE is a welcome statement. The subject in default is

	Subject: Welcome to our (Elena ML)
	 You are added automatically

where $ML_FN = "(Elena ML)".

5.2	Enable Automatic Registration

If $PERMIT_COMMAND_FROM == "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 for a not member.
If $REJECT_COMMAND_HANDLER == "auto_regist", fml.pl calls auto_regist
hander to sets in the automatic registration routine.

in config.ph(default)

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

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

re-configured config.ph for automatic registration

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

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

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

Now FML permits only members can post to ML and reject mail from a
not member. FML permits commands from a member and do automatic
registration for a subscriber request mail from a not member.

	$REJECT_POST_HANDLER           = "auto_regist";

enables that $MAIL_LIST can provide the service of automatic
registration.

5.3	Restriction On Addresses To Register

This $REGISTRATION_ACCEPT_ADDR variables can restrict registration
routine in both cases, remote-administration and automatic
registration. This variable cannot restrict "makefml add".

In default automatic registration routine can accept all addresses
except for $REJECT_ADDR. $REGISTRATION_ACCEPT_ADDR restricts
acceptable addresses to register in automatic registration.  This
restriction is used in such that you can accept only a domain users as
a ML member.

Example 1; accept subscribe request from domain.co.jp
	$REGISTRATION_ACCEPT_ADDR = 'domain.co.jp';

Example 2;
	$REGISTRATION_ACCEPT_ADDR = 'domain1.co.jp|domain2.co.jp';

5.4	Restrict persons who can post to ML assuming automatic registration

$REJECT_COMMAND_HANDLER can have a value 'auto_asymmetric_regist'. If
defined, FML uses delivery list controlled by automatic registration
and authentication list edited by hand (or makefml).

	elena/actives	delivery list (automatic registration)
	elena/members	authentication list (edit by hand)

5.5	Type Of Automatic Registration

	$AUTO_REGISTRATION_TYPE 

controls automatic registration type. The available configuration is
one of them:

	confirmation
	body
	subject
	no-keyword

See 5.9 for more details on confirmation type.

5.6	$AUTO_REGISTRATION_TYPE: no-keyword

NOT REQUIRE SPECIAL KEYWORDS NOR PROCEDURES. If From: is a new comer,
FML adds it to a member automatically. I have used this style for a
party ML since almost all articles for this ML are "I joined the
party." mails and this temporary ML is used for a few weeks.

	$AUTO_REGISTRATION_TYPE = "no-keyword";

	Extract an Email address from From: field, compare and register it
	to a member if it is a new comer. If you change the address to add 
	explicitly, you can use the syntax

		subscribe your-mail-address 

	The "subscribe" keyword is defined in

		$AUTO_REGISTRATION_KEYWORD

5.7	$AUTO_REGISTRATION_TYPE: subject

A keyword in Subject: is required. To use this type, please set

	$AUTO_REGISTRATION_TYPE = "subject";

The address to register comes from
	* address if "Subject: subscribe address"
   or
	* From: address if just "Subject: subscribe"

	If Subject: does not match this format, FML returns the error mail.

5.8	$AUTO_REGISTRATION_TYPE: body

A keyword in the mail body is required. To use this type, set  

	$AUTO_REGISTRATION_TYPE = "body";

The address to register comes from
	* address if the body is "subscribe address"
   or
	* From: address if the body has only "subscribe"

	If a request mail does not match this format, 
	FML returns the error mail.

5.9	$AUTO_REGISTRATION_TYPE: confirmation (RECOMMENDED)

If the type

	$AUTO_REGISTRATION_TYPE = "confirmation";

is defined, FML tries to verify the user (From: address)'s will.  FML
sends a confirmation mail back for a subscribe request. The flow is as
follows:

1	subscribe request

The subscribe request phrase is "subscribe Family-name First-Name".
This "subscribe" is defined as $CONFIRMATION_SUBSCRIBE.  We expect
this format causes psychological trick.

	Example: subscribe Ken'ichi Fukamachi

2	reply from fml server

A confirmation request mail is sent to From: address. If the user
agrees it, the user needs to send back a phrase

	confirm 84682771 Ken'ichi Fukamachi

This is "confirmation" request of the users'will and also against
From: fabrication. FML ignores citation, so e.g. ">confirm 84682771
Ken'ichi Fukamachi" is accepted.

In sending back, the confirmation mail includes $CONFIRMATION_FILE
($DIR/confirm in default).

3	confirmation 

If a use receives the confirmation request, he/she sends back a phrase

	confirm password(identifier) your name

to an address

	$CONFIRMATION_ADDRESS

In default $CONTROL_ADDRESS must be either listname-ctl or fmlserv.

If FML receives the confirmation, it adds From: address to a member.
"confirm" keyword is defined as $CONFIRMATION_KEYWORD.

If a user fails the confirmation, please try it again from the first
"subscribe" request. For example when you lost the confirmation
request mail (so you not have a password of confirmation), ...

If so, please start again by sending

	subscribe Ken'ichi Fukamachi

____________________________________________________________________________
user				server

subscribe		->	receives subscribe request 
			<-	confirmation request
				"confirm identifier name"

sends 			->	
"confirm identifier name"
				If "confirm identifier name" is valid
				automatic registration routine adds the 
				From: address.

			<-	send "you are added to this ML." mail
____________________________________________________________________________

5.10	&Confirm internal hook functions

	$CONFIRM_REPLAY_TEXT_FUNCTION		for test
	$CONFIRM_REPLAY_SUBJECT_FUNCTION	for subject

This function hook is to generate each subject and text in each phase
transition of confirmation routine. "unsubscribe confirmation"~is an
application of this function.

5.11	[fml 1.x, fml 2.x] File to use in automatic registration

[fml 3.0]
fml 3.0 always uses member lists as follows:

		actives		recipient list
		members		authentication list

[fml 1.x, 2.x]

Which file to regist in is defined 

	$FILE_TO_REGIST ($MEMBER_LIST in default)

$FILE_TO_REGIST is the same as $MEMBER_LIST in default. However
authentication is based on files defined in an array 

	@MEMBER_LIST

It is useful to split up delivery lists and authentication lists.  For
example, create "members-admin" and adds remote maintainers to
it. members-admin is included in @MEMBER_LIST, so FML authenticates
them even if members and actives do not exist. After this, all
operations can be done under remote administration.

In default fml.pl defines @MEMBER_LIST as

    @MEMBER_LIST = ($MEMBER_LIST, $ADMIN_MEMBER_LIST);

The default authentication lists cover member list and remote
maintainers list. It enables that you set up remote maintainers in the
first, and set up all other by remote.

Requests log is logged in

	$CONFIRMATION_LIST

The request is expired after

	$CONFIRMATION_EXPIRE

5.12	Forward a request mail to mailing list when automatic-ly added?

I want not to read only "subscribe" phrase mail;_; In default FML does
not forward subscribe request mails to ML itself but notifies "added"
to ML maintainers. If the type is "confirmation", it must be of no mean:)

It ie apparently independent between forwarding and which address to
regist. When you do not want forwarding, set 

	$AUTO_REGISTERED_UNDELIVER_P = 1;

Comment: when an address is AUTOmatic REGISTERED, UNDELIVER-PREDICATE ?;-)
Naming convention is historical.

Even when $AUTO_REGISTERED_UNDELIVER_P == 1, only "subscribe" mail is
not forwarded. Forwarding depends on the number of lines. The limit is
8, which is considered, 3 main lines + 1 null line + signature 4
lines. This parameter is defined in 

	$AUTO_REGISTRATION_LINES_LIMIT = 8; 

If lines > 8, forwarding is done. If <= 8, it is not forwarded.

If $AUTO_REGISTRATION_LINES_LIMIT = -1, all request mails are
forwarded.

5.13	+ trick; not member check nor automatic registration

Historically "+" trick technique has been existed. Today "permit
anyone to post" config is 

	$PERMIT_POST_FROM	= "anyone";

"permit anyone to use commands" config is

	$PERMIT_COMMAND_FROM	= "anyone";

5.14	One recipient address for plural sender addresses when auto registration

One recipient address is fukachan@phys.titech.ac.jp but you can post
from plural senders e.g. fukachan@phys.titech.ac.jp,
elena@phys.titech.ac.jp, Pollyanna@phys.titech.ac.jp.

If member check mode == not automatic registration, $MEMBER_LIST is
for authentication, $ACTIVE_LIST is for delivery. Hence $ACTIVE_LIST
has fukachan@phys.titech.ac.jp, $MEMBER_LIST contains fukachan, elena
and Pollyanna.

In automatic registration mode, $MEMBER_LIST == $ACTIVE_LIST.  So
asymmetric list is not available in this mode.  When automatic
registration mode, in the member list (authentication list) you can
write in the following:

	fukachan@phys.titech.ac.jp
	# 3lena@phys.titech.ac.jp	
	# Pollyanna@phys.titech.ac.jp

fukachan@phys.titech.ac.jp	matome

5.15	Automatic registration fails for request mails from localhost

FML accepts From: user@domain form not From: user without domain.  It
is based on RFC822, in which not user@domain address is invalid.

$PeerAddr which log smtp connection source address may be also
available if you permit user form within localhost smtp connection.

* hack sendmail.cf. For example, in rule set 10 

R$+			$@$1<@$S>			user w/o host

[sendmail.cf Example]

S10
R<@>			$n				errors to mailer-daemon

# append local address
R$*			$:$>11 $1

S11
R$*<@$*>$*		$@$1<@$2>$3			already qualified

# output local host as user@host.domain
R$=S			$@$1<@$j>			show exposed names
R$+			$@$1<@$S>			user w/o host

* MH configuration

* force the requester to use "subscribe address" format. However this
is unavailable in "confirmation" type.

	subscribe uja@localhost-name.uja.jp 

* Hook adjustment (trick). It is not recommended. DO THIS BY YOUR OWN
  RISK.

$START_HOOK  = q#
	if ($From_address !~ /\@/) {
	}
#;

$START_HOOK  = q#
	if ($From_address !~ /\@/) {
		$From_address = "$From_address\@LOCAL_DOMAIN";
	}
#;

5.16	Delivery Mode In Automatic Registration

	address $AUTO_REGISTRATION_DEFAULT_MODE

can set the mode default configuration for From: address user. You
need to write $AUTO_REGISTRATION_DEFAULT_MODE using FML internal
representation.

* default is "skip"

	$AUTO_REGISTRATION_DEFAULT_MODE	= "s=1"; 

* default is digest delivery once in 3 hours, with file format
MIME/Multipart.

	$AUTO_REGISTRATION_DEFAULT_MODE	= "m=3mp"; 

5.17	$AUTO_REGISTRATION_HOOK

Example: a hook

$AUTO_REGISTRATION_HOOK = q#
    $e{'GH:Reply-To:'} = $MAINTAINER;
#;

Reply-To: $MAINTAINER for welcome mail when automatic registration.

6	Moderator

6.1	Overview

In Moderator mode (moderation for posted articles)

	1 posted mail to ML is not delivered to members.
	2 the mail is forwarded to moderators.
	3 moderator certifies the content. If he accepts it,
	  he sends back a keyword of certification to ML server.
	  FML server (described below) notifies the keyword/password to you.

FML runs under moderator mode if in config.ph

	$PERMIT_POST_FROM              = "moderator";

The menu shown in "makefml config " is 

   [POST]

   1    PERMIT_POST_FROM                   moderators

We can apply moderation for command mails.  This is of no use to
certify command requests? The current FML provides commands
certification procedures sa the same as posting mails.

   [COMMAND]

   3    PERMIT_COMMAND_FROM                moderators

6.2	Certification ($MODERATOR_FORWARD_TYPE == 2 default)

FML has several kinds of certifications. The type differs following
$MODERATOR_FORWARD_TYPE. When $MODERATOR_FORWARD_TYPE is type I, you
send back a submitted mail to ML with a field "Approval:
remote-administrator-password" in the header.  When
$MODERATOR_FORWARD_TYPE is type II, you receive the following mail
from FML when an article is submitted.

   Moderated $MAIL_LIST (elena@fml.org) receives a submit from

      fukachan@fml.org.

   Please check it. If you certify the following article, 
   please send to elena-ctl@fml.org
   the following line (only this line!)

   moderator certified 199711032027.709982

   ------- Forwarded Message

   a submitted mail

   ------- End of Forwarded Message

If the moderator certifies the content, he/she sends the "moderator"
keyword line to elena-ctl@fml.org.

moderator certified 199711032027.709982

Who is a moderator? When $MODERATOR_FORWARD_TYPE is type II, it is
members which the keyword and notification is sent to. In default a
moderator is the ML maintainer, $MAINTAINER. If the file
$DIR/moderators exists, the forwarded mail described above is sent to
members in a list, $DIR/moderators. Hence people who receive the mail
are moderators since a password (one time) is seen in this mail. When
$MODERATOR_FORWARD_TYPE is type I, moderators are people who can know
the password to add "Approval:" field.

6.3	How to Certify ($MODERATOR_FORWARD_TYPE == 1)

The forwarded mail is sent to $MAINTAINER or members in
$DIR/moderators. When $MODERATOR_FORWARD_TYPE is type I, you should
send back remote administrator password with Approval: password in the
header.

The problem is to use password in the header. When an error occurs,
postmaster can read a password in a header.

Not to use Approval: field, FML provides "admin forward" command such
as:

	admin forward

	admin forward
	certified article sent to ML

Example:

	admin forward

	admin pass approval-password
	admin forward
	mail body (certified article sent to ML)

6.4	How to Certify ($MODERATOR_FORWARD_TYPE == 3)

Type III is a variation of type I. The mail from a moderator pass
through without certification. The mail with Approva: password is not
checked. 

See also "admin forward" command.

6.5	classify members to 3 groups based on trust-ness

Consider to split members off to 3 groups such as

group 1: moderators
group 2: trusted omembers but not moderators
group 3: untrusted people

Moderator mode described above cannot provide 3 calss trust-ness.
Here we implement it by a hook.

1. set up moderator mode ML.

	$PERMIT_POST_FROM  = "moderator";

2. prepare $DIR/priv which is a list of trusted members (group 2).
   The list syntax is the same as members, actives ...

3. append the following hook to config.ph (append it to cf and
   re-create config.ph by "make config.ph" etc..).

$START_HOOK = q#
     $PRIV_LIST = "$DIR/priv";
      if (&CheckMember($From_address, $PRIV_LIST)) {
         $PERMIT_POST_FROM  = "members_only";
   }
#;

6.6	Expire moderator queue

	$MODERATOR_EXPIRE_LIMIT (default 14 == 2 weeks)

expire moderator mail queue

7	Delivery, commands and access controls

7.1	Access Control and policy

	$PERMIT_POST_FROM
	$REJECT_POST_HANDLER
	$PERMIT_COMMAND_FROM
	$REJECT_COMMAND_HANDLER

are access control variables.

   $PERMIT_POST_FROM		permit posting from whom ?
   $REJECT_POST_HANDLER		If a not member posts mail, 
				what should we do?
   $PERMIT_COMMAND_FROM		permit commands from whom ?
   $REJECT_COMMAND_HANDLER	If a not member posts a command mail, 
				what should we do?

[whom]
	anyone			from anyone
	members_only		members only (in $MEMBER_LIST @MEMBER_LIST)
	moderator		forward mail from anyone to moderators

[handler]
	reject			reject (sends the file "deny" to From:)
	auto_subscribe		calls automatic registration (fml Release 3)
	ignore			ignore

	(auto_regist		fml Release 2 automatic registration)

When non usual event occurs in any case, fml.pl sends a report to
$MAINTAINER.

In "anyone", "members_only" and "moderators", $REJECT_ADDR is applied.
If mail comes from public addresses e.g. "root', "postmaster",
"mailer-daemon", fml.pl rejects it. If you can pass it, change
$REJECT_ADDR.

    $REJECT_ADDR  = 'root|postmaster|MAILER-DAEMON|msgs|nobody';
    $REJECT_ADDR .= '|majordomo|listserv|listproc';

Consider a default config.ph of elena ML.  In it access control is
defined as follows:

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

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

7.2	Automatic registration and access control

For example, configure

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

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

In this case, fml.pl rejects mail posted from a not member.
Subscribe request from a not member to the command address is passed
to automatic registration routine.

	$REJECT_POST_HANDLER           = "auto_subscribe";

enables to pass mail from a not member to the automatic registration
routine.

7.3	$MAIL_LIST

Consider if you set $MAIL_LIST == $CONTROL_ADDRESS. The combination is
possible to set up. In this case fml.pl cannot recognize the mail is
commands or a usual article. However special keywords to show this
mail is for commands can control fml.pl action mode. The keyword
syntax is '# command' syntax. For example, "# help".

This is not used in default and prepared for some backward
compatibility.

7.4	Address for commands only

listname-ctl is set up for a command address in default examples.
include-ctl file is created for it and aliases has an entry for this
address. Please set up them. "--ctladdr" in listname-ctl is required,
so DO NOT REMOVE IT. Who can use commands is controlled by
$PERMIT_COMMAND_FROM. You can change the variable by hand or makefml config. 

7.5	If $MAIL_LIST == $CONTROL_ADDRESS

Consider if you set $MAIL_LIST == $CONTROL_ADDRESS. The combination is
possible to set up. In this case fml.pl cannot recognize commands or
just an article. However special keywords to show commands can control
fml.pl action mode. The keyword syntax is '# command' syntax.

This is not used in default and prepared for some backward
compatibility.

7.6	Set up a special server

You can set up a special purpose server by setting $LOAD_LIBRARY.
$LOAD_LIBRARY priority is higher than a command server. In fact
theoretically speaking, a command server is a special case of this
functionality. The command server is when

	$LOAD_LIBRARY = 'libfml.pl'; 

and if you set

	$LOAD_LIBRARY = 'libftpmail.pl'; 

you can provide ftpmail server.  

7.7	Access control in remote administration

Address, password, PGP authentication are available. 

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.

* Automatic registration

See the chapter 5 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
for several subscription styles ($AUTO_REGISTRATION_TYPE).

9	misc

9.1	Not Deliver From: Field Address Of In-Coming Mail. 

If you do not deliver an article when you yourself post it, set

$START_HOOK = q#
	$SKIP{'fukachan@phys.titech.ac.jp'} = 1
		if &AddressMatch($From_address, 'fukachan@phys.titech.ac.jp');
#;

9.2	off and skip

fml-support: 07144

These functions are same but different internally.

9.3	disable all commands except for subscribe/unsubscribe

fml-support: 07271

disable all commands except for subscribe/unsubscribe

@PermitProcedure = ('subscribe', 'confirm', 'bye');

It is better to set up this to disable "fml status report" reply.

     &DEFINE_MODE('disablenotify');

9.4	actionless subscribe

This is tricky. If subscribe request comes to elena-ctl, the function
is same as the default one.  But subscribe request comes to elena ML
itself, the article is forwarded to elena ML.

    $AUTO_REGISTRATION_LINES_LIMIT = -1;
    $START_HOOK = q#
    	if ($Envelope{'mode:ctladdr'}) {
    		$AUTO_REGISTERED_UNDELIVER_P   = 1;
    	}
    	else {
    		$AUTO_REGISTERED_UNDELIVER_P   = 0;
    	}
    #;

9.5	what file "skip" command operates?

fml-support: 07656, 07716

	push( @MEMBER_LIST, "$DIR/../list2/members" );

  loading config.ph
  ...

When you use both "list1" and "list2" ML member lists for list1 ML,
"skip" command operates the first matched target within these lists.
To enforce the search order to list2/members, list1/members, try this
hook (if you use old fml (< 4.0)).

$START_HOOK = q#
   push( @MEMBER_LIST, "$DIR/../list2/members" );
#;

9.6	Restrict domains of user which joins a mailing list

$REGISTRATION_ACCEPT_ADDR can restrict registration to e.g. we permit
only persons in some domains can join this mailing list.
Please see it (this section may be of no use after this).

Several hooks are available to enable a lot of exceptional functions.
To permit only users on permit_domain.co.jp can join this list, you
can use $START_HOOK.

$START_HOOK = q#
   if ($From_address !~ /permit_domain\.co\.jp$/i) {
	&Mesg(*Envelope, 
	   "We permit user@*permit_domain.co.jp can join this list.");
	$DO_NOTHING = 1;
   }
#;

	$DO_NOTHING = 1		do not run the main routine
				* distribute
				* automatic registration
				and other almost all functions

   if ($From_address !~ /permit_domain\.co\.jp$/i) {

is "addresses(From: address) which do not match permit_domain.co.jp".

   if ($Envelope{'h:sender:'} !~ /permit_domain\.co\.jp/i) {

is "Sender: does not contains permit_domain.co.jp string".

9.7	Example: "automatic registration" and "restrict members who can post"

$REJECT_COMMAND_HANDLER can have a value 'auto_asymmetric_regist'. If
defined, FML uses delivery list controlled by automatic registration
and authentication list edited by hand (or makefml).

make "elena" and "elena-regist" ML.

	elena		only for post (by hand or makefml)
	elena-regist	only for commands

	elena-regist/members	distribution list (automatic registration)
	elena/members		authentication list (by hand or makefml)

We use "elena-regist" for automatic registration to add
"elena-regist/members". "elena" ML uses plural distribution lists,
"elena/actives", "elena-regist/members".

   [Example of flow]

	% makefml newml elena
	% makefml newml elena-regist
	% cd /var/spool/ml/elena-regist
	% cp include-ctl include

	*** edit /etc/aliases

	% cd /var/spool/ml/elena
	% makefml edit elena cf

	*** edit cf file to append "elena-regist/members" to @ACTIVE_LIST.

	ACTIVE_LIST	/var/spool/ml/elena-regist/members

	recreate config.ph

	% make config.ph
	% makefml add elena postable-member-address-1
	% makefml add elena postable-member-address-2
	.....

[Discussion]

[Discussion]
FML cannot lock elena-regist ML in default but works well I believe:)

9.8	%DOMAIN_ALIASES when authentication

When FML authenticates From: address as a member or not, FML tries
both who@ujauja.or.jp and who@ujauja.ne.jp.

%DOMAIN_ALIASES = (
	);

An example of a patch for fml.pl 2.0.24.47

--- fml.pl.org	Fri Nov 21 08:11:10 1997
+++ fml.pl	Sat Nov 22 12:51:33 1997
@@ -571,6 +571,19 @@
     &Log("Gecos [$e{'macro:x'}]") if $debug;
     $e{'Addr2Reply:'}    = &Conv2mailbox($e{'h:reply-to:'},*e)||$From_address;

+    if (%DOMAIN_ALIASES) {
+       local($addr);
+	if (&MailListMemberP($From_address)) {
+	    ; # not rewrite
+	}
+	else {
+	    for (keys %DOMAIN_ALIASES) {
+		if ($From_address =~ /$_$/i) {
+                   $addr = $From_address;
+		    $addr =~ s/$_$/$DOMAIN_ALIASES{$_}/i;
+                   &MailListMemberP($addr) && ($From_address = $addr);
+		}
+	    }
+	}
+    }
+
     # To: $MAIL_LIST for readability;
     # &RewriteField(*e, 'Cc') unless $NOT_REWRITE_CC;
     if ($REWRITE_TO < 0) { 

9.9	How severely FML checks the validity of the address

* How severely fml.pl checks address syntax
please see address_manipulate 2.1 for $ADDR_CHECK_MAX.

9.10	$MAINTAINER

Roughly speaking $MAINTAINER is an address which a user contacts ML
maintainers with and error mails returns to. In default fml.pl sets up
listname-admin and listname-request for listname ML. fml.pl uses
listname-admin as a maintainer address and prepares listname-request
as an alias. Historically it is good for you to prepare
listname-request also.

However some ISP services cannot provide listname-request or
listname-admin. Please consult with your ISP around on this point.

	@MEMBER_LIST = (
			);
	@ACTIVE_LIST = (
			);

We accept opinions by mail from anyone and send back the reply "thank
you for your opinion" to the sender.

object:
return guide if fml receives post from the member.

config.ph configuration Example 1:

1. permit post from anyone
2. add $START_HOOK to send back "guide"

    ### sample configuration ###
    $PERMIT_POST_FROM              = "anyone";
    
    # YOU CAN EDIT MANUALLY AFTER HERE.
    $START_HOOK = q# 
       if (! &MailListMemberP($From_address)) { &GuideRequest(*Envelope);} 
    #;

config.ph configuration Example 2:
return another file not guilde with the header:

From: $MAIL_LIST
Subject: Thanks you for your mail

    ### sample configuration ###
    $PERMIT_POST_FROM              = "anyone";
    
    # YOU CAN EDIT MANUALLY AFTER HERE.
    $RECRUIT_ACK_STATEMENT = "Thanks you for your mail";
    $RECRUIT_ACK_FILE      = "$DIR/recruit_reply";
    
    $START_HOOK = q#
        if (! &MailListMemberP($From_address)) {
    	&DEFINE_FIELD_OF_REPORT_MAIL('From', $MAIL_LIST);
            &SendFile($From_address, $RECRUIT_ACK_STATEMENT, $RECRUIT_ACK_FILE);
        }
    #;

9.13	One recipient for plural addresses to post mails from

When one recipient for plural addresses to post mails from, you can
write 

	# address

format in member or delivery lists. In this comment out style fml.pl
uses it as an authentication candidate but not delivers articles to
it. If the list follows

	# addr1
	# addr2
	# addr3
	addr4

Fml delivers mail to addr4 not addr1,addr2,addr3 but accepts post
from addr1,addr2,addr3,addr4.

9.14	Set up listname-request as a command address

   1 set up listname-request to run fml.pl with command mode

	elena-request: :include:/var/spool/ml/elena/include-ctl

   The content of file elena-request is such as

	"|/usr/local/fml/fml.pl /var/spool/ml/elena --ctladdr"

2	FML distribution article has information of commands in the header.
	Please set 

	$CONTROL_ADDRESS       = "elena-request\@$DOMAINNAME";

In config.ph. If $MAINTAINER is the same as $CONTROL_ADDRESS, please
change it to different one. In default it is o.k. since $MAINTAINER is
listname-admin.

$Id: examples.wix,v 1.3 2000/12/10 04:14:40 fukachan Exp $


		INDEX

$AUTO_REGISTERD_UNDELIVER_P                ...   4.12 5.12 
$AUTO_REGISTERED_UNDELIVER_P               ...   4.12 5.12 
$AUTO_REGISTRATION_DEFAULT_MODE            ...   4.16 5.16 
$AUTO_REGISTRATION_HOOK                    ...   4.17 5.17 
$AUTO_REGISTRATION_KEYWORD                 ...   4.6 5.6 
$AUTO_REGISTRATION_TYPE                    ...   4.6 5.6 
$AUTO_REGISTRATION_TYPE                    ...   4.5 5.5 
body                                       ...   4.5 5.5 
$COMMAND_CHECK_LIMIT                       ...   7.4 7.5 
&Confirm                                   ...   4.10 5.10 
$CONFIRM_REPLAY_SUBJECT_FUNCTION           ...   4.10 5.10 
$CONFIRM_REPLAY_TEXT_FUNCTION              ...   4.10 5.10 
confirmation                               ...   4.5 5.5 
$CONFIRMATION_ADDRESS                      ...   4.9 5.9 
$CONFIRMATION_EXPIRE                       ...   4.9 5.9 
$CONFIRMATION_FILE                         ...   4.9 5.9 
$CONFIRMATION_KEYWORD                      ...   4.9 5.9 
$CONFIRMATION_LIST                         ...   4.9 5.9 
$CONFIRMATION_RESET_KEYWORD                ...   4.9 5.9 
$CONFIRMATION_SUBSCRIBE                    ...   4.9 5.9 
confirmation mode                          ...   4.9 5.9 
$CONTROL_ADDRESS                           ...   8.1 9.14 
$DEFAULT_SUBSCRIBE                         ...   4.6 5.6 
distribute-only                            ...   7.3 
$FILE_TO_REGIST                            ...   4.1 5.1 
$MAIL_LIST                                 ...   7.3 
$MAINTAINER                                ...   9.10 
$MANUAL_REGISTRATION_CONFIRMATION_FILE     ...   3.1 
$MANUAL_REGISTRATION_TYPE                  ...   3.1 
$MEMBER_LIST                               ...   4.1 4.11 5.1 5.11 
@MEMBER_LIST                               ...   4.11 5.11 
$ML_MEMBER_CHECK                           ...   4.1 5.1 
no-keyword                                 ...   4.5 5.5 
noskip                                     ...   9.13 
$PERMIT_COMMAND_FROM                       ...   7.1 
$PERMIT_POST_FROM                          ...   7.1 
$REGISTRATION_ACCEPT_ADDR                  ...   4.3 5.3 
$REJECT_COMMAND_HANDLER                    ...   7.1 
$REJECT_POST_HANDLER                       ...   7.1 
s=skip                                     ...   4.14 5.14 
%SKIP                                      ...   9.1 
skip                                       ...   4.14 5.14 9.1 9.13 
$START_HOOK                                ...   9.1 
subject                                    ...   4.5 5.5 
UNIX_FROM                                  ...   9.10 
$WELCOME_FILE                              ...   4.1 5.1 
