Resolved GMX Emails stuck in queue

[jonny_alex]

I got a problem with sending emails to gmx.

All the Mails i send stuck in the queue but never delivering.

Receiving gmx.de isn't a problem.

My Plesk Version is: CentOS Linux 7.6.1810 (Core)‬
Mailserver Qmail
SMPT: Dovecot

My check on mx records show as in the image

In this case i'll need specific guidance since i have no clue how to set it up correctly.

 

[Monty]

Check your mailserver log file at /var/log/maillog or /usr/local/psa/var/log/maillog. There you'll see the reason why your server can't send to GMX. You can also post (anonymized) logs here if you require some assistance understanding them.

 

[jonny_alex]

Check your mailserver log file at /var/log/maillog or /usr/local/psa/var/log/maillog. There you'll see the reason why your server can't send to GMX. You can also post (anonymized) logs here if you require some assistance understanding them.

Apr 18 07:22:27 srv01 /var/qmail/bin/relaylock[12916]: /var/qmail/bin/relaylock: mail from 177.154.52.34:xx(34customer-52-154-177.portalsol.com.br)
Apr 18 07:22:37 srv01 /var/qmail/bin/relaylock[12928]: /var/qmail/bin/relaylock: mail from 103.231.139.184:62508 (softdnserror)
Apr 18 07:22:38 srv01 qmail: 1555564958.986905 starting delivery 550: msg 1181458 to remote [email protected]
Apr 18 07:22:38 srv01 qmail: 1555564958.986993 status: local 0/10 remote 1/20
Apr 18 07:22:39 srv01 qmail-remote-handlers[12930]: Handlers Filter before-remote for qmail started ...
Apr 18 07:22:39 srv01 qmail-remote-handlers[12930]: [email protected]
Apr 18 07:22:39 srv01 qmail-remote-handlers[12930]: [email protected]
Apr 18 07:22:39 srv01 drweb[12931]: Starting the drweb filter...
Apr 18 07:22:39 srv01 qmail-queue[12931]: scan: the message(drweb.tmp.emHbHR) sent by [email protected] to [email protected] is passed
Apr 18 07:22:39 srv01 qmail: 1555564959.352974 delivery 550: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
Apr 18 07:22:39 srv01 qmail: 1555564959.353075 status: local 0/10 remote 0/20
Apr 18 07:22:42 srv01 smtp_auth[12935]: SMTP connect from softdnserror [103.231.139.184]
Apr 18 07:22:42 srv01 smtp_auth[12935]: No such user '[email protected]' in mail authorization database
Apr 18 07:22:42 srv01 smtp_auth[12935]: FAILED: [email protected] - password incorrect from softdnserror [103.231.139.184]
Apr 18 07:22:43 srv01 /var/qmail/bin/relaylock[12937]: /var/qmail/bin/relaylock: mail from 103.231.139.127:28238 (softdnserror)
Apr 18 07:22:48 srv01 smtp_auth[12942]: SMTP connect from softdnserror [103.231.139.127]
Apr 18 07:22:48 srv01 smtp_auth[12942]: No such user '[email protected]' in mail authorization database
Apr 18 07:22:48 srv01 smtp_auth[12942]: FAILED: [email protected] - password incorrect from softdnserror [103.231.139.127]
Apr 18 07:22:57 srv01 /var/qmail/bin/relaylock[12950]: /var/qmail/bin/relaylock: mail from 91.241.72.38:37538 (mail21-38.srv2.de)
Apr 18 07:22:59 srv01 qmail-queue-handlers[12957]: Handlers Filter before-queue for qmail started ...

 

[jonny_alex]

Apr 18 07:22:27 srv01 /var/qmail/bin/relaylock[12916]: /var/qmail/bin/relaylock: mail from 177.154.52.34:43371 (34customer-52-154-177.portalsol.com.br)
Apr 18 07:22:37 srv01 /var/qmail/bin/relaylock[12928]: /var/qmail/bin/relaylock: mail from 103.231.139.184:62508 (softdnserror)
Apr 18 07:22:38 srv01 qmail: 1555564958.986905 starting delivery 550: msg 1181458 to remote [email protected]
Apr 18 07:22:38 srv01 qmail: 1555564958.986993 status: local 0/10 remote 1/20
Apr 18 07:22:39 srv01 qmail-remote-handlers[12930]: Handlers Filter before-remote for qmail started ...
Apr 18 07:22:39 srv01 qmail-remote-handlers[12930]: [email protected]
Apr 18 07:22:39 srv01 qmail-remote-handlers[12930]: [email protected]
Apr 18 07:22:39 srv01 drweb[12931]: Starting the drweb filter...
Apr 18 07:22:39 srv01 qmail-queue[12931]: scan: the message(drweb.tmp.emHbHR) sent by [email protected] to [email protected] is passed
Apr 18 07:22:39 srv01 qmail: 1555564959.352974 delivery 550: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
Apr 18 07:22:39 srv01 qmail: 1555564959.353075 status: local 0/10 remote 0/20
Apr 18 07:22:42 srv01 smtp_auth[12935]: SMTP connect from softdnserror [103.231.139.184]

 

