I’ve been dealing with a significant wave of mass unsubscribe and automated abuse on my installations (subscription bombing via scraped third-party email addresses, confirmed through what appears to be corporate email security scanners auto-fetching links). While digging into it, I noticed two design points in core phpList that I think are worth a community discussion before anyone jumps to a PR:
1. Unsubscribe via GET
UNSUBSCRIBEURL currently performs the unsubscribe action directly on GET request — no separate confirmation step required. This means any automated system that fetches links found in an email body (corporate “safe link” scanners being the most common case, e.g. Microsoft Defender/ATP Safe Links, Proofpoint, Mimecast) can unintentionally unsubscribe real users the moment a campaign is sent, before anyone has actually opened the email. This is a well-documented issue in the wild — see e.g. these Microsoft Tech Community threads reporting mass, unintended unsubscribes from mailing lists after enabling Safe Links:
This isn’t phpList-specific (it’s a broader “GET should be safe” issue per RFC 7231 §4.2.1), but since we control the unsubscribe flow here, I think it’s worth discussing whether UNSUBSCRIBEURL should link to the unsubsribe page and not leading to the one-click-unsubscribe so that explicit interaction is required.
I know this simple workaround adds friction that a proper fix could avoid (e.g. an auto-submitting POST form on page load — invisible to a human, but not triggered by simple GET-only fetchers) – but maybe this step is also not safe to advanced scanners and my simple solution linking the unsubscribe page is the non-beautiful but bulletproof solution.
2. Double opt-in confirmation, same pattern
Same issue can be found on the confirm side, just with the opposite effect: automated scanners confirming subscriptions that were never clicked by humans. I have concrete log examples (Tor exit node submits a subscription with a scraped corporate email address; 3 seconds later, a completely different IP/UA — looks like AWS-hosted scanning infrastructure — hits the confirm link) which allows to subscribe whatever email address from those domains to your lists – which may lead to unhappy end users that may complain and you risk to get your mailserver on a blacklist or provider ban (happened to me, I could explain and got removed from the blacklist).
This problem is more tricky as double opt-in confirmation is core UX (one click, done) and I don’t want to suggest adding friction for real subscribers. My rough idea: keep it one-click for humans by having the confirm link land on a page that auto-submits a POST via a small inline script, rather than confirming directly on GET. Happy to prototype this if there’s interest, but wanted to raise it here first in case others have better approaches or have already discussed this.
Please share if you have experienced these problems before and lets discuss the issues!
Plastikschnitzer