KumoMTA internal: error in deliver_message: Error Connection closed by peer reading response to Some

get-help
1

Hey guys - just started getting this error this morning, and only for yahoo addresses. Sent to yahoo over the last several days just fine but this morning everything started getting defferred:

{
   "type":"TransientFailure",
   "id":"0c270bdb2ec011f0861b0672a40910a3",
   "sender":"[redacted]",
   "recipient":"[redacted]",
   "queue":"default-tenant@verizon.net",
   "site":"ip-9->mx-aol.mail.gm0.yahoodns.net@smtp_client",
   "size":44141,
   "response":{
      "code":400,
      "enhanced_code":null,
      "content":"KumoMTA internal: error in deliver_message: Error Connection closed by peer reading response to Some(Rset)",
      "command":null
   },
   "peer_address":null,
   "timestamp":1747060679,
   "created":1747006282,
   "num_attempts":5,
   "bounce_classification":"Uncategorized",
   "egress_pool":"pool-1",
   "egress_source":"ip-9",
   "source_address":null,
   "feedback_report":null,
   "meta":{
      
   },
   "headers":{
      
   },
   "delivery_protocol":"ESMTP",
   "reception_protocol":"HTTP",
   "nodeid":"c3047569-3ede-40ae-b4e6-774ddc6cc407",
   "provider_name":"yahoo",
   "session_id":"f20eb338-895d-4a97-8f3a-bc7f0f42510f"
}

We’re using Kumo SOCKS proxy if that’s helpul. Other domains seem fine. May try to change to 1 connection / message to see if that helps

4

So by the error message Yahoo is snipping the connection when you try to RSET.

Is that on all Yahoo destined mail?

5

Correct

6

Run a trace?

7

I can send a single message, wait a bit, send another, wait, etc and it goes through. But at volume we get that error. Maybe we’re being rate limited and that’s how they handle that or something.

I did run a trace but it’s since been buried. We have yahoo excluded right now but I’ll inject some more yahoos and report back

8

yeah still seeing it if we do more than a couple messages. I’ve dumped some trace data but almost impossible to parse through becaus of the volume of data. I don’t see anything in the trace logs that stand out

9

Are you filtering down to just the yahoo traffic? You can also use --only-one after filtering the trace to just Yahoo.

10

Might have to run it a few times to catch a broken one but it would make for less data.

11

I’ll try that. The error does go away if I set max_deliveries_per_connection = 1 for yahoo (previously set at 20).

12

You may want to experiment with dialing the max_deliveries up until the error reappears then dialing it down again, find your limit as it were.

13

We’ve been talking with Yahoo this morning and they claimed nothing changed on their end. And nothing changed on our Kumo side - but here we are :man_shrugging:

14

yeah even setting max_deliveries_per_connection to 2 will create the error. We’ll just keep it at 1 for now - this is the last day of the send and it’s crunch time so will have to circle back to this issue later

15

Finally caught one in the trace logs. Doesn’t say much more than what we already know:

16 
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta domain="verizon.net" 
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta egress_pool="pool-1" 
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta egress_source="ip-4" 
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta id="2c2abdef-20ad-4020-9d06-f15b18dec7ed"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta message_id="5650dae72f5d11f0943a0672a40910a3"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta mx_address="98.136.96.92"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta mx_host="mx-aol.mail.gm0.yahoodns.net."
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta mx_plan={"Addresses":[{"addr":"67.195.204.75","name":"mx-aol.mail.gm0.yahoodns.net."},{"addr":"67.1
95.204.80","name":"mx-aol.mail.gm0.yahoodns.net."},{"addr":"67.195.228.86","name":"mx-aol.mail.gm0.yahoodns.net."},{"addr":"98.136.96.92","name":"mx-aol.mail.
gm0.yahoodns.net."},{"addr":"98.136.96.93","name":"mx-aol.mail.gm0.yahoodns.net."},{"addr":"67.195.228.84","name":"mx-aol.mail.gm0.yahoodns.net."}]}
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta queue_name="default-tenant@verizon.net"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta ready_queue_name="ip-4->mx-aol.mail.gm0.yahoodns.net@smtp_client"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta recipient="X"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta routing_domain=null
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta sender="X"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta source_address="172.16.1.104:38505"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed]       === conn_meta tenant="default-tenant"
[2c2abdef-20ad-4020-9d06-f15b18dec7ed] 129µs === ERROR: Error during read: peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof
[2c2abdef-20ad-4020-9d06-f15b18dec7ed] 143µs === Closed
17

Not even an RSET that time?

18

yeah searching through the trace and I don’t see an RSET anywhere in association with that error.

19

Yeah, so their MTA is just snipping connection at some point when they are not happy. Best you can do is figure out what isn’t making them happy and not doing it, so yeah cutting message count per connection.

20

yeah super strange. We confirmed with them this morning that we’re on their nice list and that 20 msgs/connection is still their limit. Given that we didn’t touch our kumo config and it randomly started happening I can’t see it being a kumo issue - unless our socks server is getting wonky on us. May try and reboot that during a lull.

21

what I’d suggest is that you should look at the Delivery/TransientFailure/Bounce logs for the other messages that were in that session; they will all have the same session_id. That will give you some insight into what happened on one of those sessions. Most likely some limit was hit and the session was snipped.

You will probably benefit from setting try_next_host_on_transport_error - KumoMTA Docs to true. This is a new option that was very recently added to help in situations like this.

22

sweet! will give that a try, thanks