I’m looking to replace my current hosting server with virtualmin, So I have built a new etch debian server with the webmin and virtualmin and run the install.sh, the machine is on a local dchp network.
I have created a virtual server with a single user. To start with I have wanted to test the email server. I used outlook and configured pop / smtp. I have successfully sent email through smtp using auth, but I have not managed to get pop to login.
When I telnet localhost pop3 there is an OK from dovecot on username but no response after supplying the password. No errors are generated in the mail or auth logs until the connection times out.
Does this sound like a common mistake that I’ve made? which user authorisation method should dovecot be using?
Outlook is vicious when it comes to troubleshooting email problems. Once a login has failed even once for a particular account, Outlook will never attempt to login again. I have no idea why the Outlook folks though this was a good (or even marginally acceptable) idea…but it’s the way Outlook behaves, so you’ve gotta deal with it.
I would recommend testing with a more sane mail client until everything is working correctly, and then ask Outlook (politely) to try connecting. But you’ll probably have to reboot your system to convince Outlook to actually try again. I’m sure there must be some way to convince it to try again, but I’ve never been able to figure it out (though I am, admittedly, an idiot when it comes to Windows boxes).
In short, if you don’t see errors in the log, then the client isn’t actually trying to login. And we’ll need to see errors to know what is going wrong.
I have tried logging into dovecot on pop3 over telnet and here is what i did and the logs generated. As you can see that dovecot doesnt respond to the password and times out.
Kind regards
Leigh
virtualhost:~# telnet localhost pop3
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
+OK Dovecot ready.
user test
+OK
pass 123456
Connection closed by foreign host.
==> /var/log/auth.log <==
May 8 11:15:01 virtualhost CRON[3237]: (pam_unix) session opened for user root by (uid=0)
May 8 11:15:04 virtualhost su[3260]: Successful su for postgres by root
May 8 11:15:04 virtualhost su[3260]: + ??? root:postgres
May 8 11:15:04 virtualhost su[3260]: (pam_unix) session opened for user postgres by (uid=0)
May 8 11:15:04 virtualhost su[3260]: (pam_unix) session closed for user postgres
May 8 11:15:04 virtualhost CRON[3237]: (pam_unix) session closed for user root
So how did you install Dovecot? (And what OS/version are you running?)
The defaults found in the packages provided by most Linux distros is sane, and Just Works. But, maybe if it’s trying to do something dumb like use ntlm or cram-md5 or something, that might cause trouble…but I would think the log would indicate it. I really don’t know what to tell you, as I’ve never seen this behavior from Dovecot. It’s one of the aspects of the product that we never think about because it always works and we don’t have to do much configuration during installation (we set the mail location to ~/Maildir, and we make sure all of the relevant protocols are turned on…that’s pretty much the entirety of our configuration process on most Linux systems).
This turned out to be straight forward I switched the password authentication to "Unix shadow file" rather the "default PAM server (dovecot)" that is was on.