All emails from eBay rejected by SMTP (other senders working just fine)

[spellinn]

I seem to have having an issue where all emails from eBay SMTP servers are getting dropped by Exim.

From the exim_mainlog:

4-21 07:02:37 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:22047) syscall: Connection reset by peer
2020-04-21 07:02:37 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:22047) syscall: Broken pipe
2020-04-21 07:02:37 SMTP connection from mxphxpool2044.ebay.com [66.211.185.207]:22047 lost while reading message data (header)
2020-04-21 08:02:49 SMTP connection from [66.211.185.207]:54807 (TCP/IP connection count = 17)
2020-04-21 08:04:25 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:54807) syscall: Connection reset by peer
2020-04-21 08:04:25 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:54807) syscall: Broken pipe
2020-04-21 08:04:25 SMTP connection from mxphxpool2044.ebay.com [66.211.185.207]:54807 lost while reading message data (header)
2020-04-21 09:04:50 SMTP connection from [66.211.185.207]:41235 (TCP/IP connection count = 17)
2020-04-21 09:06:27 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:41235) syscall: Connection reset by peer
2020-04-21 09:06:27 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:41235) syscall: Broken pipe
2020-04-21 09:06:27 SMTP connection from mxphxpool2044.ebay.com [66.211.185.207]:41235 lost while reading message data (header)
2020-04-21 10:03:00 SMTP connection from [66.211.185.207]:10849 (TCP/IP connection count = 23)
2020-04-21 10:04:37 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:10849) syscall: Connection reset by peer
2020-04-21 10:04:37 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:10849) syscall: Broken pipe
2020-04-21 10:04:37 SMTP connection from mxphxpool2044.ebay.com [66.211.185.207]:10849 lost while reading message data (header)
2020-04-21 11:02:07 SMTP connection from [66.211.185.207]:20545 (TCP/IP connection count = 20)
2020-04-21 11:03:43 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:20545) syscall: Connection reset by peer
2020-04-21 11:03:43 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:20545) syscall: Broken pipe
2020-04-21 11:03:43 SMTP connection from mxphxpool2044.ebay.com [66.211.185.207]:20545 lost while reading message data (header)
2020-04-21 12:01:16 SMTP connection from [66.211.185.207]:25443 (TCP/IP connection count = 17)
2020-04-21 12:02:53 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:25443) syscall: Connection reset by peer
2020-04-21 12:02:53 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:25443) syscall: Broken pipe
2020-04-21 12:02:53 SMTP connection from mxphxpool2044.ebay.com [66.211.185.207]:25443 lost while reading message data (header)
2020-04-21 13:05:45 SMTP connection from [66.211.185.207]:41601 (TCP/IP connection count = 13)
2020-04-21 13:07:22 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:41601) syscall: Connection reset by peer
2020-04-21 13:07:22 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:41601) syscall: Broken pipe
2020-04-21 13:07:22 SMTP connection from mxphxpool2044.ebay.com [66.211.185.207]:41601 lost while reading message data (header)
2020-04-21 14:03:02 SMTP connection from [66.211.185.207]:19201 (TCP/IP connection count = 11)
2020-04-21 14:04:39 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:19201) syscall: Connection reset by peer
2020-04-21 14:04:39 SSL_write: (from mxphxpool2044.ebay.com [66.211.185.207]:19201) syscall: Broken pipe
2020-04-21 14:04:39 SMTP connection from mxphxpool2044.ebay.com [66.211.185.207]:19201 lost while reading message data (header)

So its not isolated to one particular eBay host, its them all however the error (Broken pipe) only occurs with incoming email from ebay (obviously one failure out of thousands of hosts sending us emails successfully)

Any suggestions? I thinking perhaps a cipher mismatch perhaps on the SSL connection from their servers?

My openssl connection config is "+no_sslv2 +no_tlsv1" and cipher list is:

ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Suggestions welcome.

Regards

Neil

 

[cPanelLauren]

Hello,

I wonder if this is the same as the issue discussed here: Incoming Email from Office 365 Distribution Group

The delay in that circumstance was causing a similar error - adding the provider's email IP ranges allowed it to complete successfully.

 

[spellinn]

