Socket connection closed by the other side how rude mdaemon

Need Help here. There is some issue with my client MultiPop.

First of all, here is the email flow :

Email(External) >> Incoming Server >> Mailserver (My site) >> MultiPop(Client site) >> Recipient Outlook Inbox

So, in this case, MultiPoP will grab the email from my Email Server. My client informed me that all the POP setting is on their side in MultiPop.

However, recently, they receive below error.

So, what we have done here in both site,

— We can ping the our server IP and MultiPop IP.

— We can telnet with the port 110. Our site always using 110 port.

— Try to change other hostname but still same.

So, what cause the issue and is there any solution?

3 Replies

Brand Representative for MDaemon Technologies

It looks like their MDaemon server is not allowing enough time for the protocol to start. They can try increasing this time setting via Setup| Server Settings | Timeouts. If that does not resolve the issue, then it’s likely that there’s something on your server that is closing the connection (as indicated by Socket Connection closed by Other Side).
Do you have any third-party anti-virus software running on the MDaemon server? If so, does the issue persist if you exclude scanning of the MDaemon directory? Are there any other applications such as file sync softwrare that might be interrupting the message delivery process?

Thanks for reply. I have to check with myclient site about this first. If there anything will update here.

This topic has been locked by an administrator and is no longer open for commenting.

To continue this discussion, please ask a new question.

Read these next.

Redundant MFA’s/SSO’s?

