QUIT message after . taking too long?

this is a weird one, I don’t even know where to start.

I’m watching via kcli trace-smtp-client

and I keep seeing messages like this:

[206f23a7-979f-4e2d-9f71-0080a23b3789]    1s  <- 250 OK i0ougondbcvltu51cpuqv05qj5sd4fi9a1tejlo1


[206f23a7-979f-4e2d-9f71-0080a23b3789]   61s ->  QUIT
[206f23a7-979f-4e2d-9f71-0080a23b3789]   61s  <- 451 4.4.2 Timeout waiting for data from client.```

if I remember my SMTP correctly:

  1. Kumo is sending the . to signify the end of DATA
  2. it looks like the receiving MTA is sending 250 OK
  3. then Kumo hangs before sending QUIT
  4. causing the 451 4.4.2 Timeout

it’s happening regardless of the injector to the same receiving MTA (which makes sense, Kumo waits until it full receives from the injector before sending). so it’s happening with SWAKS as well

interesting. it actually happens to other services as well such as http://aboutmy.email

so maybe this isn’t a new issue I just didn’t notice until this MTA?

[fc21ef73-6c57-4101-a6b0-2809306913d8]   61s ->  QUIT
[fc21ef73-6c57-4101-a6b0-2809306913d8]   61s  <- 221 2.0.0 Bye
[fc21ef73-6c57-4101-a6b0-2809306913d8]   61s === Closed```

you can change that value in your shaping config if you wish

The timeout response you sometimes see is most likely because the remote host in that situation has a mismatched idle time and has given up on the connection, leaving the graceful QUIT command that we send to timeout.

thanks Wez! I got distracted because it turns out the remote host was accepting the message just fine

but it was gunking up the logs

so I’ll go find that setting and tune it a bit