• 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 GMX Emails stuck in queue

J

jonny_alex

Basic Pleskian
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.
 

Attachments

  • Unbenannt.PNG
    Unbenannt.PNG
    53 KB · Views: 21
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.
 
Monty said:
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.
Click to expand...
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 ...
 
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]
 
Code: 
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:
Code: 
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):

Code: 
>>> 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.
 
Last edited:
>>> 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')
 
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:
Code: 
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.
 
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.
 
I added an image of my current Records. Do i need to add another one?

Greetings
 

Attachments

  • DNS.PNG
    DNS.PNG
    48.8 KB · Views: 22
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.
 
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.
 
Peter Debik said:
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.
Click to expand...
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?
 
You must log in or register to reply here.

Similar threads

P
Resolved Can't receive email - DNS Error
Replies
8
Views
5K
PeterH
P
Stergios G
Resolved Can 't send email from website forms to same domains email account, with office 365
Replies
2
Views
3K
Stergios G
Stergios G
X
Resolved Plesk Extension: Plesk Email Security (Very Slow Delivery)
Replies
8
Views
6K
Kaspar@Plesk
Kaspar@Plesk
L
Issue Spam-/Mailproblems
Replies
1
Views
960
Peter Debik
P
K
Question Mail not sended.
Replies
2
Views
1K
klamort
K
Back
Top