It is difficult to handle virtual domains and the default domain in the same way. You can use "user@domain" as an argument if needed, for example, ambiguous. So, use "user@domain" form for the ML name if it is an ML of a virtual domain. For example, for a virtual domain, use makefml like this % makefml newml mlname@virtualdomain but both 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. You need to prepare /usr/local/etc/fml/virtual file for a hint on mappping between domain and directory. This file name is defined as $virtual_maps in main.cf. It is easy in use. Edit /usr/local/etc/fml/virtual file and define it as $virtual_maps in main.cf. 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, 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. "config.cgi" does not resolve its domain by URL. NOT YET WRITTEN.