I am running Ubuntu 8.04.04 with virtualmin 3.76 which I installed by install.sh (on an almost fresh installation - packages had been installed but were then purged)
I am having problems with connecting mail clients to the server. SMTP, pop and imap are all running but receive authentication errors. Usermin can login and send/receive email fine.
I have worked through the steps listed in previous threads with no joy so far - I will list some of the commands logs requested in those to see if anyone can spot the issue.
grep mail_location /etc/dovecot/dovecot.conf
# path given in the mail_location setting. # mail_location = maildir:~/Maildir # mail_location = mbox:~/mail:INBOX=/var/mail/%u # mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n #mail_location = mail_location = maildir:~/Maildir # namespaces completely, they use only the mail_location setting. # explicitly, ie. mail_location does nothing unless you have a namespace # mail_location, which is also the default for it. # converted to destination storage (mail_location) when the user logs in. #
/var/log/mail.log
Feb 4 02:15:01 ds7132 postfix/pickup[13591]: 8F6C131844F: uid=0 from=<root> Feb 4 02:15:01 ds7132 postfix/cleanup[13758]: 8F6C131844F: message-id=<20100204021501.8F6C131844F@ds7132.dedicated.turbodns.co.uk> Feb 4 02:15:01 ds7132 postfix/qmgr[13593]: 8F6C131844F: from=<root@ds7132.dedicated.turbodns.co.uk>, size=994, nrcpt=1 (queue active) Feb 4 02:15:01 ds7132 postfix/local[13772]: 7C99F318452: to=<alias@ds7132.dedicated.turbodns.co.uk>, orig_to=<root>, relay=local, delay=0.23, delays=0.08/0.01/0/0.14, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrap$ Feb 4 02:15:01 ds7132 postfix/qmgr[13593]: 7C99F318452: removed Feb 4 02:15:01 ds7132 postfix/local[13779]: 8A50531844E: to=<alias@ds7132.dedicated.turbodns.co.uk>, orig_to=<root>, relay=local, delay=0.26, delays=0.1/0.03/0/0.13, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrapp$ Feb 4 02:15:01 ds7132 postfix/qmgr[13593]: 8A50531844E: removed Feb 4 02:15:01 ds7132 postfix/local[13772]: 8F6C131844F: to=<alias@ds7132.dedicated.turbodns.co.uk>, orig_to=<root>, relay=local, delay=0.29, delays=0.09/0.11/0/0.09, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrap$ Feb 4 02:15:01 ds7132 postfix/qmgr[13593]: 8F6C131844F: removed Feb 4 02:17:42 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:17:42 ds7132 last message repeated 8 times Feb 4 02:17:42 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:17:42 ds7132 last message repeated 4 times Feb 4 02:17:43 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:17:43 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:17:43 ds7132 last message repeated 4 times Feb 4 02:17:47 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:17:47 ds7132 last message repeated 4 times Feb 4 02:17:48 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:17:48 ds7132 last message repeated 4 times Feb 4 02:17:56 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:17:56 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:17:56 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:17:56 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:18:01 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:18:01 ds7132 last message repeated 4 times Feb 4 02:18:01 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:18:01 ds7132 last message repeated 4 times Feb 4 02:18:04 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:18:04 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:18:04 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:18:04 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:18:05 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:18:06 ds7132 last message repeated 4 times Feb 4 02:18:06 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:18:06 ds7132 last message repeated 4 times Feb 4 02:18:09 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:18:09 ds7132 last message repeated 4 times Feb 4 02:18:09 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:18:09 ds7132 last message repeated 4 times Feb 4 02:18:12 ds7132 dovecot: imap-login: Login: user=<test.upgradeconsulting>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Feb 4 02:18:12 ds7132 last message repeated 4 times Feb 4 02:18:12 ds7132 dovecot: IMAP(test.upgradeconsulting): Connection closed Feb 4 02:18:12 ds7132 last message repeated 4 times Feb 4 02:19:31 ds7132 dovecot: pop3-login: Disconnected: user=<test.upgradeconsulting.co.uk>, method=PLAIN, rip=119.42.97.146, lip=94.136.50.205, TLS Feb 4 02:27:37 ds7132 postfix/qmgr[13593]: CB744318400: from=<www-data@dedicated.turbodns.co.uk>, size=4537, nrcpt=1 (queue active) Feb 4 02:27:40 ds7132 postfix/smtp[14340]: connect to dedicated.turbodns.co.uk[194.154.164.129]:25: Connection refused Feb 4 02:27:40 ds7132 postfix/smtp[14340]: CB744318400: to=<sales.thelondonminibuscompany@dedicated.turbodns.co.uk>, orig_to=<sales@thelondonminibuscompany.co.uk>, relay=none, delay=47240, delays=47237/0.08/3/0, dsn=4.4.1, status=defer$ Feb 4 02:30:01 ds7132 postfix/pickup[13591]: EAD2D318452: uid=0 from=<root> Feb 4 02:30:02 ds7132 postfix/cleanup[14376]: EAD2D318452: message-id=<20100204023001.EAD2D318452@ds7132.dedicated.turbodns.co.uk> Feb 4 02:30:02 ds7132 postfix/qmgr[13593]: EAD2D318452: from=<root@ds7132.dedicated.turbodns.co.uk>, size=1142, nrcpt=1 (queue active) Feb 4 02:30:02 ds7132 postfix/pickup[13591]: 0416B31844E: uid=0 from=<root> Feb 4 02:30:02 ds7132 postfix/cleanup[14376]: 0416B31844E: message-id=<20100204023002.0416B31844E@ds7132.dedicated.turbodns.co.uk> Feb 4 02:30:02 ds7132 postfix/qmgr[13593]: 0416B31844E: from=<root@ds7132.dedicated.turbodns.co.uk>, size=1002, nrcpt=1 (queue active) Feb 4 02:30:02 ds7132 postfix/pickup[13591]: 21671318453: uid=0 from=<root> Feb 4 02:30:02 ds7132 postfix/cleanup[14376]: 21671318453: message-id=<20100204023002.21671318453@ds7132.dedicated.turbodns.co.uk> Feb 4 02:30:02 ds7132 postfix/qmgr[13593]: 21671318453: from=<root@ds7132.dedicated.turbodns.co.uk>, size=994, nrcpt=1 (queue active) Feb 4 02:30:03 ds7132 postfix/local[14381]: EAD2D318452: to=<alias@ds7132.dedicated.turbodns.co.uk>, orig_to=<root>, relay=local, delay=1.9, delays=0.08/0.02/0/1.7, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrappe$ Feb 4 02:30:03 ds7132 postfix/qmgr[13593]: EAD2D318452: removed Feb 4 02:30:03 ds7132 postfix/local[14381]: 21671318453: to=<alias@ds7132.dedicated.turbodns.co.uk>, orig_to=<root>, relay=local, delay=1.7, delays=0.07/1.6/0/0.05, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrappe$ Feb 4 02:30:03 ds7132 postfix/qmgr[13593]: 21671318453: removed Feb 4 02:30:03 ds7132 postfix/local[14386]: 0416B31844E: to=<alias@ds7132.dedicated.turbodns.co.uk>, orig_to=<root>, relay=local, delay=1.9, delays=0.08/0.04/0/1.8, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrappe$ Feb 4 02:30:03 ds7132 postfix/qmgr[13593]: 0416B31844E: removed
/var/log/auth.log extract
Feb 4 02:19:17 ds7132 dovecot-auth: pam_unix(dovecot:auth): check pass; user unknown Feb 4 02:19:17 ds7132 dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=test.upgradeconsulting.co.uk rhost=119.42.97.146 Feb 4 02:19:20 ds7132 dovecot-auth: pam_unix(dovecot:auth): check pass; user unknown Feb 4 02:19:20 ds7132 dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=test.upgradeconsulting.co.uk rhost=119.42.97.146
/etc/passwd extract
test.upgradeconsulting:x:10**:10**::/usr/fs/home/upgradeconsulting/homes/test:/dev/null
I have set permissions of /var/spool/postfix/var/run/saslauthd directory.
made sure that postfix is in the sasl group by running this: usermod -a -G sasl postfix
/etc/init.d/saslauthd restart /etc/init.d/postfix restart /etc/init.d/dovecot restart
Another unrelted issue is that the mail queue keeps filling up with messages from root@dedicated.turbodns.co.uk to root@dedicated.turbodns.co.uk with mail content
Can't locate FindBin/libs.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
/usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
/usr/local/lib/site_perl .) at /usr/local/controlpanel/cronjobs/qmail.pl line 5.
BEGIN failed--compilation aborted at /usr/local/controlpanel/cronjobs/qmail.pl line
5.
my server is servxxxx.dedicated.turbodns.co.uk so obviously root@dedicated.turbodns.co.uk doesnt exist on this system - how would I change the email that cron errors are sent from/to to something I can actually use and check?
One more thing I forgot to mention - A PHP mailer script on the website using either mail.domain.co.uk or localhost as the smtp server gives the errors
SMTP -> ERROR: Failed to connect to server: Connection refused (111) SMTP Error: Could not connect to SMTP host. Mailer Error: SMTP Error: Could not connect to SMTP host.SMTP -> ERROR: Failed to connect to server: Connection refused (111) SMTP Error: Could not connect to SMTP host. Mailer Error: SMTP Error: Could not connect to SMTP host.
So its not just remote authentication failing - however usermin works fine.
Also the mail() command in PHP was working but outlook was displaying html messages (with correct looking headers) as plain text. Thunderbird displayed the mail fine.
Telnet direct to the server works sending to local addresses but refuses relay. AUTH LOGIN via telnet fails using the same email and password as usermin.
I dont know if it is related but the first command in telnet, whether HELO or anything else fails with 502 5.5.2 Error: command not recognized Typing the same command again works.
Howdy,
Hrm, it kind of sounds like something about your previous setup may be causing some trouble, but let's see what we can figure out :-)
how would I change the email that cron errors are sent from/to to something I can actually use and check?
Well, what I'd typically recommend is making root an alias that forwards to your primary email account. I'd typically set that up in /etc/aliases.
And then, that wouldn't fix just cron emails, but anything going to root.
Alternatively, you can set the MAILTO variable in the crontab file, with the email address to send cron output to (see "man 5 crontab" for more info).
However, viewing the above output, it appears that at some point, you were using Qmail? Is it possible Qmail is still running and interfering with Postfix?
Regarding logging into dovecot using POP/IMAP -- the above output suggests that the username it's attempting to authenticate is "test.upgradeconsulting.co.uk". However, it looks like the actual username is just "test.upgradeconsulting".
Are you sure that the username is correct in your email client?
-Eric
Have made the ailias adjustment and havent received any more messages stuck in the queue so fingers crossed on that.
With qmail I found that it was still installed so have purged that. qmail-run is still listed in dpkg -l but says that it isnt installed when I try and remove it again.
I also noticed that courier is still installed - could this be conflicting as well or does virtualmin use it?
With the email - I definitely have it set with the co.uk I have also tried a few variations which have worked with different providers. user@domain.co.uk user.domain.co.uk user
I tried all of the above manually using telnet too.
Just a thought, I had previously managed to get locked out of ssh by being added to the hosts.deny - does postfix etc have its own blacklists that are worth checking?
Howdy,
Virtualmin uses Dovecot by default, so if Courier is running or it's installation had somehow affected your systems config, that could be a potential problem.
For the username -- according to your /etc/password entry, the username to use would be "test.upgradeconsulting". I'd make sure whatever you're logging in as exists in /etc/passwd.
As far as getting locked out -- there aren't any default installed daemons that would automatically lock you out after N failed login attempts. If you get locked out, there's a custom installed program, daemon, or pam entry that's causing that.
For example, SSH won't lock you out unless something's been changed to cause it to do so... usually through a third-party tool such as denyhosts.
So, it's possible that there could be a tool that was installed onto your system that blocks a POP/IMAP user after some number of unsuccessful logins, but that's not a typical setup, so it's hard to say :-)
-Eric
Thanks for your help so far, has got it partially working Changing the username to test.upgradeconsulting worked for pop access.
Is there a global setting I can change so that the more logical user@domain.ext or even user.domain.ext is translated to the internal username?
I could change the usernames manually but that defeats the purpose of having virtualmin for easy setup, virtualmin is automatically dropping the TLD from the user.
With SMTP I am managing to authenticate but am getting the following error. An error occurred while sending mail. The mail server responded: 5.7.1 mark@innerspaceproductions.co.uk: Relay access denied. Please check the message recipient mark@innerspaceproductions.co.uk and try again.
In SMTP authentication and Encryption I have "allow authenticated clients" ticked under relaying restrictions, along with "allow connections from the same network" and (which I just noticed) "Reject email to other domains" I unchecked "Reject email to other domains" (This will allow unauthenticated relaying right? Needs to be switched off when working?)
And now I get Sending of message failed. The message could not be sent because the connection to SMTP server mail.upgradeconsulting.co.uk timed out. Try again or contact your network administrator.
I have seen in "SMTP server options" Error count for temporarily ignore a client which was set to 10 I have upped that to 100 for testing but may have already hit that limit.
I found this related thread with almost identical problems to mine, but unfortunately no confirmed answer. http://www.virtualmin.com/node/9026
That indicates the file /etc/postfix/virtual Which correctly has the email address followed by the system username
Also there is the link to it in postconf -n
This suggests to me that I should be able to log in with an email rather than just a unix username, unless these settings are being overridden somewhere.
The last post by the OP of that thread was making the same checkbox changes that I just have which removed the relay error but didnt send the email (or maybe it did since they didnt return to the thread)
Unfortunately I am still receiving timeouts on smtp so not sure if this will work for me.
Howdy,
First, before we get too much further... it seems like you're running into a lot of problems due to your previous packages you had setup there.
If your server isn't running anything "live" now, you might save yourself some hassle by working with a fresh install of Ubuntu.
That said, these things should all be fixable, so some thoughts on the problems you're seeing --
Could you run a "ps auxw", and attach the output as a file to this thread? I'd like to see what all is running on your server and make sure it looks normal.
A possible cause of mail server timeouts could be due to DNS lookups hanging. Are the nameservers setup in /etc/resolv.conf correct?
Whenever your mail server times out, do you see any errors in /var/log/mail.log?
What about when you restart Postfix -- does it generate any errors at that point?
Are you sure that the saslauthd daemon is running? You can launch it with: /etc/init.d/saslauthd restart
-Eric
Ok 3rd time lucky.
I fixed this issue - mail logs indicated that the smtp service was down since I had unchecked too many boxes.
I rechecked "Reject email to other domains" and kept "allow connections from the same network" checked and it worked.