Anyone can unsubscribe a member of a list with open scenario

[qosobrin]

Debian Stretch 9.4 and Sympa Package 6.2.16 environment.

I have one list ([email protected]) configured with unsubscribe.open scenario:

title.gettext open

!is_subscriber ([listname],[email]) smtp,dkim,smime,md5 -> do_it
!equal ([sender],[email])           smtp,dkim           -> request_auth([email])
true()			            smtp,md5,smime      -> do_it

and three users: [email protected], [email protected] and [email protected] Both users A and B are members of the list, while user C is not.

When either user A (member) or user C (not member) sends a message to [email protected] with the following subject "SIGNOFF [email protected] [email protected]" then user B is automatically unsubscribed from the list. The expected behaviour should be user B to receive an authentication request, but it doesn't happen.

Thank you very much. Regards.

[ikedas]

Hi @qosobrin,

Can you also check recent version of Sympa?

[qosobrin]

I have just checked with version 6.2.30 and the problem continues. When user A sends the SIGNOFF message to the list "SIGNOFF [email protected] [email protected]" User B is unsubscribed from the list. The funny thing is that User B receives the unsubscription mail notification.

[qosobrin]

After editing the unsubscribe.open scenario and removing the ! sign in the second line:

title.gettext open

!is_subscriber ([listname],[email]) smtp,dkim,smime,md5 -> do_it
equal ([sender],[email])           smtp,dkim           -> request_auth([email])
true()			            smtp,md5,smime      -> do_it

I tried again and this time user B received the unsubscription confirmation request. It seems like either the equal scenario condition is returning the opposite value or the ! sign is not being evaluated correctly.

[ikedas]

Hi @qosobrin,

Can you show sympa log during original scenario is processed? (Log lines not including "`Sympa::Scenario::" are not needed.)

[qosobrin]

Find attached the full log (debug 3) during user signoff (issue_233.log). In this case I include both sympa and postfix logs. The particular lines referring to the scenario processing are these ones:

Mar 29 22:31:11 parasito sympa_msg[815]: debug2 Sympa::Scenario::_parse_scenario(tracking, default, listas.usc.es)
Mar 29 22:31:11 parasito sympa_msg[815]: debug2 Sympa::Scenario::request_action(Sympa::List <[email protected]>, unsubscribe, smtp, HASH, )
Mar 29 22:31:11 parasito sympa_msg[815]: debug2 Sympa::Scenario::new()
Mar 29 22:31:11 parasito sympa_msg[815]: debug2 Sympa::Scenario::new()
Mar 29 22:31:11 parasito sympa_msg[815]: debug Sympa::Scenario::new() Unable to read file /home/sympa/var/lib/sympa/list_data/lista-probas/scenari/include.unsubscribe.header
Mar 29 22:31:11 parasito sympa_msg[815]: debug Sympa::Scenario::new() Unable to read file /home/sympa/etc/listas.usc.es/scenari/include.unsubscribe.header
Mar 29 22:31:11 parasito sympa_msg[815]: debug Sympa::Scenario::new() Unable to read file /home/sympa/etc/scenari/include.unsubscribe.header
Mar 29 22:31:11 parasito sympa_msg[815]: debug Sympa::Scenario::new() Unable to read file /home/sympa/share/sympa/default/scenari/include.unsubscribe.header
Mar 29 22:31:11 parasito sympa_msg[815]: debug2 Sympa::Scenario::verify(HASH, !is_subscriber ([listname],[email]), HASH, )
Mar 29 22:31:11 parasito sympa_msg[815]: debug2 Sympa::Scenario::verify(HASH, !equal ([sender],[email]), HASH, )
Mar 29 22:31:11 parasito sympa_msg[815]: debug2 Sympa::Scenario::verify(HASH, true(), HASH, )

Should you need anything else, do not hesitate to ask me.

Thank you very much.
Regards.

[ikedas]

Hi @qosobrin,

According to log, sender of message bound for [email protected] looks [email protected] and sent command looks "SIGNOFF list [email protected]" "SIGNOFF list [email protected]". Is it right?

---

2018-04-02 Corretion

[ikedas]

Hi @qosobrin,

Could you please apply this patch and check if the problem is solved?

Additionally if possible, could you please check if other scenarios containing [email] work properly.

[qosobrin]

Hi, @ikedas:

I tried your patch with the unsubscribe scenario and it works as expected.

[email protected] sent an unsubscribe message with subject SIGNOFF list [email protected] to the sympa email address and [email protected] received the confirmation request without being removed from the list. Moreover, the confirmation request works and when used removes the user from the list.

The only other scenario that uses [email] is move_user.auth, but I did not try it because I do not know where it is used. If you could give me hint I will try it and let you know.

Thank you very much for your good work.

Regards,

[ikedas]

Hi @qosobrin,

move_user scenario is used on:

• As a listmaster, "Changing user's email" of "Users" in "Listmaster Admin Menu"
• As a user, "Changing your email address" in "User preferences"

[qosobrin]

OK, I tried to move an user email, since there is no mail command to carry it out I did it through the web interface, and worked as expected. My sympa was configured with the default value of the move_user variable, in this case, move_user.auth

equal([sender],[current_email])     smtp,dkim,md5,smime -> request_auth([email])
is_listmaster([sender])             md5,smime           -> do_it
equal([sender],[email])             md5,smime           -> do_it
true()                              smtp,dkim,md5,smime -> reject

I logged in with account [email protected] and changed the email address to [email protected]. [email protected] received an auth request email. After using the auth url the email changed.

On a side note to this, I do not see the point of the third line in this scenario:

equal([sender],[email])             md5,smime           -> do_it

Can anyone explain me how come sender and email can be the same when this action can only be carried out in a web interface? I understand that email refers to the new email address, while current_email refers to the email address the user had when he logged in (that, of course, should be equal to the sender, except when the change is carried out by the listmaster). If everything that I said is true then the third line will never be evaluated, so there is no need to include it in this scenario. Please, correct me if I'm wrong.

Regards.

[ikedas]

Hi @qosobrin,

Since /sympa/move_user itself can accessed by any authenticated user, the third rule may be carried out. However, I feel what is performed is weird.

[qosobrin]

@ikedas I have nothing more to add to this issue. Feel free to close it when you consider.

[ikedas]

Correction:
Authentication may be requested by request_auth([email]) in the first rule. The third rule will catch authentication sent by user [email] --- md5 implys authentication by validation link.
However, as md5 also implys authentication by login, any logged-in users can move others.

[ikedas]

Merged.