• 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

qmail TLS problem

Flamenetworks

Basic Pleskian
Hi all,

i'm experiencing a problem with TLS and QMAIL.

When trying to send an e-mail to some e-mail addresses i get the following message:

Sep 9 19:30:53 web qmail: 1220981453.155498 delivery 6654: deferral: TLS_connect_failed:_No_such_file_or_directory;_connected_to_62.99.XXX.XXX./

The messages remains in the queue and is not delivered.

Here's OS/Plesk versions:

root@web:~# cat /opt/psa/version
8.6.0 Ubuntu 6.06 86080822.20
root@web:~#


Any help would be very appreciated.

Regards
 
Just to give all of you more informations:

it seems it's a problem related to OpenSSL...when i try to add a new SSL Cert i get the following messages:

unable to load 'random state'
This means that the random number generator has not been seeded
with much random data.
Consider setting the RANDFILE environment variable to point at a file that
'random' data can be kept in (the file will be overwritten).
Generating a 1024 bit RSA private key
17982:error:24064064:random number generator:SSLEAY_RAND_BYTES:pRNG not seeded:md_rand.c:503:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html
17982:error:04081003:rsa routines:RSA_BUILTIN_KEYGEN:BN lib:rsa_gen.c:183:
 
Well,

rm /dev/random /dev/urandom

# /var/qmail/bin/qmail-qstat
messages in queue: 18

after a reboot the same :(

Any idea?
 
Having messages in queue doesn't mean you have a problem. If a message can't be delivered because of a temporary error (graylist or dest server down, for example), it will be queued and attempt deliver again later.

You should check your maillog for possible error messages related to TLS, now that you recreated /dev/(u)random.
 
Having messages in queue doesn't mean you have a problem. If a message can't be delivered because of a temporary error (graylist or dest server down, for example), it will be queued and attempt deliver again later.

You should check your maillog for possible error messages related to TLS, now that you recreated /dev/(u)random.

The problem is, that the remote server works from other mailservers (for example from gmail or gmx) but not from mine and that the mails are for days in the queue and don't leave it.

A log example:
Sep 24 19:36:57 bountin qmail: 1222277817.982019 starting delivery 12: msg 13058351 to remote test***@***rainbowtrust-austria.org
Sep 24 19:36:57 bountin qmail: 1222277817.982124 status: local 0/10 remote 1/20
Sep 24 19:36:57 bountin qmail-remote-handlers[3617]: Handlers Filter before-remote for qmail started ...
Sep 24 19:36:58 bountin qmail-remote-handlers[3617]: from=**@** ( is a private mail)
Sep 24 19:36:58 bountin qmail-remote-handlers[3617]: to=test***@***rainbowtrust-austria.org
Sep 24 19:36:58 bountin qmail: 1222277818.133702 delivery 12: deferral: TLS_connect_failed:_No_such_file_or_directory;_connected_to_91.203.111.3./
Sep 24 19:36:58 bountin qmail: 1222277818.133785 status: local 0/10 remote 0/20
 
Back
Top