[Ales]

delivery 550: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)

There is something blocking your mail server from connecting to gmx.ch's mail server. Are gmx.ch addresses the only recipients your server has issues delivering mail to?

Anyway, let's quickly test the SMTP connection. I'm going to assume you don't have or wish to have the telnet client installed, so we'll use python.

From your Plesk server's shell, type:

python

to open the python console and enter (copy/paste) the commands (lines beginning with the >>> are the commands, lines without the >>> are the responses):

>>> import smtplib as s
>>> srv = s.SMTP('mx00.emig.gmx.net')
>>> srv.ehlo()
(250, 'gmx.net Hello host.example.com [192.168.0.1]\n8BITMIME\nSIZE 157286400\nSTARTTLS')
>>> srv.quit()
(221, 'gmx.net Service closing transmission channel')
>>> quit()

The above is what should happen if the connection is ok.

If needed, you can try the same with their other MX, mx01.emig.gmx.net.

Can you connect? Do you get the proper communication responses from GMX?

BTW, gmx.ch and gmx.de use the same MX servers, so I suspect your outgoing mail to gmx.de addresses isn't being sent either. You can probably receive mail form both, but not send.

 

[jonny_alex]

>>> srv = s.SMTP('mx00.emig.gmx.net')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.7/smtplib.py", line 257, in __init__
raise SMTPConnectError(code, msg)
smtplib.SMTPConnectError: (554, 'gmx.net (mxgmx015) Nemesis ESMTP Service not av ailable\nNo SMTP service\nBad DNS PTR resource record.\n
For explanation visit Error messages | GMX Postmaster')

 

[Ales]

Ok, there it is. Your mail server is blocked on their side, the reason they give is: "Bad DNS PTR resource record."

Following their link - and I must give them credit here, they do explain their policies - this is one of the possible reasons:

The PTR-RR is a generic standard entry of your provider. Please allocate an independent and fully qualified domain name (Fully Qualified Domain Name - FQDN) to your email server and enter the corresponding valid PTR-RR.

Indeed, if I check the PTR for your mail server:

dig -r 185.142.212.188

it returns a generic 31301.hostserv.eu.

According to their policy, this is a reason to reject the connection from your mail server. So, instead of 31301.hostserv.eu, your PTR should be the actual FQDN of your server (<something>.hiba.ch ?).

Your provider should be able to sort this out. Perhaps there's a setting in their control panel or you'll need to contact their support.

 

[jonny_alex]

I see, can i also change this via putty or would this cause problems?

 

[Ales]

If the hostname of your server is indeed still 31301.hostserv.eu, than you should first change this to something else, like <something>.hiba.ch (just an example) and also make sure, that there is an DNS A record for this new hostname, pointing to 185.142.212.188.

After you have done this, request a PTR record change from your server's provider. This is something only they can do.

 

[jonny_alex]

I added an image of my current Records. Do i need to add another one?

Greetings

 

[Bitpalast]

The PTR record cannot be set in your normal DNS domain record. It must be set by the data center that providers your server space. Hostname must resolve to the IP address end the IP address must resolve to the hostname. The later is what's not good with your hostname. Either the PTR is missing or wrong. You need to set this in your data center's routing or ask their support to do it for you.

 

[Bitpalast]

I am setting this to "resolved", because the missing/wrong PTR is clearly the issue. It can only be solved by a correct entry in the data center routing.

 

[jonny_alex]

I am setting this to "resolved", because the missing/wrong PTR is clearly the issue. It can only be solved by a correct entry in the data center routing.

I think that the problem should actually be solved:

Is there anything more i should do in Plesk maybe for example at the dns zone template?