• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Trouble managing email through Gmail

Frostbolt

Basic Pleskian
I'm trying to add our company email account in Gmail. When I try to add it, with the correct login details, it says "the server returned an error: 334 PDM0ODI0MjY1MDIuMTYwMDYxODJAY2F0YW1hbmNlcijb20+ 535 5.7.8 Error: authentication failed: authentication failure code(535)"

When I look at the maillog I see:
Code:
Oct 28 09:58:13 ns312941 postfix/smtpd[2665]: connect from mail-ua0-f172.google.com[209.85.217.172]
Oct 28 09:58:14 ns312941 postfix/smtpd[2665]: warning: SASL authentication failure: incorrect digest response
Oct 28 09:58:14 ns312941 postfix/smtpd[2665]: warning: mail-ua0-f172.google.com[209.85.217.172]: SASL CRAM-MD5 authentication failed: authentication failure
Oct 28 09:58:14 ns312941 postfix/smtpd[2665]: lost connection after AUTH from mail-ua0-f172.google.com[209.85.217.172]
Oct 28 09:58:14 ns312941 postfix/smtpd[2665]: disconnect from mail-ua0-f172.google.com[209.85.217.172]

I've already tried googling for this error, but so far come up without any working solutions. We use the latest version of Plesk with LetsEncrypt.
 
This error is not linked to the SSL certificate, but it is caused by the authentication encryption algorithm that is used on login from GMail's pop collector. I suggest to try a combination of "SSL/TLS" protected login but PLAIN password, meaning unencrypted password. This should not be a problem when an SSL/TLS encrypted connection is used. If that combination does not work, probably the only way to resolve the issue is to figure out why CRAM-MD5 is not an accepted encryption algorithm in your mail server configuration.
 
Is there some way I can configure that through the Plesk interface? We have root access, but I'd rather not mess with the standard configuration since we're not experts. And I would guess this is a pretty standard use-case?
 
The supported authentication types cannot be configured from within Plesk. They need to be configured on root level of the operating system.
 
My smtpd.conf already shows:
Code:
pwcheck_method: saslauthd
mech_list: plain login
So that seems correct, right?

I checked dovecot configs:
Code:
ssl= yes
disable_plaintext_auth = yes

but when I connect to my server using openssl, it shows:
Code:
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Help, why is plain login not enabled? According to the documentation:
ssl=yes and disable_plaintext_auth=yes: SSL/TLS is offered to the client, but the client isn't required to use it. The client isn't allowed to use plaintext authentication, unless SSL/TLS is enabled first.
 
Have you considered to adjust the GMail pickup method (if possible)? Currently it seems to be set to using password encryption, but the combination of SSL/TLS for the connection an no password encryption (=plain) login should work.
 
Hi Peter,

I'm afraid there's only 3 options in Gmail: TLS, SSL and unencrypted. But thats the connection only, not the password.

But when I connect to my server using openssl, it shows: AUTH DIGEST-MD5 CRAM-MD5 and not AUTH LOGIN. So I guess the problem lies with my server configuration and not Gmail?
 
I edited the smtpd.conf file and changed it to match the suggestion given in the link you provided. I restarted the smtpd service. Unfortunately the error remains the same.

Code:
Oct 29 14:41:36 ns312941 postfix/smtpd[11211]: connect from mail-ua0-f171.google.com[209.85.217.171]
Oct 29 14:41:37 ns312941 postfix/smtpd[11211]: warning: SASL authentication failure: incorrect digest response
Oct 29 14:41:37 ns312941 postfix/smtpd[11211]: warning: mail-ua0-f171.google.com[209.85.217.171]: SASL CRAM-MD5 authentication failed: authentication failure
Oct 29 14:41:37 ns312941 postfix/smtpd[11211]: lost connection after AUTH from mail-ua0-f171.google.com[209.85.217.171]
Oct 29 14:41:37 ns312941 postfix/smtpd[11211]: disconnect from mail-ua0-f171.google.com[209.85.217.171]

I did however run:
Code:
service saslauthd status
Redirecting to /bin/systemctl status saslauthd.service
Unit saslauthd.service could not be found.

