Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have an issue where postfix is setup to use dovecot auth and as far as I know it works, if i login using telnet to the mail server i can authorize myself y providing the base64 encoded user & password. so if i can login, why cant my email clients. have tried thunderbird and evolution.
this is the mail.log relavant entries for sucessful login via telnet
Code:
May 13 23:30:26 horus postfix/smtpd[15207]: NOQUEUE: reject: RCPT from unknown[121.98.152.54]: 554 5.7.1 <cole@devtest.co.nz>: Relay access denied; from=<info@coachingineffectivespeaking.org> to=<cole@devtest.co.nz> proto=ESMTP helo=<host>
May 13 23:30:58 horus postfix/smtpd[15207]: D2354205CA: client=unknown[121.98.152.54], sasl_method=plain, sasl_username=info@coachingineffectivespeaking.org
Login by pop or imap works flawlessly that what i dont get. From what i see it SHOULD be working.
It it changes things, im using postfixadmin, postfix, dovecot. passwords and info stored in mysql tables. passwords are md5 encrypted. I thought that may be the issue, but that dosnt make sence.
My best guess is that the email client is not encoding the details corectly.
Looking at that it's complaining about the password (UGFzc3dvcmQ6).
So to be clear, you can log in by hand to your Postfix using telnet/nc > ehlo > then either a single plain string |OR| auth login base64 username,base64 password and that works without an issue?
I had some 'fun' with Evolution myself having some odd behaviour insofar as setting it up by hand randomly gave issues with the password. In the preferences > mail accounts [select account] > sending email tab, clicking on the 'check supported types' and then either selecting 'login' or 'plain' (even though they were already selected) and UNCHECKING the 'remember password' seemed to fix it. It then prompted for the password (which you can then check the 'remember' box) and worked flawlessly. No understanding why, but it seems to have a bit of a sticky memory for bad login data. I don't know if that is your issue but I can assure you Postfix SASL/AUTHSMTP works flawlessly with Dovecot and you can check for Postfix offering support for Dovecot with:
Code:
postconf -a
{output...>}
cyrus
dovecot
The relevant section of main.cf looking something like this:
Don't get hung up with the MD5 passwords. I'm guessing that you are storing user info in a MySQL database. When the Dovecot library looks up the password for auth it is only doing a comparison. It checks what has been entered against what the database returns using the relevant 'cipher' set in 'default_pass_scheme':
EG:
--
Quote:
dovecot-sql.conf
# Default password scheme
default_pass_scheme = PLAIN-MD5
# passdb query to retrieve the password. It can return fields:
password_query = SELECT username AS user, userpassword AS password FROM users WHERE username like '%u';
I should note that i had everything set up and working prior to incorporating mysql.
UGFzc3dvcmQ6 : I have no idea how this value is come around. the password for the account i was using is infoinfo and the encoded password i used in telnet was different again.
UGFzc3dvcmQ6 is base64 for 'Password:' - that is, just the prompt not the actual password. On login you are normally prompted: VXNlcm5hbWU6 (Username UGFzc3dvcmQ6 (Password. With PLAIN you won't see this prompting as you are entering a single string following the auth plain command.
I note your comment regarding "It was working before mysql" but if you can manually log in from the command line using nc/telnet and the auth is successful the issue has to be the client or data supplied to it. You can enable full logging in Dovecott with 'auth_verbose=yes' in the conf. This will allow you to view the the log in data being passed to, and queried by, Dovecot in the logs. Hence how I found that Evolution was actually passing the wrong data.
Thanks for your help, I resolved the issue on the first server (I didn't mention it was happening on two)
The problem turned out to be ail clients (Thunderbird and evolution) providing the incorrect details. But from a human error, mis spelled a really long domain, twice.
On the second server however, after enabling logging, postfix is attempting to use a Berkley DB, even though smtpd_sasl_type=dovecot and path=private_auth
Any ideas on what to check here? (Unable to telnet this server)
Probably the trickiest part of that is the location of the socket to Dovecot (In my case: private/auth). Obviously search main.cf to make sure you don't redefine any of these later in the file.
Next your dovecot.conf file should have something that looks like this towards the end (path to the socket must match above and note this file includes in the actual SQL calls from the file '/etc/dovecot/dovecot-sql.conf')
Quote:
auth default {
mechanisms = plain login
passdb sql {
# Path for SQL configuration file
args = /etc/dovecot/dovecot-sql.conf
}
userdb sql {
# Path for SQL configuration file
args = /etc/dovecot/dovecot-sql.conf
}
socket listen {
client {
#
path = /var/spool/mail/private/auth
mode = 0660
# Assuming the default Postfix user and group
user = postfix
group = postfix
}
}
}
Your own 'dovecot-sql.conf' will be different to suit your database structure, but will probably look something like this:
Quote:
# This file is opened as root, so it should be owned by root and mode 0600.
driver = mysql
connect = host=127.0.0.1 dbname=<your-database-name> user=<your-database-user> password=<your-database-password>
# Default password scheme
default_pass_scheme = PLAIN-MD5
password_query = SELECT email AS user, userpassword AS password FROM users WHERE email like '%u';
user_query = SELECT mailbox AS home, virtual_uid AS uid, virtual_gid AS gid FROM users where email = '%u';
With that in place, and a working database to deal with the queries, you should be cooking on gas.
Thanks for the reply. I wasnt able to find anything out of place in either config file. (Dovecot config file is so much easier to navigate without comments - Thank you Internet) So i figured i would copy the config from the good server to the no-good server. change the relavant hostnames etc and got to a point where i could troubleshoot the rest myself. Now i working on tls and ssl integration for both. And its all pretty straightforward.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.