Thanks for the pointer...adding the hosts to the trusted senders list has indeed fixed the problem (albeit temporarily, until eBay's IPs change).

Is there any way to find out how the emails are getting classified as SPAM to then getting subject to the SMTP delayed transactions? I don't really want to get into the business of maintaining whitelists..I'd rather solve the problem at source.

Regards

Neil

 

[cPanelLauren]

Awesome I'm really glad it worked for you. You could add the IP ranges associated with the includes in their SPF record which would ensure that items from other hosts associated would get through:

ebay.com.        3292    IN    TXT    "v=spf1 include:c._spf.ebay.com include:p._spf.ebay.com include:p2._spf.ebay.com ~all"

[[email protected] ~]# dig txt c._spf.ebay.com +short
"v=spf1 ip4:205.201.137.229 ip4:66.135.215.0/24 ip4:66.211.184.0/23 ip4:66.135.222.1 ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:66.135.202.0/27 ip4:216.113.172.0/25 ip4:216.113.160.0/24 ip4:216.113.175.0/24 ip4:148.105.8.0/21 include:ces._spf.ebay.com" " ~all"

"v=spf1 ip4:67.72.99.26 ip4:206.165.246.80/29 ip4:64.127.115.252 ip4:194.64.234.128/27 ip4:65.110.161.77 ip4:204.13.11.48/30 ip4:72.3.237.64/28 ip4:63.111.28.137 ip4:208.74.204.0/22 ip4:46.19.168.0/23 include:emarsys.net include:_spf.salesforce.com"

[[email protected] ~]# dig txt p2._spf.ebay.com +short
"v=spf1 ip4:203.145.57.160/27 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ip4:216.74.162.13 ip4:216.74.162.14 include:sendgrid.net"

 

[spellinn]

That's still whitlisting though..it doesn't stop whatever in cPanel/eXim is deciding the messages aren't to be trusted and adding the SMTP delays which then breaks the message transmission.

 

[cPanelLauren]

Ahh, actually the issue is their mailserver drops the connection when the delay is present, instead of maintaining it. You can change the setting in the Exim Configuration Manager if you don't want the delay present or don't want to have them added to one of the lists. They aren't being necessarily being flagged as spam, I'd lean more towards they are unknown. If you read the full text of the setting:

Introduce a delay into the SMTP transaction for unknown hosts and messages detected as spam.
The SMTP receiver will wait a few additional seconds for a connection when it detects spam messages in order to reduce inbound spam. The system excludes the following remote hosts from the delay: Neighbor IP addresses in the same netblock, Loopback addresses, Trusted Mail Hosts, Relay Hosts, Backup MX Hosts, Skip SMTP Checks Host, Sender Verify Bypass Hosts.

It clarifies that this is specifically unknown hosts and messages detected as spam not just spam.

 

[spellinn]

What makes a host "known" though? By definition, my server doesn't "know" about any of the thousands of remote SMTP hosts that are sending it email...but the majority of them succeed in doing so without triggering this particular setting.

 

[cPanelLauren]

Actually, they probably trigger it but don't disconnect as these do. The problem lies in the fact that the remote server is terminating the connection on the delay, most legitimate email servers don't have this behavior which is why there is an association with spam. While this isn't spamming it's improperly terminating the connection to the server which is similar to spam-sending behavior. The delay is actually only 45 seconds it's not long at all. Even my own mail from Gmail email encounters this delay. Adding them to the Access lists noted is what makes them a "known host" - the server automatically excludes local mail from this as well.


From the documentation:

Introduce a delay into the SMTP transaction for unknown hosts and messages detected as spam.
This setting configures the SMTP receiver to wait a few additional seconds for a connection when it detects spam messages. Typically, legitimate mailing systems will wait past the delay, whereas spammers do not wait past the delay.

Note:
The system excludes the following remote hosts from the delay:

• Neighbor IP addresses in the same netblock
• Loopback addresses
• Trusted Hosts
• Relay Hosts
• Backup MX Hosts
• Skip SMTP Checks Host
• Sender Verify Bypass Hosts

Warning:

• If you use third-party sites to diagnose mail server issues, this setting may falsely detect spam messages.
• If your external monitoring system reports failures after you update your server, configure your monitoring system to allow 45 seconds timeout for connections to port 25. For more information about how to adjust the timeout and polling settings, read your monitoring system’s documentation.
  • If that does not resolve the problem, add the IP address of your monitoring system to the Trusted SMTP IP Addresses section of WHM’s Exim Configuration Manager interface (WHM >> Home >> Service Configuration >> Exim Configuration Manager).
  • If you still encounter errors on your monitoring system, disable the Introduce a delay into the SMTP transaction for unknown hosts and messages detected as spam setting in the Basic Editor section of WHM’s Exim Configuration Manager interface (WHM >> Home >> Service Configuration >> Exim Configuration Manager). However, this will likely result in an increase in spam that your server receives.

This setting defaults to On.