Errors with bounce processing from forwardemail

[Skeyelab]

I am using the forwardemail service and have set my Webhook URL in their settings and my Forward Email Key in my listmonk settings. Listmonk's error log reads:

bounce.go:215: error processing forwardemail notification: invalid signature

Does anyone have any experience with this and have gotten it to work?

[MaximilianKohler]

Have you asked on their forum?

[knadh]

Perhaps @shaunwarman could help.

[titanism]

Hi there @Skeyelab - team here from @forwardemail. Curious if you can get some log output, or debug/print to figure out what the culprit is?

The code is at

listmonk/internal/bounce/webhooks/forwardemail.go

Line 59 in 0878f3e

return nil, fmt.Errorf("invalid signature")

on your instance.

I think that @shaunwarman tested this before his PR was accepted/merged for Forward Email support - but he said he'd chime in when he gets time.

[shaunwarman]

@Skeyelab there's a helpful bit here in the screenshots of a previous setup and testing: #2016 (comment)

The webhook should be sent to the 'Bounce Webhook URL' configured in the forwardemail dashboard /domains/<domain_name>/advanced-settings. This is just above the 'Webhook Signature Payload Verification Key' you have configured in listmonk.

I would also check the My Account -> Emails view in your forwardemail dashboard for some logs as well.

Let me get this set back up and see if I can reproduce the invalid signature.

[Skeyelab]

@shaunwarman I am fairly certain that I have everything configured correctly. ForwardEmail is hitting my webhook, generating the error.

@titanism - as far as adding logging goes, I am using the listmonk/listmonk:latest docker image and when I connect to a terminal, I only see what appears to be an executable file. It does not seem I am able the source... unless I am mistaken

[titanism]

@Skeyelab just to confirm, you're using the "Webhook Signature Payload Verification Key" from My Account > Domains > Settings, and not your API key, correct?

[Skeyelab]

Correct. Thanks

[titanism]

Note you can test with hard reject 550 via hardreject@forwardemail.net on your list and soft reject 421 via softreject@forwardemail.net. We created those aliases for test/debug purposes.

[shaunwarman]

Hey @Skeyelab @knadh - my apologies, but I see some issues that are fixed here: #2250

I've validated on a personal VM and see it working end to end.

[titanism]

Awesome stuff @shaunwarman !!!! 🚀

Once it's merged & released all you need to do is upgrade your ListMonk version @Skeyelab

[knadh]

This is merged. Thanks @shaunwarman.

[Skeyelab]

Thanks for the help. When can I expect this to be released?

[titanism]

@knadh the last release was v4.1.0 - can 4.1.1 be released or 4.2.0?

[knadh]

@titanism the next version is v5.0.0 with a major overhaul in the e-mail editor + other small fixes in the next couple of months. No interim releases are planned.

[MaximilianKohler]

What is the thinking behind not releasing small bug fix updates and opting to wait a long time and do major releases only?

[Skeyelab]

@knadh that is quite disappointing to hear that the issue is fixed, but not being released.

[shaunwarman]

@Skeyelab At your own risk, if you want, you can pull down the latest code, build the binary (listmonk), build the docker image and restart docker compose since it sounds like you're using that setup. I've done the same for testing.

git clone https://github.com/knadh/listmonk.git
cd listmonk
make dist
docker build -t listmonk:latest .
docker-compose down

# change docker-compose.yml image reference to local image you just built
sed -i -E 's|listmonk/listmonk:latest|listmonk:latest|g' docker-compose.yml

docker-compose up -d

[knadh]

This is a niche feature, most likely not affecting 99%+ of the current users.

It wouldn't make sense to push interim releases for fixes unless they are significant and affect a significant number of users.

No software makes a release per fix. There's generally a cadence, per month, per quarter, per six months etc. For listmonk, i generally target 3 releases per year with meaningful enough changes making it worthwhile for a large number of users to upgrade.

[titanism]

Just checking in here - I think that core bugs that need patched should get semver releases here and upstream. Or an automated way to choose latest or some other sort of build. Otherwise if push comes to shove and this is so delayed we'll probably release our own newsletter tool built-in to our service, fully open source.