John,

I was having an issue with the tcp socket @ 127.0.0.1. I'd tried various different modifications based on the logs and the issue had remained regardless.
I had built up the environment in a dockerfile and worked on it through the weekend so the problem was replicable across instances up until this morning.

I ended up switching over to using the socket yesterday and only checked out to the previous commit this morning to run a few additional tests on
the problematic part. For whatever reason, the issue is now completely gone.

At this point, I'm thinking this must be a docker issue.

The only notable (minor) differences between this past weekend and today are an AER/ASPM kernel error that was logging on the host.
The paste is here: https://pastebin.com/idBWKDq2

The main difference between the weekend and today is the additional line included saying it can't find device of ID 0008. That wasn't showing up over the weekend.
I think given this experience I may have to revisit my testing methodology when working with docker.

Best Regards,
Lorek


On Tue, Jul 2, 2019 at 12:38 PM John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 01/07/2019 09:48, lorek via dovecot wrote:
> Actually, it seems I may have been wrong in initial assumption that
> the issue with the client was that it was being identified to mysql as
> coming from localhost when connecting via tcp.
> This is what syslog indicated as a reason for the failure but its not
> the whole picture.
>
> As John mentioned I am trying to have dovecot connect over TCP to
> mysql (not using the socket), and the issue looked like the cause was
> the identified by portion of mysql being read by either mysql
> incorrectly or the domain portion being overwritten on dovecot's end
> (I don't know about the internals enough to say for sure where).
>
> Just as due dilligence, I added credentials for a mysql user
> identified by localhost and removed the jail since the dovecot error
> was stating that it failed for connection by user@'localhost' (where
> there weren't credentials).
> After adding the credentials, I performed all the usual mysql tests
> before moving testing up to dovecot and still get an auth failure. The
> log seems to be a bit of a red herring or at the minimum doesn't show
> the whole picture.
>
> Replacing the connection string host with the socket (host=localhost)
> and everything works, and using an external IP that's not 127.0.0.1
> works as expected as well. (confirmed by standing up two isolated
> mysql and dovecot containers and setting auth up over the bridge).
>
> If the issue was caused by user@'localhost' creating the credentials
> should have resolved it, and it didn't. So something weird is going on.
> I've got the environment built up in a dockerfile I can provide if
> anyone wants to dig into what's causing it.
>
> In the meantime due to time constraints, I'll just be working with the
> socket file from now for hosts running most of the mail stack all in one.
>
> Best Regards,
> Lorek.

Lorek

If you have user@localhost as a user in mysql you will be able to
connect with either of these options:

- a tcp socket via an ip address that resolves to localhost

- a unix socket via hostname localhost.

If you have user@127.0.0.1 as a user in mysql you will be able to
connect only via:

- a tcp socket using ip address 127.0.0.1.

John