From Netvigator on Fri, 20 Aug 1999
I recently install RH6 and use linuxconf to add virtual email domain as well as POP3 account. I test it with sending email to that virtual email domain and sucessfull without returning mail. However, I cannot retrieve mail using POP3. Can you give me any idea about that ? (The DNS setup is OK since the Web virtual domain can function properly).
When you send mail to the account into which you are funneling this virtual e-mail domain traffic, is the spool file created under /var/spool/mail/?
Is it a normal mbox file (a text file with a series of e-mail messages concatenated together, delimited by lines of the form ^From ....*)?
Does your POP daemon work for any of your other accounts?
What mail client are you using? Does 'fetchmail' work when you use it to fetch your POP mail from localhost?
Are there any messages in /var/log/messages that might be related to any of this?
You'll have to at least isolate the problem to the MTA (mail transport agent, presumably sendmail) or the MSA (mail storage agent: presumably UW's IMAP/POP3 daemon package), or the client/delivery agents (procmail, fetchmail, or whatever you're using).
Once you've isolated a problem down to the relevant subsystem you can then work on isolating it to a specific operation. Is your POP3 daemon being started by TCP wrappers, tcpd (almost certainly)? Is tcpd preventing the access from your client (quite a common problem)?
The fact that this is being done through linuxconf doesn't offer me any clues. I've only played with linuxconf very briefly, and so far I don't like it and wouldn't trust it to set up a virtual e-mail domain.
Is it generating a .mc file for sendmail? I don't want to see a sendmail.cf --- those are too long and too tedious to read. However, if the mbox file(s) are being properly created under /var/spool/mail as you expect then you don't need to worry about the MTA at all.
Incidentally, the fact that your virtually hosted web server works doesn't actually eliminate the possibility of DNS problems. It could be that you have MX records pointing to never-never-land. Those would take precedence over the A records (which are all that are required for web browsers to resolve your server's IP address).
Try doing a bit of troubleshooting to isolate the symptoms in more detail. That will probably make the problem more clear and suggest a solution.