2003/10: We enhanced fml8 to handle virtual domains as same way as default domain. It is difficult to handle virtual domains and the default domain in the same way. One proper enhancement is using "user@domain" form for the ML name as an argument of commands. For example, for a virtual domain, use makefml like this % makefml newml mlname@virtualdomain The following two syntaxes are acceptable for the default domain. % makefml newml mlname@defaultdomain % makefml newml mlname Fml treats these properly as could as possible. But fml needs some hints such as ml home directory information for each domain. You need to prepare /usr/local/etc/fml/ml_home_prefix file for a hint on mappping between domain and directory. This file name is defined as $ml_home_prefix_maps (formerly $virtual_maps) in main.cf. $virtual_maps is obsolete but effective now for compatibility. To handle $ml_home_prefix_maps, you can use "makefml newdomain" and "makefml rmdomain". It is easy in use. For the first time to use a virtual domain, run "newdomain" command to add {domain => directory} relation to ml_home_prefix_maps (precisely primary_ml_home_prefix_map). After that, you can use "user@domain" form in makefml arguments in handling virtual domains. makefml newml ML@virtualdomain makefml add ML@virtualdomain address makefml bye ML@virtualdomain address Instead, for the default domain, definitions in ml_home_prefix_maps is not needed and either of user and user@domain is accpetable. When you use CGI, you need not to use user@domain syntax since config.cgi knows the domain name the cgi handles. http://lists/~fml/cgi-bin/fml/$domain/admin/config.cgi The domain name is hard-coded within config.cgi since makefml injects the domain name in creating config.cgi when "makefml newml" runs. That is, "config.cgi" does not resolve its domain by the URL. *** SORRY, NOT YET WRITTEN ***.