Open da2x opened 6 years ago
@da2x You're suggesting that a second step to (un)confirmation is added and selectively required based on the user agent?
Isn't it simpler, and better UX, to simply block access to the (un)confirmation pages for specific user agents of known bots?
No, I’m suggesting that an extra step is required for everyone. It’s probably better than blocking based on the User Agent. (Though no confirmation should be accepted from a blacklisted User-Agent too.)
@da2x Thanks for clarifying; I don't yet get it.
If no confirmation is accepted from blacklisted User-Agents, then what's the benefit of adding the second required step for everyone (including humans)?
There's a clear downside to adding that, which is that people trying to unsubscribe must make a greater effort to do so. It may also impact list-unsubscribe buttons in mail clients; I don't recall how that's currently implemented.
@da2x phpList already has a mechanism for that. If "JumpOff" is false, it will request details and require a post to actually unsubscribe.
The main reason to not use that, ie jump off true, is to make it as quick and easy as possible to get off a list. That's mostly because phpList unfortunately is also used for non-permission based marketing. This makes doing that less attractive.
However, I do agree that even in those cases it will be useful to put things in that avoid bots from erroneously unsubscribing people.
Subscription is always double opt-in, and has been so forever. People have tried to hack that, but I don't think that's a good idea. It will fill your system with spam accounts and pollute the database.
Subscription is always double opt-in, and has been so forever. People have tried to hack that, but I don't think that's a good idea. It will fill your system with spam accounts and pollute the database.
But it doesn’t require a POST request, right? Which is what this ticket was about. I wasn’t aware of UNSUBSCRIBE_JUMPOFF
and I guess what I’m looking for is a SUBSCRIBE_JUMPON
then; requiring the same POST request before subscribing someone via an confirmation link.
True, there's no POST request on confirming. But that should be really short-lived. There is however a POST request on subscribing, and then the email has a unique link that is a GET. Again, there's a UX issue here. If that's were to be a POST, you'll lose half your subscribers. And these are supposed to be the real ones that actually went through the trouble of click the confirmation link in the email, so they really want to get your stuff, it seems.
The default is set to true but the documentation says false: https://resources.phplist.com/system/config/unsubscribe_jumpoff
https://github.com/phpList/phplist3/blob/main/public_html/lists/admin/init.php#L277
415 demonstrates the need for a two-step subscription and unsubscription process.
The (un)subscription confirmation page should no longer (un)subscribe on GET requests. Add a button with an (Un)subscribe button instead. Clicking that should POST to the same page and only then (un)subscribe the user.
Ideally the button should be big and in the middle of the page with some text like “Confirm your (un)subscription request.”
This extra process should possibly only apply to some User-Agents or recipient domains (see #415).