phpList / phplist3

Fully functional Open Source email marketing manager for creating, sending, integrating, and analysing email campaigns and newsletters.
https://www.phplist.org
GNU Affero General Public License v3.0
746 stars 269 forks source link

Double opt-in via form for confirmation and unsbuscription links #418

Open da2x opened 6 years ago

da2x commented 6 years ago

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).

samtuke commented 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?

da2x commented 6 years ago

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.)

samtuke commented 6 years ago

@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.

michield commented 6 years ago

@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.

da2x commented 6 years ago

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.

michield commented 6 years ago

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.

rickytato commented 5 months ago

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