NONE TITLE 3.html
Keywords: NONE TITLE,fml, flexible mailing list manager, not listserv style but fmlserv emulates listserv or majordomo style

[PREVIOUS CHAPTER] [NEXT CHAPTER]

3 Registration

    Technical Terms => ../Glossary 1.3
    See 5.0 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.0 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

[PREVIOUS CHAPTER] [NEXT CHAPTER]