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@virtualdomainThe following two syntaxes are acceptable for the default domain.
% makefml newml mlname@defaultdomain % makefml newml mlnameFml 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 addressInstead, 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
| Warning |
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. |
Copyright (C) 1993-2022 Ken'ichi Fukamachi mail:< fukachan at fml.org >