• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Postfix port 25 not working on fresh installed Onyx Server

Hi D4NY,

o.k. - let's start with some suggestions here:

Your servers hostname is configured with "nsXXXXXX.ip-XX-XX-XXX.eu", while you secured your mail - server with the certificate from "mail.XXXXXXXXXX.eu".

This can be solved by changing the servers hostname at => HOME > Tools & Settings > Server Settings to for example "YOUR-DESIRED-NAME.XXXXXXXXXX.eu".

Afterwards, pls. check your new settings over the command line with the command ( logged in as uer "root" over SSH ):
Code:
hostname


Let's assume now, that you choosed a servername like "servername.YOUR-DOMAIN.COM", then pls. add the corresponding SUBDOMAIN - name "servername" at the domain - specific subscription of "YOUR-DOMAIN.COM".


( if not already done! ) Pls. add afterwards a SUBDOMAIN "mail.YOUR-DOMAIN.COM".


Secure BOTH of the subdomains with the help of the Plesk Let's Encrypt Extension and you should now have two valid certificates for "servername.YOUR-DOMAIN.COM" and "mail.YOUR-DOMAIN.COM".


You are now able to secure your Plesk Control Panel and the mail - server with these two certificates at: => HOME > Tools & Settings > SSL/TLS Certificates


The next step is to CHANGE YOUR REVERSE for your IP. This is done over the Control Panel of your server provider OVH. Instructions I found are:

=> OVH : PersonalisedReverse

Due to the fact, that you choosed "servername.YOUR-DOMAIN.COM" for your servers hostname, the reverse of the IP "94.XXX.XXX.204" should now point to the new hostname!

To continue, pls. check now the file "/etc/hosts" on your server and correct it to for example:
Code:
127.0.0.1    localhost.localdomain    localhost
127.0.0.1    servername.YOUR-DOMAIN.COM    servername

94.XXX.XXX.204    servername.YOUR-DOMAIN.COM    servername


To be sure, that all your postfix and dovecot configuration files are correct, pls use now the Plesk Repair Utility with the command:
Code:
plesk repair mail -y -v

At the end, you should now consider to modify as well the SPF - entry for your domain(s), which can be easily be done at:

=> HOME > Tools & Settings > DNS Template

At the moment you use "v=spf1 include:turbo-smtp.com ?all" and you should consider to use as template the TXT - entry:

Code:
v=spf1 +mx +a a:<hostname> include:turbo-smtp.com ip4:94.XXX.XXX.204 ?all
Apply the changes and head over to your domain - specific DNS - settings at:

=> HOME > Subsciptions > YOUR-DOMAIN.COM > DNS Settings

... and check that your changes are set to the SPF - TXT - entry to:
Code:
v=spf1 +mx +a a:servername.YOUR-DOMAIN.COM include:turbo-smtp.com ip4:94.XXX.XXX.204 ?all
As I don't know right now, if you use an external nameserver, where you should place the very same DNS - entries as you see them over your domain specific DNS - Settings at your Plesk Control Panel, I suggest now, not to forget to modify/add/edit all the above DNS - changes at the Control Panel from your domain - provider. ;)

It may take some hours, untill the new reverse entry for your IP and the DNS - changes are synced with the worldwide nameservers... so pls. check for example with the help of the following links, if all your changes are in place:

=> DNS Lookup for 94.XXX.XXX.204
=>
DNS Lookup for YOUR-DOMAIN.COM

If all is fine and in place, pls. send now with your desired eMail - Client an eMail to any external eMail - adress and send an eMail from this external eMail - adress to any eMail - account, setup over your own server and check the "mail.log" afterwards, to see the results.



If you experience further issues/errors/problems, pls. include the NEW "mail.log" and the NEW configuration files "main.cf", "master.cf" from postfix and as well the NEW configuration file from dovecot ( /etc/dovecot/dovecot.conf ) as attachments to your post.



 
First of all i would like to thank you very much for the time you spent trying to help me, i really appreciate that.

I followed step by step your instructions and here is what happened (sorry for italian language in images, but i think you can understand)

1. changed the hostname in camillo.MYDOMAIN.com
hostname.jpg

2. created MYDOMAIN.com subscription and created two subdomains: camillo.MYDOMAIN.com and camillomail.MYDOMAIN.com
subdomains.jpg

3. Created Let's Encrypt certificate for both subdomains

4. Protected Plesk and Mail Server using these two ssl certificates
sslcertificate.jpg

