phplist

NOTE:: Before reporting an issue, make sure you are running the latest version, currently 3.0.5


View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015320phplistSubscribe Processpublic11-08-09 11:1101-11-12 12:27
ReporterThorsten Albrecht 
PrioritynormalSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version2.10.10 
Target VersionFixed in Version2.11.8 
Summary0015320: Unsubscription should only be possible by a subscriber himself and not by a third person
DescriptionIt's possible to unsubscribe somebody else just with the knowledge of his email address (e.g. with mydomain.com/lists/?unsubscribe). One does not have to know his personal preference/unsubscribe link. The unsubscribed user is _immediately_ put on the blacklist which is probably not what he want's to.

I think that this should not be possible. This is an inconsitent behaviour related to the procedure of suscribing where a confirmation mail is needed. Also, this is an security issue.

Unsubscribing should only be possible using one's personal preference link which is normally included in every mailing or which can be sent to the user by mail upon request. If the unsubscribe process should be possible using the unsubscribe link as described above (without any userid), there should be sent a confirmation link to the user.

This functionality should be provided without the need of enabling user passwords.

Thorsten
TagsNo tags attached.
Attached Files

- Relationships
related to 0015359resolvedmichiel User Specific Authentication Pages Loose Formatting 
related to 0015337resolvedmichiel The subscribe page lets anyone change anyone's details by "re-subscribing" 

-  Notes
(0050749)
spiro (reporter)
06-10-09 19:17

I'm also experiencing this issue so wanted to add a bit more detail...

The main issue here is that even with settings in config set to request a password from a user;

define("ASKFORPASSWORD",1);
define("UNSUBSCRIBE_REQUIRES_PASSWORD",1);

When using the uid version of the unsubscribe url this almost works with the exception of the login screen presented without any css styling. Secondly and more importantly, only works properly providing a valid uid is parsed in via the unsubscribe url otherwise only an email unsubscribe form is presented allowing any email to be unsubscribed.

For some reason the non uid or invalid uid with unsubscribe url is accessible in the form of an email only unsubscribe login when it doesn't seem to serve a purpose, i.e. it should at minimum check for the uid and not be available if the uid parsed in is not valid or not present.
(0050750)
spiro (reporter)
06-10-09 20:39

Done some more investigation and found that the setting of "The default subscribe page when there are multiple" in the PHPList configure screen has an effect on this issue. With my set up I don't have any subscribe pages, as im using a joomla addon which feeds into the PHPList tables. What I found is if I change the value in the configure page of the default subscribe page to 0 (zero), then although the default subscribe page stops working it also now only allows the unsubscribe page to be accessed if a valid unsubscribe url with valid uid is used. As I have the password variables set to 1 in the main config.php file as described in previous note, then this seems to now screen out unauthorised users from unsubscribing other emails. It's not a pretty fix but maybe a solution if you don't mind locking down new subscriptions whilst a solution is found and want to protect the existing users from being unsubscribed. It suits those that aren't using the PHPList subscribe page better who want to close down this loophole that mischievous users might try and exploit.
(0050753)
lwc (reporter)
07-10-09 11:12

Likewise for Subscription: Related to http://mantis.phplist.com/view.php?id=15337 [^]
(0050779)
rrrrob (reporter)
13-11-09 20:57

I just stumbled onto this report, my report is basically on the same issue

http://mantis.phplist.com/view.php?id=15359 [^]
(0050815)
michiel (manager)
19-01-10 19:50


I know that it's preferable for "nice" list managers that only the UID link in emails is used, but unfortunately a lot of people "forget" to put the link in, and as a result nobody would be able to unsubscribe.

I will make changes in the future that forces the link to be there, even if it's not added, but it's not hard to hack that out again. Some people don't even want their subscribers to be able to unsubscribe.

phpList should give as much power to users as possible, and this is part of that. I don't think I'm going to change that.
(0050901)
Thorsten Albrecht (reporter)
15-04-10 09:00

Hello Michiel,

your argument that

    "a lot of people "forget" to put the link in, and as a result
    nobody would be able to unsubscribe"

is something that is hard to understand. Even when I would forget the correct (long) unsubscribe link it would be possible to get it again (and access to my personal account data) on two different ways:

1. The easy way: Request to send me the personal link by mail. No problem.

2. Wait for the next newsletter. There you'll get the right link to unsubscribe.

Those two ways should be enough for everybody. There is no need to have a security hole by offering an "anonymous unsubscription". I don't know any other system where I am able to unsubscribe a third person without his knowledge.

