Intermittent 'error sending message: broken pipe'

[henk23]

Version:

• listmonk: v3.0.0 (but also happened with v2.x)
• OS: Docker 27.1.1 on Ubuntu 22.04.4 LTS

Description of the bug and steps to reproduce:
Since a few months ago we started getting a lot of these:

error sending message 'Confirm subscription': write tcp x.x.x.x:33690->x.x.x.x:587: write: broken pipe

It happens very rarely. I've never seen it during sending of a campaign, but it happens very often for the opt-in emails, so we have a lot of unconfirmed subscribers now, which starts to become a problem.

We were on Listmonk v2 and used the SMTP server of a really crappy mail hoster (Netcup).
So we upgraded to v3 and switched to Gmail in hope of solving this. But sadly we keep seeing these errors in our logs.

Listmonk runs in docker on my virtual server, there is no other mail/smtp traffic coming from this IP, or anything fishy happening there.

Since it's Gmail I don't have access to SMTP logs, can only use the "Email log search" as a Workspace Admin, which does not include SMTP errors.

Is it possible that this has something to do with Listmonk? Some protocol violation, that leads to the server dropping the connection? Or maybe Listmonk is keeping the "pipe" open for too long and then for the next mail after 2 days, it is broken?

And the next question: Can Listmonk do anything about this? It seems like there is no retry happening, although I've set "5 retries" in settings --> SMTP. For my case, a retry after say 30 or 60 seconds would probably solve the problem.

Or if an automatic retry is not possible, somehow inform me that there was an error and give me the option to retry manually again?

[MaximilianKohler]

For my case, a retry after say 30 or 60 seconds would probably solve the problem.

Yeah, it would solve some other 4xx errors too. #1717 (comment)

[janwni]

This happens regularly to me, I'd guess in 2 % of the cases. Most often, it seems, on the first mails sent. Using the subscriber ID from the logs is a usable workaround, but it's annoying.

It's a big issue for opt-in mails, as a third of them isn't sent because of this issue. As there's no indication in the logs which subscriber it was, this made double opt-in lists quite unusable for me, especially because #1927 still isn't fixed in the latest release.

[github-actions]

This issue has been marked 'stale' after 90 days of inactivity. If there is no further activity, it will be closed in 7 days.

[henk23]

This is still an issue unfortunately :/

[knadh]

broken pipe is a TCP/network level issue in the environment. There must be something that's causing it, perhaps a firewall. Nothing we can do inside listmonk about it, unfortunately ;(

[henk23]

Hey @knadh, thanks for taking the time to reply :)

I'm not a TCP expert, any idea how to look into this?

And would there be a way for listmonk to catch this issue and trigger a retry?

[knadh]

listmonk already has retry support. It's configured in SMTP settings.

Debugging why the connections are breaking, I am afraid there are two many factors involved depending on the environment. Perhaps using somthing like WireShark would be a good starting point.

[henk23]

Retry setting is already activated. Listmonk seems to ignore the retry setting in case of broken pipe error, and no retry is triggered.

Only available workaround for us currently is to manually confirm the opt-in for new subscribers, which undermines the whole opt in process.

[MaximilianKohler]

@knadh This is not correct:

Nothing we can do inside listmonk about it, unfortunately ;(

See: #1992 (comment)