5. Set the reverse dns on my SoYouStart (OVH) server panel
reversedns.jpg

6. Check the /etc/hosts, it's ok, just added the line 127.0.0.0 camillo.MYDOMAIN.com camillo

7. Run the "plesk repair mail -y -v" command. Execution was ok, no error and no warnings.

8. DID NON change SPF record (but for sure i will do it later, now the problem is make smtp working). We use an external domain and dns manager, but no problem with it.

9. Check the reverse dns using tools, and it's ok

10. Set up a test hosting, let's call it MYCUSTOMER.eu, with website, database, mailbox and a Let's Encrypt ssl certificate (the perfect copy of MYCUSTOMER.eu running without problem on a CentOs 6.8 server with Plesk 12.5)

11. Set up the mailbox on my Microsoft Outlook, using this configuration for smtp
outlooksmtp1of2.jpg
outlooksmtp2of2.jpg

12. With the above configuration on the Plesk 12.5 server (when the dns was with old ip obviously) the mails are sent without any problem.

13. Trying to send mails from info@ MYCUSTOMER.eu using Outlook on the Plesk Onyx 17.5 server we got (again, damn!) this error:
outlookerror.jpg

14. Serch on Google about the 0x800CCC80 error and found this: https://support.microsoft.com/it-it...mail-from-outlook-results-in-error-0x800ccc80
That is a "None of the authentication methods supported by this client are supported by your server." error.

Any new idea?

Thank you.
 
Hi D4NY,