Thorsten
(0050902)
michiel (manager)
15-04-10 10:32

No, you misunderstand my argument.

it's not the subscribers who forget the link, it's the administrators who do not put the unsubscribe link in the email. Forget is not the right word for that. They don't like the link and then take it out, basically removing the personalised unsubscribe URL.

I think the other one, to be able to ask for the link is too "hidden" to be really useful. That's more for when the link fails, eg it wrapped.

I will probably add some additional checks in the sendout process to make sure the link is there, and it's always in the headers, but for now phpList does not enforce the unsubscribe URL, it expects the admins to behave, where in reality they don't.

That's why we have this page on our site: http://www.phplist.com/spam [^]

When you write "I don't know any other system where I am able to unsubscribe a third person without his knowledge." that's not entirely true. If you are unsubscribed, you get a message that this happened, and you can correct it by re-subscribing.
(0050903)
Thorsten Albrecht (reporter)
15-04-10 11:44

Michiel,

ok, I see. I did not thought about this possibility that an admin can forget something... Well, if an admin is not able to use phpList correctly he should forget it! ;-)

>I think the other one, to be able to ask for the link
>is too "hidden" to be really useful.

You are exactly right. It's too hidden. And therefore this user form has to be changed to make this functionality immediately visible to the user.

E.g. I just put a simple link to the subscription form of our newsletter:

"change your preferences":
http://www.mydomain.xy/lists/?p=unsubscribe&p=preferences [^]

Now, everybody who wants to change his preferences gets easy to a form where he can enter his mail address to receive his personal link again.

This concept is straight forward and easy to understand for everybody. And quite common for nearly every system found in the web where one has to login. Normally, you get passwords, in phpList you get your personal link. It's nearly the same.

>When you write "I don't know any other system where I am able to
>unsubscribe a third person without his knowledge." that's not entirely true.
>If you are unsubscribed, you get a message that this happened, and you can
>correct it by re-subscribing.

Well, you are right. But don't you see the problem concerning data security? What would a customer think of our company if he notices that anybody else can change his personal data in the newsletter system? Ok, he can easily resubscribe, but with high security he will think: "If this could happen to my newsletter data - what else can happen within this company? Perhaps everybody can view my orders in their webshop! They don't seem to care about privacy data!"

Please take my arguments seriously. I am not just talking about new features, I am describing a data security problem which has to be closed. And it should not have to be ignored just by the reason "that the admin could forget to insert the unsubscription link". IMO this is no reason at all.

Please ask other phpList user what they think about this "feature". I am sure that I am not the only one who is complaining about the current method.

Best regards from Berlin,

Thorsten
(0050904)
michiel (manager)
15-04-10 12:07

yes, you're right. But that's what the options for using password and using a password to unsubscribe are for. that way the unsubscription can be protected.

the way it works has in mind the subscriber that considers the message to be spam. They want to get off immediately. If they have to go through a procedure to request their password and the like, it won't happen and they'll report it as spam, causing your servers to become tainted and possibly blacklisted.

That's also why the JUMP_OFF option exists. Even asking for a reason is too much.

The difficulty is that phpList is used in a very large range of "situations" including extremely inexperienced and unaware mailinglist managers. The last thing I'd want is phpList to become equated with "spamming tool" which is why these features exist. Unsubscribe should be as smooth as possible.

Interesting discussion, and certainly not the end of it.

Regards from Buenos Aires :-)
(0051830)
michiel (manager)
01-11-12 12:27

I think the main problem with this one was the fact that even with

define("ASKFORPASSWORD",1);
define("UNSUBSCRIBE_REQUIRES_PASSWORD",1);

entering an email in the unsubscribe page, would allow unsubscribing that email without needing to enter a password.

This was due to using $_GET['email'] as the variable. So I changed the form to have a method "GET" and now it works to request the password.

Still remains the issue that it is possible to unsubscribe someone else. To avoid this, you'd need to set it to require the password to unsubscribe, but I don't think that's very subscriber friendly, and only really an option for small closed lists, not for large blasts.

Particularly because I recoded the subscriber passwords to be encrypted, and haven't managed to code the "Forgot password" system yet, which means the password has to be requested by email, which is not good.

But the "being able to unsubscribe someone else" issue is something we just have to live with and partly intrinsic to systems like this. This is the main reason that phpList still sends out a "Goodbye from our lists" email, in order to notify the person being unsubscribed, so that they can act on it, when it was not requested.


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker