Feature request: suggest performance settings and/or allow re-sending campaign to failed subscribers

[nrathi]

trafficstars

Hi there!

I just switched from HubSpot to ListMonk. I needed to send a legal notice to all 3117 subscribers.

I created a campaign, and a new list (Legal Notice 08102023) with all 3117 subscribers.

Attempt 1: I started the campaign, but it auto-paused out around ~1.7k sends. Attempt 2: I clicked "Send" (the rocket icon) again, and got a bit further, but it still auto-paused around ~2.9k sends. Attempt 3: At this point, I realized there was a throttling issue. I changed my performance settings to use a sliding window:

I hit "Send" one last time, and the campaign "Finished".

However, on SES, I'm only seeing 973 emails sent (510 + 463):

And most importantly, I never got my own email (and I am a subscriber!), so that's how I know it wasn't sent properly.

If you could please help me, I'd really appreciate it. I just need to understand who the email was not sent to, so I can send it to them.

[nrathi]

Here's how I figured this out for myself (feature request at the bottom):

I ssh-ed into the server hosting ListMonk and ran docker logs -f listmonk_app

I found all the messages that looked like this:

2023/08/10 12:35:33 manager.go:392: error sending message in campaign Legal Notice 08102023: subscriber UUID: 454 Throttling failure: Maximum sending rate exceeded.

I then put these subscribers UUIDs in a new list (Legal Notice 08102023-2)

And re-sent the campaign, with the correct performance settings, to this new list.

Feature request: since you're already logging this error, it would be nice if you could:

1. Subtract this "failed count" from the "sent count"
2. Surface which Subscribers didn't get the message, and allow re-sending to them

Even simpler, honestly, would be recommending reasonable performance settings based on the SMTP setup.

[rayrrr]

The long-term fix should involve exponential backoff and jitter. https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter

Update: https://github.com/cenkalti/backoff would probably be a good fit.

[MaximilianKohler]

I don't think listmonk can detect your SES sending rate. It's different for everyone and is something you need to check with SES about.

Listmonk could make the default the SES default, but not everyone is using SES.

[rayrrr]

@MaximilianKohler exponential backoff is a best practice for all high-volume API call situations. It is not specific to AWS SES. Is there any reason we would not want to add this feature to Listmonk?

[1000i100]

Same workaround than I ask here could work : https://github.com/knadh/listmonk/issues/1584#issuecomment-2185512552