Now I'm trying to start saslauthd service but I haven't yet found out how to do that.
 
Last edited:
It is possible that it does not run. Instead you can try this: Check /etc/dovecot/conf.d/11-plesk-security-ssl.conf
It should contain:
Code:
ssl_cipher_list = HIGH:!aNULL:!MD5
ssl_protocols = TLSv1 TLSv1.1 TLSv1.2
Then restart dovecot
# service dovecot restart
 
Hi Peter Debik,

this depends... in case of using Ubuntu/Debian for example, there might be still some issues, when switching between postfix and qmail, as there is still a bug, where permissions issue can appear ( rare case, but still existent ).
 
It is possible that it does not run. Instead you can try this: Check /etc/dovecot/conf.d/11-plesk-security-ssl.conf
It should contain:
Code:
ssl_cipher_list = HIGH:!aNULL:!MD5
ssl_protocols = TLSv1 TLSv1.1 TLSv1.2
Then restart dovecot
# service dovecot restart

It contains:
Code:
ssl= yes
ssl_protocols = TLSv1.1 TLSv1.2
ssl_dh_parameters_length = 2048
ssl_cert= </etc/dovecot/private/dovecot.pem
ssl_key= </etc/dovecot/private/dovecot.pem
ssl_cipher_list = EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EDH+SHA256+AES128:EDH+SHA256+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EDH+SHA1+AES128:EDH+SHA1+AES256:EECDH+HIGH:EDH+HIGH:AESGCM+AES128:AESGCM+AES256:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES
I suppose this is due to: Tune Plesk to Meet PCI DSS on Linux ?

Should I disable the pci_compliance_resolver? This is not something we manually enabled, this was the default.

Hi Frostbolt,

could you pls. provide the informations about your current used operating system?

Indicates some more issues on your server, which should be investigated.
We run "CentOS Linux 7.4.1708".
 
Yes, disabling it would be a great idea. Give it a try. You can always revert to the enabled state. Please report here whether the change solved the problem.
 
I tried disabling pci_compliance_resolver. When I try it again now, I get: "454 4.3.0 Try again later code(454)"

maillog shows:
Code:
Oct 29 20:58:54 catamancer postfix/smtpd[15191]: connect from mail-ua0-f180.google.com[209.85.217.180]
Oct 29 20:58:54 catamancer postfix/smtpd[15191]: warning: connect to Milter service inet:127.0.0.1:12768: Connection refused
Oct 29 20:58:54 catamancer postfix/smtpd[15191]: NOQUEUE: milter-reject: CONNECT from mail-ua0-f180.google.com[209.85.217.180]: 451 4.7.1 Service unavailable - try again later; proto=SMTP
Oct 29 20:58:54 catamancer postfix/smtpd[15191]: NOQUEUE: milter-reject: EHLO from mail-ua0-f180.google.com[209.85.217.180]: 451 4.7.1 Service unavailable - try again later; proto=SMTP helo=<mail-ua0-f180.google.com>
Oct 29 20:58:54 catamancer postfix/smtpd[15191]: lost connection after STARTTLS from mail-ua0-f180.google.com[209.85.217.180]
Oct 29 20:58:54 catamancer postfix/smtpd[15191]: disconnect from mail-ua0-f180.google.com[209.85.217.180]

When I try to connect myself, I get this:

Code:
openssl s_client -connect mydomain.com:25 -starttls smtp
CONNECTED(00000003)
140554678073248:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 237 bytes and written 282 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Now I enabled pci_compliance_resolver again, but I still get the same error. I feel like I'm getting further and further from a solution :(

Edit: now I rebooted my entire server, and now the settings seem to be back to "normal" again. However, when I connect I now see: "250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN", so that is hopeful.

Edit: I ran /usr/local/psa/admin/bin/mail_auth_view and it was suddenly empty! So I ran "plesk repair mail" and now it seems to work correctly. I am testing some more.
 
Last edited:
The issue is fixed :)

I don't know exactly what fixed it, but I disabled and enabled pci_compliance_resolver. I rebooted the server and I ran "plesk repair mail" and now I can connect normally with Gmail. Thanks for all the advice Peter & UFHH01.
 
Back
Top