To explain some of these problems: > > PMFJI, but I have also just struck trouble with virtual mail to > virtual domains. > This is using freevsd 1.4.9-2, a self-generated skel from the > RH6.2 host, and > the 1.4.9-2 package of rpm's added. Everything goes well most of > the way, ie > I created a new virtual server, created 3 test domains on it, > created and enabled > users for these as per the docs. Testing by bevs'ing to the new VS and > sending mail, as per the docs, worked. > > Problems: > 1/ Can't collect mail using a normal mail client, as the > /etc/virtual/domain.net/passwd > file is thought to be .../domain/.. by vm-pop3d, ie without the > .net suffix, and so > ...passwd "does not exist". Creating a symlink works as a > "hackish" solution. > > Also, there needs to be a symlink, for the same reason, on > /var/spool/virtual/domain.net -> domain >
This is not something I have previously seen in any testing but sounds like a problem in vm-pop3d. I will see if I can duplicate it.... > 2/ Sendmail thinks that the virtual users don't exist, despite > vuser_list showing that they > do and sending test mail from within the VS arriving where is should. > As explained in my previous mail, Sendmail does not play a very significant part in the current freeVSD virtual mail implmentation. Configuration relating to virtual users (forwarders/reponders etc) are held in procmail recipes beneath /etc/procmailrcs/virtual/<domain>/... Sendmail will have absolutely no awareness of the virtual users as they do not feature in any Sendmail configuration files. > 3/ Procmail, after the "unknown user" msg, returns this mail to > admin@the_new_VS, rather > than admin@the_sending_domain. > Check out the procmail recipe structure beneath /etc/procmailrcs (also see man procmail and man procmailrc for more background). The recipe file basically acts like a long switch/case statement with the default delivery destination being the admin@<domain>. When a non-matching user is received it will eventually fall through all the checks and end up in the admin@<domain> account, as you describe. It would not be much work to improve the recipe to actually respond to the sender of the incorrectly addressed message as well - I just didn't go as far as implementing that at this stage in the freely available skels. There are all sorts of possiblities available through procmail for filtering/responding/preventing spam etc. and the module is written to be very flexible and extendable to take account of this. Any procmail recipe suggestions or additions would be more than welcome... Tim ------------------------- The freeVSD Support List -------------------------- Subscribe: mailto:[EMAIL PROTECTED]?body=subscribe%20freevsd-support Unsubscribe: mailto:[EMAIL PROTECTED]?body=unsubscribe%20freevsd-support Archives: http://freevsd.org/support/mail-archives/freevsd-support -----------------------------------------------------------------------------
