• 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
  • Inviting everyone to the UX test of a new security feature in the WP Toolkit
    For WordPress site owners, threats posed by hackers are ever-present. Because of this, we are developing a new security feature for the WP Toolkit. If the topic of WordPress website security is relevant to you, we would be grateful if you could share your experience and help us test the usability of this feature. We invite you to join us for a 1-hour online session via Google Meet. Select a convenient meeting time with our friendly UX staff here.

Issue Gmail SMTP problem; SASL auth failure: incorrect digest response

Tempest

New Pleskian
Hello,

I have a problem with a few email clients having trouble using my SMTP (one of them being gmail, but thunderbird is ok).

the gmail comes back with 'authentication failed. Please check your username/password. Server runtime error: "334 (...) authentication failure code (535)'

the /var/log/maillog shows:
'warning: SASL authentication failure: incorrect digest response'

My server is on CentOS 6.9.

I did search for similar gmail resolvevd issues, but I don't think anyone had the 'incorrect digest response'

Would you have any ideas, please?

Many thanks!
 
I have an externally purchased certificate added in plesk/tools&settings/ssltls certs - Certificate for securing mail
Is there anything else needed to validate a cert?

Please find the files attached.
 

Attachments

  • master_cf.txt
    6.7 KB · Views: 1
  • main_cf.txt
    28.2 KB · Views: 1
  • maillog.txt
    20.3 KB · Views: 1
Hi Tempest,

the /var/log/maillog shows:
'warning: SASL authentication failure: incorrect digest response'
Can't be found within your provided mail - log. Pls. add a correspnding log - file, where your issue/error/problem exists.


In addition, you have this issue for your certificate:
Cert VALIDATION ERROR(S): unable to get local issuer certificate, certificate not trusted, unable to verify the first certificate
Pls. make sure, that you inserted as well the INTERMEDIATE certificate from Comodo. If you need help here, pls. contact the COMODO - Support ( or use the FORUM - SEARCH, where your issue has been discussed within earlier threads )
 
Last edited by a moderator:
Thank you for looking into this!

Please find the fresh maillog attached.

I'll look into the cert issue, I thought everything got uploaded.
 

Attachments

  • maillog.txt
    47.4 KB · Views: 2
Hi,

Just wondered if you had any further thoughts on this.

I contacted the comodo team but they said that to them the certificates look perfectly installed. If this is not the case, could you let me know how you verified the installation, please?

Many thanks!
 
Hi Tempest,

If this is not the case, could you let me know how you verified the installation, please?

Pls. visit for example: => Secure Email and insert the desired eMail - address, to where you desire to send an eMail. ( I used [email protected] )
The result is still an error here:
[001.193] Cert Hostname DOES NOT VERIFY (mail.tuina.scot != vps453544.ovh.net | DNS:vps453544.ovh.net | DNS:www.vps453544.ovh.net)

If you test it with [email protected], the result is o.k now. ;)
 
Alright, please help me understand the logic of the plesk cert installation.
Let's sum up the current situation.

let's use: "Cert A" - to mean an externally purchased cert
"Cert B" - a Let's Encrypt cert.

- in server level: Certificate for securing Plesk - 'Cert A' from server pool
- in server level: Certificate for securing mail - 'Cert A' from server pool

- in domain level: vps453544.ovh.net - 'Cert A' installed in that domain's 'SSL/TLS Certs' section

- in domain level: tuina.scot - 'Cert B' installed in that domain's 'SSL/TLS Certs' section

On my previous server with plesk, I had the same cert installed for domain tuina.scot and for securing mail on a server lever and everything was fine. Likewise, at the moment it's fine only for emails for the domain which cert is used for securing mail on the server level.
Does this mean that among all domains run on the server only the one may be secured fully, which cert is used for securing mail on the server level?
 
Back
Top