Any new idea?
I would have a "better idea", if you would follow the suggestions... :(
If you experience further issues/errors/problems, pls. include the NEW "mail.log" and the NEW configuration files "main.cf", "master.cf" from postfix and as well the NEW configuration file from dovecot ( /etc/dovecot/dovecot.conf ) as attachments to your post.


In addition to the above, pls. try to login with the user credentials at Unknown address and test as well the sending and receiving functions please.
 
Sorry, forgot logs and configuration. Here are the files.

From the webmail, same error (see webmail.jpg)
 

Attachments

  • maillog.txt
    16.2 KB · Views: 8
  • main.cf.txt
    28.8 KB · Views: 6
  • master.cf.txt
    6.5 KB · Views: 4
  • webmail.jpg
    webmail.jpg
    73.4 KB · Views: 11
  • dovecot.conf.txt
    3.6 KB · Views: 4
At the moment the only way to sending mail via Outlook is using port 465 SSL (accepting certificate), but the webmail still can't send.
 
I believe part of your issue (only ssl works) got resolved by my answer in the other similar thread.

It's not the self signed certificate that's a problem (although your mail client may complain). it is the combination of using a username/password and the plain connection your client is using.

Plesk 17.5 has setup postfix with this parameter.
You could uncomment that line although I would not recommend it.

Code:
smtpd_tls_auth_only=yes
.

You would see the change of that parameter if you would compare the 2 configs

Code:
diff <(sort main.cf | grep -v '^#') <(sort main.cf.other | grep -v '^#')

Instead of comparing the config files themselves you can also generate a file containing its working config with the command:

Code:
postconf

That's because the 2 postfix programs can have different default values and if a parameter is not explicitly defined in their configs they could act different even though the configs are the same.

When postfix is on a plain connecting it will give an error if the client tries to authenticate:

Code:
# telnet my.server.com 25
Trying 120.24.21.6...
Connected to my.server.com.
Escape character is '^]'.
220 my.server.com  ESMTP Postfix (Ubuntu)
EHLO test
250-my.server.com
250-STARTTLS
250-SIZE 36352000
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN LOGIN
535 5.7.8 Error: authentication failed: another step is needed in authentication
 
Last edited:
Ehi Mr.Wolf thank you! You have fully understood my problem.

in my etc/postfix/main.cf i've tried this:

# smtpd_tls_auth_only=yes

and suddenly the outgoing mail from Outlook (port 25 without ssl) and Roundcube webmail are working!

Now the question is... in which way this setting impact to the mail server and to the server (you wrote is a not recommended setting)?
Then you wrote about two different postfix programs and about postconf command but i'm not understanding... Can you explain better?
 
Your client is sending its username and password unencrypted to the mail server.
Modern Plesk installations setup postfix with "smtpd_tls_auth_only=yes".

That's a good thing, because people should be discouraged to send their passwords over unencrypted lines.
Often people use their passwords for other stuff as well (sometimes with a minor predictable difference).


In the case of "smtpd_tls_auth_only" for old and new postfix the default value is the same.
It's "no"
If you don't understand my story with postconf then forget it.
It does not apply for the parameter "smtpd_tls_auth_only"

You notice that smtp is working on port 465.
That's not because it's on port 465, but that's because your client is forced to use SSL there.
Postfix knows it can then accept a plain username and password because it is on an encrypted connection.

The modern recommended setting for sending authenticated is using port 587 with TLS.
The SMTP-client then starts a plain connection and greets the mail server.
Then it switches to TLS by invoking "STARTTLS"
From then on the connection is encrypted.


You can copy the main.cf of your old server to the new one as the file "main.cf.other"
Then invoke this command:

Code:
diff <(sort main.cf | grep -v '^#') <(sort main.cf.other | grep -v '^#')

It will show the difference between main.cf and main.cf.other.

You can also use the simpler
Code:
diff main.cf main.cf.other

But that will show differences that may not matter. By sorting the files first and removing the lines that start with a "#" you will get a much cleaner output.
 
Last edited:
Thank you Mr.Wolf.
In these days i've tested configurations with one of my domains and we are now able to use mail client without ssl/tls even if you don't recommend this.
The webmail also seems to work. But on our smartphone we have problems with IMAP configuration on port 143.... we got can't connect to the server.
 
I just checked my configuration and can find these:

find /etc/dovecot -type f -name \*.conf -exec grep -H '^ssl *=' {} \;
Code:
/etc/dovecot/conf.d/11-plesk-security-ssl.conf:ssl= yes

find /etc/dovecot -type f -name \*.conf -exec grep -H '^disable_plaintext_auth *=' {} \;
Code:
/etc/dovecot/conf.d/10-plesk-security.conf:disable_plaintext_auth = no

According to the first paragraph here: SSL/DovecotConfiguration - Dovecot Wiki
It means that ssl is possible (not required) and that it allows plaintext authentication.

  • ssl=no: SSL/TLS is completely disabled.

  • ssl=yes and disable_plaintext_auth=no: SSL/TLS is offered to the client, but the client isn't required to use it. The client is allowed to login with plaintext authentication even when SSL/TLS isn't enabled on the connection. This is insecure, because the plaintext password is exposed to the internet.

  • 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. However, if non-plaintext authentication mechanisms are enabled they are still allowed even without SSL/TLS. Depending on how secure they are, the authentication is either fully secure or it could have some ways for it to be attacked.

  • ssl=required: SSL/TLS is always required, even if non-plaintext authentication mechanisms are used. Any attempt to authenticate before SSL/TLS is enabled will cause an authentication failure.
This is not very consistent with regard to the requirements set in Postfix (by Plesk).
I don't know the reason why plaintext passwords are here suddenly allowed.
Maybe it's the remark in Note2.
Some clients send the authentication in plaintext anyhow as they don't honour the "LOGINDISABLED" when being on a plain connections.

As to your problem.
I wouldn't know its route cause now.
You could repeat those commands (copy/paste) on your server and check how they are set.


Better still...
Stop using plain communications. You'll avoid a lot of the problems you're having now.
Put the same non-selfsigned certificate on all your mail communication (postfix/dovecot) using the Plesk interface and start using a matching hostname in your clients and use SSL.

At least test it with SSL to see if your problem has anything to do with plain text/ssl.
Keep using port 143, but enable SSL (It will use TLS then).
I believe all smartphones are able to (optionally) accept self-signed certificates and those not matching the hostname.

Outlook for Desktop Windows is a pita.
It will always give a warning if hostnames and certificate don't match.

Apple Mail allows you to accept a non-matching certificate.
But after the certificate has been renewed or replaced it will start nagging you again, even if it stays the same hostname. IMHO this is a design flaw of Apple, but there are of course no set rules for such an exception. My opinion is that if you tell the OS that a certain hostname does not have to match it should stay that way. Apple starts rejecting a new certificate even if the name stays the same. What makes it even more flaky is that it checks it quite random. Sometimes it takes months for Apple mail to notice that change...

That's the reason why I stopped using those exceptions and now always have a valid non-selfsigned certificate that matches the used hostname. It's really the only way to go.

In the near future we will be having multiple certificates on the mail connections in Plesk (also LetsEncrypt).
This is only supported by modern mail clients, so I will not be using that feature.

Please Mr. Odin!! Make this upcoming feature optional!!!
 
Last edited:
Back
Top