I don't know how to answer to the 2nd question. I assume MySQL login is fine, otherwise it didn't work in first place for 1 month. I didn't do any upgrade or update to packages since the install. The MySQL user that Postfix is using is mail_admin.

Searching the internet I found this link where someone suggests to grant privileges again to the MySQL user that Postfix is using. I'm afraid I don't know how to do this and if it's appropriate to my issue, so I didn't touch the server.

Any idea?

Edit: I found another user having the same issue. He gave up on finding the problem, but I wish I'll find the cause. Hope it won't take too long, otherwise I'll be forced to rebuild the server because my main emails comes on it.

I changed that and the issue is still there. During my research in logs, I found some lines which might or might not be related to this issue. I took them before the last change - you can see the date:

I don't know what is proxymap and proxy:mysql. Are you kind to explain me (maybe it's useful for others too), like to a novice, how the system works? How is the email received by the server and what is its way to the mailbox, in this particular setup?

server.mydomain.com is registered in my DNS - if I ping from outside, it resolves fine. hostname.myprovider.com is not registered in my DNS but it resolves because it's in my provider's DNS. There should be no reason why it wouldn't work this setup. Correct me if I'm wrong.

I had a very similar problem to the one laid out by digitalage with respect to log errors and some aspects of set up After fussing for several hours, I finally remembered that I was using prefixes for my Mysql tables... Not knowing how to make the prefixes explicit in the drupal-xxx-.cf files, I just added them directly to the table calls, so

Thank you pilot9 for your response. It's now too late for me, I already reinstalled linux on that server.

However, I'd like to know more details about this issue and how to avoid it in the future. I don't understand your case. Are you nice to explain a bit more detailed? If you can, please clear up the prefixes staff, as I don't understand why and when is it write to use them. I assume you installed drupal, and after that the hell began. Am I write?

Thank you pilot9 for your response. It's now too late for me, I already reinstalled linux on that server.

However, I'd like to know more details about this issue and how to avoid it in the future. I don't understand your case. Are you nice to explain a bit more detailed? If you can, please clear up the prefixes staff, as I don't understand why and when is it write to use them. I assume you installed drupal, and after that the hell began. Am I write?

Click to expand...

Yes, I had installed Drupal, which gives you a nice option to use table prefixes for multisite installations in the same database. However, most recipes don't take them into consideration, so they are easy to miss. You are left with authentication errors, which are difficult to track sometimes. And as far as I know, the only more general solution to this sort of problem is keep careful track of everything! For relatively inexperienced sysadmin like myself, it is a mess and a climb up a steep learning curve... One general solution I would love to find (and have not found) is a comprehensive debugging recipe/howto, a series of steps to tackle certain kinds of very common errors (like authentication errors) where logs do not typically point to the problem directly...) When I have a little more time, I will sketch one out and maybe SPTM (smarter people than me) can flesh it out.

I added table prefixe [--PREFIX--] to the lines below. So if my prefix was "MySite" then [--PREFIX--]sometable becomes MySitesometable .

1. In /etc/postfix/sasl/smtpd.conf

sql_select: SELECT pass FROM [--PREFIX--]users WHERE mail='%u' AND status=1

Note: "users" is of course the table in the database with the passwords and so on. The database itself and the columns in the tables themselves do NOT need to be prefixed!

2. In /etc/dovecot/dovecot-sql.conf

password_query = SELECT mail AS user, pass AS password FROM [--PREFIX--]users WHERE mail='%u';

Note: "user" and "password" above are column names to retrieve your user's signin names and pws to access their email. "users" again is the table where that info is stored (and so needs to be prefixed).

The thing about MySQL is that it is very unforgiving. One little space or an added " ` " somewhere and you are going to get something like authentication errors. I spent a lot of time combing all the MySQL calls and then going ever so carefully over the whole process of how the different parts of the server call one another before I remembered these prefixes. The silver lining was taking a few steps up the learning curve...

Pilot, your answer is very detailed and much appreciated. Though the approach to multi-site it's logical, I wasn't aware of how to get there. Thank you for explanation and links. I'm sure many will find this post helpful.

First thing I did was to check that the mysql queries worked from command line. I did that with postmap -q and mysql (logging onto mysql as the postfix user, same as postfix will do). This worked fine. I had a good look at it with phpmyadmin and the info seemed to be there, but still, trivial-rewrite couldn't do mysql lookups.

I read that "hosts localhost" and "hosts 127.0.0.1" worked differently in mysql, so tried both those in the query. Didn't make any difference. I tried making a connection to the socket instead... "hosts unix:/var/run/mysqld/mysqld.sock" and that failed too.

(For the record: connect to mysql on localhost, and the client makes a unix domain, socket connection, NOT a network connection. If you connect to 127.0.0.1 then it does networking. And I thought localhost and 127.0.0.1 meant the same thing )

I edited /etc/postfix/master.cf so it would NOT chroot trivial-rewrite. Amazingly... postfix did its first mysql lookup, using hosts unix:

But I wanted to put trivial-rewrite back in its chroot, so wanted the network connection to 127.0.0.1. About this time, I found that even command-line connections to 127.0.0.1 failed:

# mysql --host=127.0.0.1 -u root -p
(connection refused)​

So it wasn't just postfix having trouble. "netstat -nap" showed mysql listening on 127.0.0.1:3306, as wanted. I turned on mysql's logging, and could see that it wasn't getting any requests: just sitting there idle while postfix, mysql client etc asked stuff and were refused.

I revisited the privileges tables in mysql - made sure that the postfix user could connect from host 127.0.0.1. I'm not sure I did that exactly right so I won't post the details yet. Still mysql lookups failed at 127.0.0.1.

I had already checked that iptables firewall was allowing access to port 3306.

About this time, a google result sent me to read README.Debian. (A bit embarrassing that I hadn't already, but there ya go.) The actual file on Lenny was /usr/share/doc/mysql-server-5.0/README.Debian.gz and it gave me the puzzle piece I needed:

If your connection is aborted immediately see if "mysqld: all" or similar is in /etc/hosts.allow and read hosts_access(5).​

Sigh... I added mysqld: 127.0.0.1 to hosts.allow and it all came good. The mail.log started complaining about the SQL syntax, which was really good news at the time, that was something I could fix!

I'm not finished yet still have things to fix on this postfix/mysql/etc mailserver, but this was a step forwards. Hope it helps someone.

About this time, a google result sent me to read README.Debian. (A bit embarrassing that I hadn't already, but there ya go.) The actual file on Lenny was /usr/share/doc/mysql-server-5.0/README.Debian.gz and it gave me the puzzle piece I needed:

If your connection is aborted immediately see if "mysqld: all" or similar is in /etc/hosts.allow and read hosts_access(5).

Sigh... I added mysqld: 127.0.0.1 to hosts.allow and it all came good. The mail.log started complaining about the SQL syntax, which was really good news at the time, that was something I could fix!

Click to expand...

Dipps, thank you for your post.

As far as I'm aware of, it makes sense to have a rule in /etc/hosts.allow when there is a rule in /etc/hosts.deny which blocks everything (ie: "all: all") or part of it ("mysql: all"). For the beginner, the explanation: first rule denies everything, in which case we need a rule in /etc/hosts.allow to allow mysql, the second blocks mysql from the public IP, in which case wee need a rule in /etc/hosts.allow to override this for the specific part we need mysql access (local - 127.0.0.1, or public_ip).