We’ve been a Duo customer for almost a year now and have greedily plugged in our new toy to everything that’ll accept it; both as an SSO application and MFA provider. It’s been great!This morning we got our first outage (screenshot from https://status.duo.

Repeated attempts to get into our PBX

We started getting hammered with repeated attempts to access our PBX which is internally 192.168.0.11.So I added the following to the access rules to the firewall in our router.Now we have 1 specific IP that is with repeated attempts to gain access to our.

The 2022 Spicies Awards: Spiceworks Partner Edition!

Believe it or not, SpiceWorld 2022 is right around the corner, which also means it is time to honor the best and spiciest in the Spiceworks Community with the Spicies Awards! The Spicies honor the outstanding achievements of both IT pros and tech markete.

Snap! UEFI bootloaders, SOVA Android banking trojan, Black Hat, Excel Champions

Your daily dose of tech news, in brief. Welcome to Monday! I’m unsure how accurate this date is but supposedly, on August 15, 1994, Microsoft engineer Ben Slivka sent an email message suggesting to his colleagues that a World Wide Web browser shoul.

Spark! Pro series – 15th August 2022

The cartoon today got me on a Carrot theme for this Spark! So, you get a carrot themed Spark! “What’s up Doc?” Top Ten Band Names Replaced With the Word Carrot 1. My Chemical Carrot (My Chemical Roma.

Mdaemon Winsock Errors while sending emails. WinServer2008 R2

From last few days i am having an error while my Mdaemon server (v13.0.4) sending emails to another server. I tried troubleshooting by upgrading server, disabling Anti-virus and etc, but still few on few domains it is having SMTP error

Winsock error 10053
Winsock error 10054
Winsock error 10060

Enter to win a

finally the issue was with my FIber connection. i Have had two connections, one wireless and the other one is Fiber.

The issue was with the Up stream in fiber. (ISP)

Thank you all for support and time.

20 Replies

Do these errors occur when sending to one specific domain, or are you getting these errors for all outgoing emails?

Brand Representative for MDaemon Technologies

Further on what AceOfSpades mentioned.

Without a snippet of the SMTP out log, I’m unable to verify the exact reason but the Winsock errors are network related errors. Depending on where the errors are in the SMTP out transaction between the servers, it could clue you to what could be causing the issue.

Verify if there is anything on the network that could be filtering these outbound SMTP sessions, such as a third party Firewall, Windows Firewall, third party AntiVirus software, ISP, etc.

Feel free to PM me a snippet of the SMTP out logs where the issue is happening. The SMTP out log can be found in the \MDaemon\Logs directory.

Let me know if I can help further.

#ACE: These error comes out only with few random domains. otherwise SMTP is working fine.

For more information kindly see the logs.

Tue 2015-09-01 11:11:28: [6314:2] Session 6314; child 2

Tue 2015-09-01 11:11:28: [6314:2] Parsing message

Tue 2015-09-01 11:11:28: [6314:2] * From: ***@abc.com.pk

Tue 2015-09-01 11:11:28: [6314:2] * To: *****@xyz.com.pk

Tue 2015-09-01 11:11:28: [6314:2] * Subject: FW: LIGHTING FIXTURES

Tue 2015-09-01 11:11:28: [6314:2] * Size (bytes): 1292502

Tue 2015-09-01 11:11:28: [6314:2] * Message-ID:

Tue 2015-09-01 11:11:28: [6314:2] Attempting SMTP connection to [xyz.com.pk]

Tue 2015-09-01 11:11:28: [6314:2] Resolving MX records for [xyz.com.pk] (DNS Server: 10.10.1.10).

Tue 2015-09-01 11:11:28: [6314:2] * P=010 S=000 D=xyz.com.pk TTL=(10) MX=[igw5002.site4now.net]

Tue 2015-09-01 11:11:28: [6314:2] Attempting SMTP connection to [igw5002.site4now.net:25]

Tue 2015-09-01 11:11:28: [6314:2] Resolving A record for [igw5002.site4now.net] (DNS Server: 10.10.1.10).

Tue 2015-09-01 11:11:28: [6314:2] * D=igw5002.site4now.net TTL=(10) A=[208.118.63.21]

Tue 2015-09-01 11:11:28: [6314:2] * D=igw5002.site4now.net TTL=(10) A=[208.118.63.23]

Tue 2015-09-01 11:11:28: [6314:2] * D=igw5002.site4now.net TTL=(10) A=[208.118.63.5]

Tue 2015-09-01 11:11:28: [6314:2] * D=igw5002.site4now.net TTL=(10) A=[208.118.63.12]

Tue 2015-09-01 11:11:28: [6314:2] Randomly picked 208.118.**.** from list of A records

Tue 2015-09-01 11:11:28: [6314:2] Attempting SMTP connection to [208.118.**.**:25]

Tue 2015-09-01 11:11:28: [6314:2] Waiting for socket connection.

Tue 2015-09-01 11:11:28: [6314:2] Waiting for protocol to start.

Tue 2015-09-01 11:11:29: [6314:2] EHLO webmail.clipsal.com.pk

Tue 2015-09-01 11:11:29: [6314:2] MAIL From: SIZE=1292502

Tue 2015-09-01 11:11:30: [6314:2] RCPT To:

Tue 2015-09-01 11:11:31: [6314:2] DATA

I dont know about should i share this or not, but 5 emails were stuck in the queue from yesterday and they just delivered after a power restart of Network Switch :/

Brand Representative for MDaemon Technologies

Most likely, the messages were stuck in the retry or remote queue and attempting to retry at intervals that are defined in MDaemon.

From the snippet, MDaemon is attempting to transfer the message to the recipient server, but there is a long delay:

Tue 2015-09-01 11:11:31: [6314:2] Sending to [208.118.**.**]
Tue 2015-09-01 11:12:28: [6314:2] * Winsock Error 10054

I can’t confirm that it was the switch, but it is possible it was the switch causing these network issues. You should be able to look at the Network Switch log to verify what it was doing while you were sending these messages.

Let me know if you require any more assistance and we’ll be happy to help.

Hi, thanks for the response IAN, but it was not a switch because after three hours again two emails are stuck in remote and then retry queue, one of them is at private/business domain and the other one is for gmail.com

I tried troubleshooting all the things and tired to troubleshoot the things.

I looked into every possible reason which can cause this issue i.e. SPF, Greylisting, Reverse DNS and etc.

Brand Representative for MDaemon Technologies

Thanks for the update.

Try sending another test message to one of these domains you can’t send to. When it fails, could you provide a SMTP out log snippet for the test message? I’d like to compare it to the snippet you provided above to see if the network error happens at the same point in the SMTP session.

Brand Representative for MDaemon Technologies

Sounds good. Let us know if we can help more and we’ll be happy to.

Can you confirm that any unused network cards have been disabled?

AceofSpades: Yes all unusable network cards are disable.

So far there is no error after resetting network card. Still i am monitoring, will update you shortly.

Thank you guys for your help and support 🙂

Again another email stuck. after so many hours.

Wed 2015-09-02 17:24:40: [358:2] Parsing message

Wed 2015-09-02 17:24:40: [358:2] * From: feroz@abc.com.pk

Wed 2015-09-02 17:24:40: [358:2] * Subject: =Price_&_availability_//__p?= =?UTF-8?Q?ak=C4=B1stan?=

Wed 2015-09-02 17:24:40: [358:2] * Size (bytes): 6431385

Wed 2015-09-02 17:24:40: [358:2] * Message-ID:

Wed 2015-09-02 17:24:40: [358:2] Attempting SMTP connection to [xyz.com.tr]

Wed 2015-09-02 17:24:40: [358:2] Resolving MX records for [xyz.com.tr] (DNS Server: 10.10.1.10).

Wed 2015-09-02 17:24:40: [358:2] * P=000 S=000 D=xyz.com.tr TTL=(200) MX=[aspmx.l.google.com]

Wed 2015-09-02 17:24:40: [358:2] Attempting SMTP connection to [aspmx.l.google.com:25]

Wed 2015-09-02 17:24:40: [358:2] Resolving A record for [aspmx.l.google.com] (DNS Server: 10.10.1.10).

Wed 2015-09-02 17:24:40: [358:2] * D=aspmx.l.google.com TTL=(3) A=[64.233.**.**]

Wed 2015-09-02 17:24:40: [358:2] Attempting SMTP connection to [64.233.1**.**:25]

Wed 2015-09-02 17:24:40: [358:2] Waiting for socket connection.

Wed 2015-09-02 17:24:40: [358:2] Waiting for protocol to start.

Wed 2015-09-02 17:24:41: [358:2] EHLO webmail.abc.com.pk

Wed 2015-09-02 17:24:41: [358:2] MAIL From: SIZE=6431385

Wed 2015-09-02 17:24:41: [358:2] RCPT To:

Wed 2015-09-02 17:24:42: [358:2] DATA

Brand Representative for MDaemon Technologies

From the log snippets you’ve provided, the network error is happening in the same place during the SMTP session.

From an MDaemon standpoint, MDaemon is simply trying to transfer the message to the recipient mail server. However, something on the network is closing the connection during that transfer. Notice 20 seconds go by before the network error:

Wed 2015-09-02 17:24:42: [358:2] Sending to [64.233.1**.**]
Wed 2015-09-02 17:25:02: [358:2] * Winsock Error 10054

In this case, I would verify there isn’t anything installed on the MDaemon server that could be filtering these SMTP sessions, such as AntiVirus software.

If there isn’t anything installed on the MDaemon server that could be filtering this SMTP session, try doing a trace route from the MDaemon server to the recipient’s IP address (64.233.1**.**) to verify how the connection is routed. Are there any servers between your MDaemon server and the recipient server that you can see might be filtering these connections, such as a firewall, switch, ISP, etc.

If there isn’t anything installed on your MDaemon server or on the network on your side that could be filtering these connections, I’d suggest contacting the Administrator of the recipient mail server and compare the logs to verify if they are closing connections from your mail server for any reasons.

Mdaemon 14.5 Winsock Error 10054

i am facing issue with my mdaemon server, its working accordingly and most of my email send through mdaemon and clients are getting my mail too but some email not sending i dont know whats the actual problem i have been talk with many professionals but still getting same error, i am sharing email server log kindly help me.

Traditional, Headless or Hybrid CMS: Which Is Best

6 Replies

Brand Representative for MDaemon Technologies

Winsock 10054 errors usually indicate that the other server is resetting the connection.

Is this happening with messages from specific senders/domains?

Do you have a firewall, proxy, or other device that mail is routed through before it reaches MDaemon?

You can find more troubleshooting tips in this discussion on our forums:

Brand Representative for MDaemon Technologies

yes we are using firewall which is ASA 5508-X but we are not blocking inside traffic

Brand Representative for MDaemon Technologies

Your router’s MTU settings might be a possible cause. Here’s more:

thanks for your support issue has been solved my firewall logs showed esmtp session block i just run a command on firewall no esmtp inspect.

Brand Representative for MDaemon Technologies

This topic has been locked by an administrator and is no longer open for commenting.

To continue this discussion, please ask a new question.

Read these next.

Redundant MFA’s/SSO’s?

We’ve been a Duo customer for almost a year now and have greedily plugged in our new toy to everything that’ll accept it; both as an SSO application and MFA provider. It’s been great!This morning we got our first outage (screenshot from https://status.duo.

Repeated attempts to get into our PBX

We started getting hammered with repeated attempts to access our PBX which is internally 192.168.0.11.So I added the following to the access rules to the firewall in our router.Now we have 1 specific IP that is with repeated attempts to gain access to our.

The 2022 Spicies Awards: Spiceworks Partner Edition!

Believe it or not, SpiceWorld 2022 is right around the corner, which also means it is time to honor the best and spiciest in the Spiceworks Community with the Spicies Awards! The Spicies honor the outstanding achievements of both IT pros and tech markete.

Snap! UEFI bootloaders, SOVA Android banking trojan, Black Hat, Excel Champions

Your daily dose of tech news, in brief. Welcome to Monday! I’m unsure how accurate this date is but supposedly, on August 15, 1994, Microsoft engineer Ben Slivka sent an email message suggesting to his colleagues that a World Wide Web browser shoul.

Spark! Pro series – 15th August 2022

The cartoon today got me on a Carrot theme for this Spark! So, you get a carrot themed Spark! “What’s up Doc?” Top Ten Band Names Replaced With the Word Carrot 1. My Chemical Carrot (My Chemical Roma.

Socket connection closed by the other side how rude mdaemon

Вопрос

Почта работает. Но. Есть организация, которая отсылает нам письма и они до нас не доходят. Со стороны отправителя это выглядит как Socket connection closed by the other side (how rude!).

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Ответы

Почта работает. Но. Есть организация, которая отсылает нам письма и они до нас не доходят. Со стороны отправителя это выглядит как Socket connection closed by the other side (how rude!).

С нашей стороны в smtp логах это выглядит как TLS negotiation failed with error AlgorithmMismatch.

К ним почта уходит нормально.

Это проблема на нашей стороне? или на стороне отправителя?

Ошибка означает, что при согласовании TLS не удалось найти общего поддерживаемого алгоритма шифрования. Это может быть, если вы, следуя последним веяниям безопасности (или просто бездумно ставя все обновления), отключили у себя на сервере использование старых «небезопасных» алгоритмов, а на их стороне стоит нечто старое, не знающее новых алгоритмов.

Если вам шифрование принимаемых от этого отправителя писем по TLS в реальности не нужно, то настройте отдельный Receive Connector специально для данного отправителя, чтобы он не предлагал TLS: создайте Receive Connector типа Internet, в Remote Network Settings укажите, что принимать только с адреса(ов) почтового сервера этого отправителя, а потом в свойствах этого Receive Connector снимите флаг TLS (и кроме того, можете оставить в Permission Groups только Anonymous users).

Если шифрование таки требуется, то придётся найти для этого алгоритм и включить его использование на обеих сторонах.

Socket connection closed by the other side how rude mdaemon

Вопрос

Deferred: 403 4.7.0 TLS handshake failed

При этом на нашем Exchange TLS не используется, никаких галок, вроде «Requires TLS encriyption» с в свойствах виртуального SMTP сервера не установлено.

Ответы

На самом деле проблема решилась удалением сертификата (Access > Secure Communication > Certificate).
Несмотря на то, что TLS явно нигде включен не был, сервер все равно выдавал в ответ на EHLO строки вроде

А при попытке сервера-отправителя использовать эту функцию ничего путного не происходило.
После удаления сертификата упомянутые строки из приветсвия пропали, работа нормализовалась.

Благодарю за помощь.

Все ответы

С недавних пор пользователи нашего Exchange 2003 стали жаловаться, что от ряда корреспондентов им не доходят письма.
Отправители прислали через другие почтовые системы свои NDRы. Они несколько различаются, но в большинстве своем имеют вид близкий к следующему:

Deferred: 403 4.7.0 TLS handshake failed

При этом на нашем Exchange TLS не используется, никаких галок, вроде «Requires TLS encriyption» с в свойствах виртуального SMTP сервера не установлено.

Tue 2009-01-27 12:17:00: EHLO mail.SENDER.by
Tue 2009-01-27 12:17:00: STARTTLS
Tue 2009-01-27 12:17:00:

А вот та же сессия в моих SMTP-логах: