sympa-community / sympa Goto Github PK

We want to integrate the new components created for Sympa 7 on the sympa-vue repository in the current version of Sympa.

This is how it might look like in Sympa 7:

(see here for all the screen, including the desktop ones)

This is how it might look like in the current Sympa UI:

(those are quick sketches and are not pixel-perfect)

This might be as simple as tweaking the tt2 templates, and exposing the lists data sources as a JSON array to the client (we may want to have this interface as an opt-in thing if we don't want to break the current UX). I'm not sure of what's involved in doing that, so I'm calling for help to the backend guys 😶

The component is currently in development by @ludovicm67 ; see sympa-community/sympa-vue#1

There is at typo in default/web_tt2/change_email_request.tt2 (shoukd instead of should). However, I propose to change this sentence into "Please check your mailbox now". This version is more polite and user friendly in my opinion.

<!-- change_email_request.tt2 -->

[%|loc%]Changing your email address is a sensitive operation so we need to verify your email.[%END%]<br />
[%|loc(new_email)%]To this end we have sent you an email to this address: %1 with a validation link.[%END%]<br />
[%|loc%]You shoukd check your mailbox now.[%END%]

<!-- end change_email_request.tt2 -->

Version: 6.2.14
OS: RHEL 7

When adding, or editing, a list's moderator list in a newsletter list, newly added moderators are rejected by Sympa as not having permission to send to the list until the Sympa software is restarted.

From what I can tell, when the list config changes it's supposed to trigger a cache update in the database but I don't believe this is ocurring.

Hi,

gcc is reporting warnings while building smtpc:

make[2]: Entering directory '/builddir/build/BUILD/sympa-6.2.19b.1/src/smtpc'
CC smtpc.o
CC sockstr.o
smtpc.c: In function 'parse_options':
smtpc.c:229:28: warning: comparison between pointer and zero character constant [-Wpointer-compare]
if (*p == ':' && ++p != '\0')
^~
smtpc.c:229:24: note: did you mean to dereference the pointer?
if (*p == ':' && ++p != '\0')
^~
smtpc.c:272:28: warning: comparison between pointer and zero character constant [-Wpointer-compare]
if (*p == ':' && ++p != '\0')
^~
smtpc.c:272:24: note: did you mean to dereference the pointer?
if (*p == ':' && ++p != '\0')
^~
This is with sympa 6.2.19 beta1 but the warnings were already in 6.2.18.

Also, in 6.2.19 beta 1, smtpc is not installed anymore to libexecdir but to bindir. Is that expected ?

Regards,
Xavier

I'm running Sympa 6.2.16 released in June(?) of this year, yet the information at https://www.sympa.org/manual_6.2/message-handling#unsubscription_url says to use the snippet
"To unsubscribe from this list, clink here: [% 'auto_signoff' | url_abs([list.name],{email=>user.email}) %]"
In a footer yet, this does not result in a unsubscribe e-mail being sent. We had to use the older version of the snippet
"To unsubscribe from this list, clink here: [% wwsympa_url %]/auto_signoff/[% listname %]/[% user.escaped_email %]"
To get it to work as advertised.

Due to parameters being unsorted in config files (when dumping the hash to the file I imagine, maybe because of the sorting cost), it's impossible to use the command diff on two successive config files of a given list.

It could really help ops if this was implemented!

Having upgraded to either 6.2.20 or 6.2.22, neither sympa nor wwsympa can find existing list owners and moderators. One has to edit the list ownership info and save it again (edit_list_request) in order for list ownership to be found.

Log file example:

notice Sympa::Spindle::ToModeration::_send_confirm_to_editor() Warning: No owner and editor defined at all in list Sympa::List mylist@mydomain
err main::#243 > Sympa::Spindle::spin#92 > Sympa::Spindle::ToModeration::_twist#52 > Sympa::Spindle::ToModeration::_send_confirm_to_editor#147 Impossible to send the moderation request for message Sympa::Message
[email protected] to editors of list Sympa::List mylist@mydomain Neither editor nor owner defined!
Sep 22 12:57:35 mblc sympa_msg[5113]: err main::#243 > Sympa::Spindle::spin#92 > Sympa::Spindle::ToModeration::_twist#55 Failed to send moderation request of Sympa::Message [email protected] from [email protected] for list Sympa::List mylist@mydomainto editor(s)

Hello,

over the last two weeks or so, I discussed setting up sympa behind an opensmtpd MTA.

There were quite a lot of hoops to jump through to make it work as is, so as was requested in that channel, I'm submitting a draft for your documentation based on my experiences.
I figured this is as good place as any to submit it, I apologize if it's entirely the wrong place to do so :)

I don't really care if you modify it, update it, adapt it to your formatting standards, consider it "public domain" ;)

I tried making it as clear as I can so that people understand why I did some weird things to have it work properly, so if these mechanism do improve in the future (I'm looking at you, opensmtpd), it'll be easier to simplify this doc.
If some things are silly or do not match your redaction standards, you can rephrase it all you want :)

I hope I didn't leave out any important details, be sure to test it all from zero yourself to make sure!

I hope this helps some people out there at some point.

Opensmtpd, like probably any MTA, can be setup underneath Sympa.
However, there are some tricks for it to work properly.

In this guide I will consider that Sympa has already been installed and mostly configured, has its DB setup and its web frontend in place.
We will focus on opensmtpd's role.

His duties will be:

• Receiving e-mails that will need to be handled by Sympa, and throwing them over to Sympa
• Sending e-mails from sympa over to the outside world

What I will not cover:

• MX dns setup
• SPF, Dmarc, SPF setup with opensmtpd
• spam filtering
• delivering email to MDAs
• TLS PKI
• using that same opensmtpd to submit outgoing mails directly without sympa

I will thus consider that example.com is a A record to the server's public IP, and that lists.example.com are a MX 1 record pointing to example.com

Receiving Emails

The first step will be allowing opensmtpd to receive emails, for that, add this to your opensmtpd configuration (/etc/smtpd.conf on debian)

listen on 0.0.0.0 port 25 hostname example.com pki example.com tls

Here I enabled optionnal TLS PKI, you will need to specify those lines too:

pki example.com certificate "/PATH/TO/cert.pem"	
pki example.com key "/PATH/TO/key.pem"

If you do not wish for any TLS for your ingoing emails just use this shorter line

listen on 0.0.0.0 port 25 hostname example.com

Now we receive emails directed to example.com, but we need a rule on what to do with them in opensmtpd, or else they will simply be rejected.

accept from any for domain "lists.example.com" alias <lists> deliver to mbox

there are several interesting things to note with that line.

• First, this is the first mention to "lists.example.com". As it points to the example.com dns record, emails sent to lists.example.com will be delivered to example.com by the MTAs, but will retain the email header "to: [email protected]"
  We use this to have openstmpd filter these mails that are exclusively aimed at sympa. This makes it easier to integrate it to an opensmtpd that handles other domains, and does other things. Just keep in mind that opensmtpd only matches the first rule, so any mails directed to the domain lists.example.com in the email headers will need to be handled by this rule, as opensmtpd will not match it against subsequent lines.
  Also be careful with earlier rules like 'for domain "*.example.com" ' as those will follow the same behaviour, and mask our lower, but more specific rule against lists.example.com.

• Second, this line refers to an alias file named "lists". You could name it however you want, but this name must match an entry like this, on the same smtpd.conf:

  table lists db:/etc/mail/sympa/aliases.db

Yes, it is imperative that this entry be a "db:" type of table, more on this later.
This is the file where sympa will create its lists aliases, and map them to sympa processing commands.

• Third, the "deliver to mailbox" is a simple standard opensmtpd action. This will actually NOT be acted upon IF there is an entry in the table lists that maps to a CLI command (like sympa's internal aliases do), but only for standard alias -> user mappings. So this could be used ONLY if you want to have aliases manually added to the /etc/mail/sympa/aliases.db file that map to actual user accounts.

I don't know how or why you would need this, but I will mention this as email setups are a very personal thing, and most people come up with very intricate ways of routing them. So I'm pretty sure this will be of use to someone out there :)

Of course, this action can be removed if you don't need it, and only want this rule to deliver emails to the sympa processing engine.
In this case it would simply look like this:

accept from any for domain "lists.example.com" alias <lists>

You could also have it do something else, like deliver to maildir: or probably even relay it out somwhere else. From my exprience the alias file mapping to CLI commands takes precedence over this action, but I haven't tested it that much.

As a bonus, you could increase the default size of the messages (including attachments) if you expect these, with the adding the line:

max-message-size 35M

or setting it to whatever value you'd like.
Be aware though that most email providers will probably limit this value on their side, well before your opensmtpd even sees the message. So don't expect Gmail to allow sending 50MB messages your way!

Sending emails

This is the easy one, just add this to your opensmtpd configuration, if it's not already there:

accept for any relay

If you need to pass it through a proxy email (for dkim signing, for example), you can use:

accept for any relay via smtp://PROXY_IP:PORT

That's pretty much it, as sympa will use the standard sendmail command that opensmtpd replaces uppon being installed.

The aliases thing

To process incoming mails, sympa needs to invoque processing commands.
As other mailing lists, it does so using a neat aliases trick, mapping addresses to commands like this:

somelist: "| /usr/lib/sympa/bin/queue [email protected]"

So when [email protected] receives an email, it goes through this aliases file, which maps this alias to this particular command.
each list needs a few of these.

sympa is actually clever enough to manage its own aliases file, so that when you create a new mailing list, it will actually add all the correct lines to this aliases file.
Without this, [email protected] would simply generate a 550 Bad Recipient error when trying to deliver the mail, on opensmtpd side.

The very first thing to note is that within these sympa aliases, there are actually two commands that need to be run:

somelist: "| /usr/lib/sympa/bin/queue [email protected]"
somelist-owner: "| /usr/lib/sympa/bin/bouncequeue [email protected]"

/usr/lib/sympa/bin/queue and /usr/lib/sympa/bin/bouncequeue on a typical debian system

These are binary helpers for sympa.
the problem is, these aliases commands wil lactually be run by opensmtpd upon receiving new messages. And opensmtpd wisely runs these with its unprivileged user account: "opensmtpd".
While this is a very good security practice, it means that the queue and bouncequeue commands will inherint the opensmtpd permissions, which do NOT have access to, for example, the sympa.conf file (which contains DB credentials), and cannot write to sympa owned directories.

Other MTAs might not see this problem as they might run these commands as root, which has all permissions, but as sympa is designed to use its own "sympa" unprivileged account too, we'll try to respect that. After all, if sympa gets compromised, we don't want it to be able to run things as root. And remember it's handling emails and has a web UI, so it's a fairly exposed service as it is.

The best option rignt now is to run these commands:

chown sympa /usr/lib/sympa/bin/queue
chown sympa /usr/lib/sympa/bin/bouncequeue

then

chmod 4755 /usr/lib/sympa/bin/queue
chmod 4755 /usr/lib/sympa/bin/bouncequeue

this will enable the setuid for the owner of the file. Which means when any user executes these two commands, they will NOT inherit from their own permissions, but instead be run with the file's owner's permissions ("sympa", as we chown'ed those two files)

If you don't want to let any user in the system inject messages into sympa, you could use 4754 or 4750 permissions, and add opensmtpd to the group the files belong to.

the easiest would be to run:

chown sympa:sympa /usr/lib/sympa/bin/queue
chown sympa:sympa /usr/lib/sympa/bin/bouncequeue
    useradd -G sympa opensmtpd
chmod 4750 /usr/lib/sympa/bin/queue
chmod 4750 /usr/lib/sympa/bin/bouncequeue

CAUTION: always remember that these files MUST always be executable by both opensmtpd AND sympa user, as actions triggered through the web UI will be run under the sympa user. This might seem obvious but if you get errors, make sure you didn't lock execution of those files out from sympa's user! ;)

Now, the second problem is that sympa must be able to refresh these aliases for opensmtpd.
This sounds simple, but as I mentionned, this action will be attempted by the unprivileged "sympa" user, not root, nor opensmtpd.

For this, sympa has a built-in mechanism that works for most MTAs:

/usr/lib/sympa/bin/sympa_newaliases-wrapper

This small binary helper is actually a very simple wrapper around the "newaliases" command, that will be run automatically after each time sympa updates its aliases list.

However, there are three issues with this in our case:

• currently the wrapper tries to run /usr/bin/newaliases, however opensmtpd replaces this file and puts it in /usr/sbin/newaliases, so the wrapper will simply not find it.
• /usr/sbin/newaliases, in opensmtpd, will only refresh the /etc/aliases file, which is not where sympa should write its own aliases (for a lot of reasons I will not get into, one of them being security.)
• in any case, opensmtpd actually creates /usr/sbin/newaliases as a symlink to /usr/sbin/smtpctl, which is a very powerful command, and requires root.

For all these reasons, there is only one proper workaround that I know of:

First, use the default file where sympa will drop its aliases.
In my case, for debian, it's in

/etc/mail/sympa/aliases

Make sure this file is owned and RW by the sympa user, and that its directory (/etc/mail/sympa) is also owned by sympa, as it will need to create a a aliases.db file there.

Then, add these lines on top of this /etc/mail/sympa/aliases file:

listmaster: "| /usr/lib/sympa/bin/queue [email protected]"
bounce+*: "| /usr/lib/sympa/bin/bouncequeue [email protected]"
abuse-feedback-report: "| /usr/lib/sympa/bin/bouncequeue [email protected]"
sympa-request: postmaster
sympa-owner: postmaster

these aliases are needed for basic sympa function, and they actually need to be included in this file in our setup (due to opensmtpd only matching one rule line for this domain, and only using the "lists" aliases table we saw earlier, in case you wonder why)
Please note that the postmaster aliases do not lead to a pipe command, so these, in this form, would be processed by the "deliver to mbox" part of our smtpd.conf rule line.)

Then, we will need to create a helper script. You can put it wherever and call it whatever, but for clarity, I'll use

/usr/lib/sympa/bin/opensmtpd_refresh_lists.sh

in this file, put the following exact content:

#!/usr/bin/env bash
PATH=/usr/sbin/:$PATH
/usr/sbin/makemap hash /etc/mail/sympa/aliases < /etc/mail/sympa/aliases
/bin/chmod 744 /etc/mail/sympa/aliases.db

if your sympa aliases file is in another directory, adapt it in the script.

the PATH hack is needed because this script will be run by the "sympa" user, which on a typical debian system does not have /usr/sbin directory in its PATH env variable. Even if we call directly /usr/sbin/makemap with its absolute path, makemap will actually call itself within its code, with a relative path, so without /usr/sbin/ in PATH, it will fail to call itself with a "execlp: No such file or directory" error.

In case you wonder, makemap is also a symlink to /usr/sbin/smtpctl, and this exact syntax will trigger a sendmail compatibility mode, that is the only practical way for a non-root user to generate an aliases.db file. As of July 2017 this is the only known way to do it.

Save the file and give it the right permissions:

chown sympa:sympa /usr/lib/sympa/bin/opensmtpd_refresh_lists.sh
chmod 755 /usr/lib/sympa/bin/opensmtpd_refresh_lists.sh

Again, you could chmod it to 750 or 700 if you really don't trust other users in this system.

Now, we need to override the default aliases refresh mechanism for sympa, luckily we have an option for that that we can add to out sympa.conf file:

aliases_program /usr/lib/sympa/bin/opensmtpd_refresh_lists.sh 

To recap quickly, everytime sympa created a new list, it will add new lines to the /etc/mail/sympa/aliases plaintext file, then it will call our opensmtpd_refresh_lists.sh script wich will compile /etc/mail/sympa/aliases to a binary /etc/mail/sympa/aliases.db file, that opensmtpd will read automatically for each received mail.

This is why we need it to be a "db:" entry in our smtpd.conf file:

	table lists db:/etc/mail/sympa/aliases.db

as using a "file:" plaintext reference to the /etc/mail/sympa/aliases file would need opensmtpd to re-read this file with a "smtpctl update table lists" command that the "sympa" user simply doesn't have the permission to run.

If everything is set up, you can try creating a new list from the sympa web UI, see that you don't get any error, then send a mail to this newly created list and check that it shows up in the message archive. Add some other subscribers to that list to make sure sympa is able to send mails t othe outside world.

Do not forget to add this line to your sympa.conf :

dmarc_protection_mode dmarc_reject

or else you won't be able to relay messages from yahoo and similarly dmarc-strict providers.

A big thanks to all the people on #sympa's freenode IRC channel who helped me overcome all the challenges you don't see behind these instructions :)

Hi,
I’m Cornelius from „Fraunhofer Gesellschaft“ in germany.
We use sympa 6.2.16 for our +60 institutes with nearly 30.000 employees.

I just tried your newest version and there is also one function in the
serveradmin.tt2 template missing.

We had the old version 6.1.17 running until 2016, there you could
Change „old_email“ to „new_email“.

I added the part manuelly to the file serveradmin.tt2 (Line 70 to 81):
serveradmin.tt2.txt

This is very important to us, because we have several name-changes through
the year. Also we use strict access by smartcard. So after the rename of one
user it would only be possible to change the e-mail-adresse by hand in the
mysql-database. But the best way is to change it with the template function.

Hi to all,
my problem is the - caracter in the filed attrs on the include_ldap_query.
In the last version of sympa (6.1.x) my workaround is changed the value of the List.pm at line:

'include_ldap_query' => {'format' => {'host' => {'format...
...
'attrs' => {'format' => '\w+',

to:

'include_ldap_query' => {'format' => {'host' => {'format...
...
'attrs' => {'format' => '.+',

but now???? This problem blocking my organization....

The button on the view compose_mail/eshop-news/html_news_letter says Send to selected receipient, but it simply sends it to the whole list. So it is confusing (aside from the typo ...).

Hello,

Since an update from 2.1.16 to 6.2.16 version, the "subject_list" field in "list_table" table is set to "NULL" for new created lists and is no more updated when changing the subject for an existing list.

Is this a normal new behavior ? Is the list subject only stored into the list config file ?

Best regards,
Vincent

Original report.

Summary: With mobile browser, custom attributes submitted in subscriber options page are sometimes omitted. Disabling respoisive table feature avoids this problem.

I replaced web_tt2/edit_attributes.tt2 with following content not using table, and problem looks dissolved.

<!-- edit_attributes.tt2 -->
[% IF list_conf.custom_attribute && list_conf.custom_attribute.size > 0 ~%]
  <label>[%|loc%]Additional information[%END%]</label>
  <div class="row">
    <div class="small-9 large-10 columns">
      <i>[%|loc%]*: Required element[%END%]</i>
    </div>
  </div>

  <div class="row">
    <div class="small-9 large-10 columns">
    [% FOREACH k IN list_conf.custom_attribute ~%]
      [% SET ca_id = "custom_attribute.${k.id}" ~%]
      [% SET ca_value = subscriber.custom_attribute.item(k.id).value ~%]

      <label for="[% ca_id %]">
        [%|loc(k.name)%]%1:[% END %]
        [% IF k.optional == 'required' %]*[% END %]
        [% IF k.comment ~%]
          <a href="#" class="accordionButton"
           data-selector="#help\.[% ca_id.replace('[.]', '\\.') %]">
          <i class="fa fa-question-circle" title="[%|loc%]Help[%END%]"></i>
          </a>
        [%~ END %]
      </label>

      [% IF k.comment ~%]
        <div id="help.[% ca_id %]" class="panel radius">
        <p>[% k.comment %]</p>
        </div>
      [%~ END %]

      [% IF k.type == 'string' ~%]
        <input type="text" name="[% ca_id %]" id="[% ca_id %]"
         value="[% ca_value %]" />
      [%~ ELSIF k.type == 'integer' ~%]
        <span style="display:inline-block">
        <input type="text" name="[% ca_id %]" id="[% ca_id %]"
         value="[% ca_value %]" size="10" />
        </span>
      [%~ ELSIF k.type == 'text' ~%]
        <textarea rows="5" name="[% ca_id %]" id="[% ca_id %]" maxlength="500">
          [%~ ca_value ~%]
        </textarea>
      [%~ ELSIF k.type == 'enum' ~%]
        <select name="[% ca_id %]">
        <option value=""></option>
        [% FOREACH l IN k.enum_values.split(',') ~%]
          <option
           [%~ IF l == "${ca_value}" %] selected[% END %]
           value="[% l %]">[% l %]</option>
        [%~ END %]
        </select>
      [%~ ELSE ~%]
        <input type="hidden" name="[% ca_id %]" id="[% ca_id %]"
         value="[% ca_value %]" />
        [% ca_value %]
      [%~ END %]
    [%~ END %]
    </div>
  </div>
[%~ END %]
<!-- end edit_attributes.tt2 -->

Using Sympa 6.2.18. When trying to change privileged owners for a mailing list using the web interface, the following error message appears and the change fails:

DIED: missing parameter "user" at /usr/share/sympa/lib/Sympa.pm line 519. Sympa::send_notify_to_user(Sympa::List <[email protected]>, 'added_as_listadmin', '', HASH(0xde4a230)) called at /usr/libexec/sympa/wwsympa.fcgi line 11847 main::_notify_added_admin(Sympa::List::Config <[email protected]>) called at /usr/libexec/sympa/wwsympa.fcgi line 11609 main::do_edit_list() called at /usr/libexec/sympa/wwsympa.fcgi line 1680

List administrators (owners and editors) are stored both in database and list config file. Duplicate information cause complexity of the code, and synchronization between both occasionally fails.

One of adequate changes seems deprecating owner/editor fields in list config file. Even doing this, all information will be kept in database.

It is really unacceptable for me to not log the actual DBI error. 🤐

Jul 28 12:28:49 belukha sympa_msg[29957]: err main::#87 > main::_load#314 > Sympa::DatabaseManager::instance#54 > Sympa::DatabaseDriver::PostgreSQL::connect#54 > Sympa::Database::connect#155 Can't connect to Database Sympa::DatabaseDriver::PostgreSQL <db_host=localhost;db_name=sympa;db_port=3306;db_user=sympa>
Jul 28 12:28:49 belukha sympa_msg[29957]: err main::#87 > main::_load#317 DIED: Database sympa defined in sympa.conf is unreachable. verify db_xxx parameters in sympa.conf
Jul 28 12:28:49 belukha sympa_msg.pl[29957]: DIED: Database sympa defined in sympa.conf is unreachable. verify db_xxx parameters in sympa.conf

This button trys to protect the mailing lists archives against address harvesting by a Spammer.

3rd person of try is "tries" - and spammer should be lowercase. In addition this message is quite pathetic in general. I will try to come up with a better one.

This causes the following error message - and I certainly didn't select a file to upload:

ERROR (send_mail) - You specified both an URL and a file to upload. Sympa can't choose which one to send. Please fill the form with one of them only. A web page OR a file to upload.

Currently, there are duplicate feature to record result of an action:

1. Notices and errors on web page (web interface), command result (mail interface) or rejection of delivery.
2. Logging to syslog (Sympa::Log::syslog() or wwslog() in wwsympa).
3. Database log (Sympa::Log::db_log() or web_db_log() in wwsympa).
4. Statistics (Sympa::Log::add_stat() or web_db_stat_log() in wwsympa).

In above, 1., 2. and 3. output duplicate information. Especially, 3. does not always cooccur with others: There seem no clear rules describing when logs are recorded into database.

Thus, I propose to remove feature of database logging once. If it turned out that database log is useful, it may be reimplemented with more clear feature.

If an owner was deleted added at one time, changes will be ignored with following error message:

Duplicate value '(e-mail address)' for parameter 'email address'. Ignoring change.

How to reproduce

The operator is the privileged owner.

1. Set two or more owners.
2. Check "delete" box of one owner and enter another owner with the same e-mail.
3. Click "Update".

Hello!

I would like to add Vacation message to Message templates, so users can change it easily.
Could someone give some more detailed info, http://www.sympa.org/contribs/vacation. My test experiment was unsuccessful :(

Or this feature is planned to be in Message templates in near future?

Thanks

To close large lists we use the command line method:

sympa.pl --close_list=list@robot

since the process takes long enough that the web method times out.

Today we ran into a situation where were needed to restore a large
list, but there doesn't seem to be a --restore_list option.

I took a look at what wwsympa is doing and for closing lists (in
do_close_list) and it's calling the generic $list->close from List.pm,
but for restoring lists (in do_restore_list) it's doing a bunch of
the work itself (change status, save config, restore subscriber dump,
insert users in db, savestats, setup aliases, etc).

Could it be refactored and moved into a $list->restore
in List.pm and we could also get a --restore_list option?

Thanks

OS : DEBIAN 9
SYMPA 6.2.16 from debian package repository
MHonArc v2.6.19+ from debian package repository

sympa_wizard --check don't detect MHonArc : MHonArc::UTF8 n'a pas été trouvé sur le sytème.

wwsympa work like a charm, archives are generated with MHonArc v2.6.19+.

I didn't know if this was something separate from #7 or something different. #7 deals with editing the admins (owners and/or editors). However, this problem has to do with syncing these admins from a datasource. I'm going to attached an excerpt of the log regarding such a sync. The lines with "AAG" are additional log statements I inserted in an attempt to get more information about this. One thing that's frustrating is that I have not been able to replicate this behavior on the test system, despite them having the same sympa version, same perl version, same module versions (at least mostly.)

In the attached log excerpt, the list "ecs.bmen.staff" includes the list "etech" as owners.

etech-sympa-log.txt

This feature is used by a lot of servers so it would make total sense for Sympa too. It allows to break down the configuration in smaller pieces and also information like database credentials and cookie values can be managed in a separate file. It would also make packaging Sympa a lot easier.

E.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863701.

Including system commands for evaluation in the configuration looks like a retarded concept to me.

Hello,
I need to show "my lists" on home page (into adiv) but they systematically show "No subscription.".
When home page is called [% which %] is empty

OS : DEBIAN 9
SYMPA 6.2.16 from debian package repository

Portion of my home.tt2 :

...
[% IF user.email  %]
 <article class="small-12 medium-4 columns home">
    <div>
      [% PROCESS my.tt2 %]
    </div>
  </article>
[% END %]
...

logs (level 4) :
my lists :

Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_admin FROM admin_table WHERE robot_admin = ? AND user_admin = ? AND role_admin = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_admin FROM admin_table WHERE robot_admin = ? AND user_admin = ? AND role_admin = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::new(test, listes.xxxxx.xx, skip_name_check/skip_sync_admin/filter)
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::new(test, listes.xxxxx.xx, skip_name_check/skip_sync_admin/filter)
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::load(Sympa::List <[email protected]>, test, listes.xxxxx.xx, ...)
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::load(Sympa::List <[email protected]>, test, listes.xxxxx.xx, ...)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::List::_load_stats_file(/var/lib/sympa/list_data/test/stats)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::List::_load_stats_file(/var/lib/sympa/list_data/test/stats)
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::get_lists(listes.xxxxx.xx, filter)
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::get_lists(listes.xxxxx.xx, filter)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::List::get_lists() filter ! ($list->{"admin"}{"status"} eq "closed" || $list->{"admin"}{"status"} eq "family_closed"); NOT (status_list = 'closed' OR status_list = 'family_closed')
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::List::get_lists() filter ! ($list->{"admin"}{"status"} eq "closed" || $list->{"admin"}{"status"} eq "family_closed"); NOT (status_list = 'closed' OR status_list = 'family_closed')
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_admin FROM admin_table WHERE robot_admin = ? AND user_admin = ? AND role_admin = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_admin FROM admin_table WHERE robot_admin = ? AND user_admin = ? AND role_admin = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug2 main::check_param_out() [robot listes.xxxxx.xx] [session 29732301565425] [client 192.168.0.1] [user [email protected]]
Sep 22 11:05:33 listes wwsympa[9852]: debug2 main::check_param_out() [robot listes.xxxxx.xx] [session 29732301565425] [client 192.168.0.1] [user [email protected]]
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Session::store()
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Session::store()
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT id_session FROM session_table WHERE prev_id_session = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT id_session FROM session_table WHERE prev_id_session = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "UPDATE session_table SET date_session = ?, remote_addr_session = ?, robot_session = ?, email_session = ?, start_date_session = ?, hit_session = ?, data_session = ? WHERE id_session = ? AND prev_id_session IS NOT NULL OR prev_id_session = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "UPDATE session_table SET date_session = ?, remote_addr_session = ?, robot_session = ?, email_session = ?, start_date_session = ?, hit_session = ?, data_session = ? WHERE id_session = ? AND prev_id_session IS NOT NULL OR prev_id_session = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Session::renew(id_session=29732301565425)
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Session::renew(id_session=29732301565425)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT id_session FROM session_table WHERE prev_id_session = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT id_session FROM session_table WHERE prev_id_session = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_query() Will perform query "INSERT INTO session_table (id_session, prev_id_session, start_date_session, date_session, refresh_date_session, remote_addr_session, robot_session, email_session, hit_session, data_session) SELECT '80889355860585', id_session, start_date_session, date_session, 1506071133, '192.168.0.1', 'listes.xxxxx.xx', email_session, hit_session, data_session FROM session_table WHERE (id_session = '29732301565425' AND prev_id_session IS NOT NULL OR prev_id_session = '29732301565425') AND (remote_addr_session <> '192.168.0.1' OR refresh_date_session <= 1506071091)"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_query() Will perform query "INSERT INTO session_table (id_session, prev_id_session, start_date_session, date_session, refresh_date_session, remote_addr_session, robot_session, email_session, hit_session, data_session) SELECT '80889355860585', id_session, start_date_session, date_session, 1506071133, '192.168.0.1', 'listes.xxxxx.xx', email_session, hit_session, data_session FROM session_table WHERE (id_session = '29732301565425' AND prev_id_session IS NOT NULL OR prev_id_session = '29732301565425') AND (remote_addr_session <> '192.168.0.1' OR refresh_date_session <= 1506071091)"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "UPDATE session_table SET prev_id_session = NULL WHERE id_session = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "UPDATE session_table SET prev_id_session = NULL WHERE id_session = ?"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "DELETE FROM session_table WHERE id_session = ? AND prev_id_session IS NULL"
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "DELETE FROM session_table WHERE id_session = ? AND prev_id_session IS NULL"
Sep 22 11:05:33 listes wwsympa[9852]: info Sympa::Session::renew() [robot listes.xxxxx.xx] [session 29732301565425] [client 192.168.0.1] [user [email protected]] new session 80889355860585
Sep 22 11:05:33 listes wwsympa[9852]: info Sympa::Session::renew() [robot listes.xxxxx.xx] [session 29732301565425] [client 192.168.0.1] [user [email protected]] new session 80889355860585
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Session::set_cookie(.xxxxx.xx, session, secure= )
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Session::set_cookie(.xxxxx.xx, session, secure= )
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::search_fullpath(listes.xxxxx.xx, css.tt2, subdir)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::search_fullpath(listes.xxxxx.xx, css.tt2, subdir)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::get_search_path(listes.xxxxx.xx, lang_only, 1)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::get_search_path(listes.xxxxx.xx, lang_only, 1)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::get_search_path(listes.xxxxx.xx, subdir, web_tt2)
Sep 22 11:05:33 listes wwsympa[9852]: debug3 Sympa::get_search_path(listes.xxxxx.xx, subdir, web_tt2)
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::new(test, listes.xxxxx.xx, )
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::new(test, listes.xxxxx.xx, )
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::load(Sympa::List <[email protected]>, test, listes.xxxxx.xx, ...)
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::List::load(Sympa::List <[email protected]>, test, listes.xxxxx.xx, ...)
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::Scenario::request_action(Sympa::List <[email protected]>, archive.web_access, md5, HASH, )
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::Scenario::request_action(Sympa::List <[email protected]>, archive.web_access, md5, HASH, )
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::Scenario::new()
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::Scenario::new()
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::Scenario::new()
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::Scenario::new()
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Scenario::new() Unable to read file /var/lib/sympa/list_data/test/scenari/include.archive.web_access.header
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Scenario::new() Unable to read file /var/lib/sympa/list_data/test/scenari/include.archive.web_access.header
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Scenario::new() Unable to read file /etc/sympa/listes.xxxxx.xx/scenari/include.archive.web_access.header
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Scenario::new() Unable to read file /etc/sympa/listes.xxxxx.xx/scenari/include.archive.web_access.header
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Scenario::new() Unable to read file /etc/sympa/scenari/include.archive.web_access.header
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Scenario::new() Unable to read file /etc/sympa/scenari/include.archive.web_access.header
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Scenario::new() Unable to read file /usr/share/sympa/default/scenari/include.archive.web_access.header
Sep 22 11:05:33 listes wwsympa[9852]: debug Sympa::Scenario::new() Unable to read file /usr/share/sympa/default/scenari/include.archive.web_access.header
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::Scenario::verify(HASH, true(), HASH, )
Sep 22 11:05:33 listes wwsympa[9852]: debug2 Sympa::Scenario::verify(HASH, true(), HASH, )

home:

Sep 22 11:06:04 listes wwsympa[9852]: info main::do_home() [robot listes.xxxxxxx.xx] [session 80889355860585] [client 192.168.0.1] [user [email protected]]
Sep 22 11:06:04 listes wwsympa[9852]: info main::do_home() [robot listes.xxxxxxx.xx] [session 80889355860585] [client 192.168.0.1] [user [email protected]]
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_which([email protected], listes.xxxxxxx.xx, owner)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_which([email protected], listes.xxxxxxx.xx, owner)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_lists(listes.xxxxxxx.xx, filter)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_lists(listes.xxxxxxx.xx, filter)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() filter ! ($list->{"admin"}{"status"} eq "closed" || $list->{"admin"}{"status"} eq "family_closed"); NOT (status_list = 'closed' OR status_list = 'family_closed')
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() filter ! ($list->{"admin"}{"status"} eq "closed" || $list->{"admin"}{"status"} eq "family_closed"); NOT (status_list = 'closed' OR status_list = 'family_closed')
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_admin FROM admin_table WHERE robot_admin = ? AND user_admin = ? AND role_admin = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_admin FROM admin_table WHERE robot_admin = ? AND user_admin = ? AND role_admin = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::new(test, listes.xxxxxxx.xx, skip_name_check/skip_sync_admin/filter)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::new(test, listes.xxxxxxx.xx, skip_name_check/skip_sync_admin/filter)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::load(Sympa::List <[email protected]>, test, listes.xxxxxxx.xx, ...)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::load(Sympa::List <[email protected]>, test, listes.xxxxxxx.xx, ...)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_which([email protected], listes.xxxxxxx.xx, editor)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_which([email protected], listes.xxxxxxx.xx, editor)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_lists(listes.xxxxxxx.xx, filter)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_lists(listes.xxxxxxx.xx, filter)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() filter ! ($list->{"admin"}{"status"} eq "closed" || $list->{"admin"}{"status"} eq "family_closed"); NOT (status_list = 'closed' OR status_list = 'family_closed')
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() filter ! ($list->{"admin"}{"status"} eq "closed" || $list->{"admin"}{"status"} eq "family_closed"); NOT (status_list = 'closed' OR status_list = 'family_closed')
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_admin FROM admin_table WHERE robot_admin = ? AND user_admin = ? AND role_admin = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_admin FROM admin_table WHERE robot_admin = ? AND user_admin = ? AND role_admin = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_which([email protected], listes.xxxxxxx.xx, member)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_which([email protected], listes.xxxxxxx.xx, member)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_lists(listes.xxxxxxx.xx, filter)
Sep 22 11:06:04 listes wwsympa[9852]: debug2 Sympa::List::get_lists(listes.xxxxxxx.xx, filter)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() filter ! ($list->{"admin"}{"status"} eq "closed" || $list->{"admin"}{"status"} eq "family_closed"); NOT (status_list = 'closed' OR status_list = 'family_closed')
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() filter ! ($list->{"admin"}{"status"} eq "closed" || $list->{"admin"}{"status"} eq "family_closed"); NOT (status_list = 'closed' OR status_list = 'family_closed')
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_lists() order ; name_list
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_subscriber FROM subscriber_table WHERE robot_subscriber = ? AND user_subscriber = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT list_subscriber FROM subscriber_table WHERE robot_subscriber = ? AND user_subscriber = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_shared_moderated()
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::get_shared_moderated()
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::sort_dir_to_get_mod()
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::List::sort_dir_to_get_mod()
Sep 22 11:06:04 listes wwsympa[9852]: debug2 main::check_param_out() [robot listes.xxxxxxx.xx] [session 80889355860585] [client 192.168.0.1] [user [email protected]]
Sep 22 11:06:04 listes wwsympa[9852]: debug2 main::check_param_out() [robot listes.xxxxxxx.xx] [session 80889355860585] [client 192.168.0.1] [user [email protected]]
Sep 22 11:06:04 listes wwsympa[9852]: debug Sympa::Session::store()
Sep 22 11:06:04 listes wwsympa[9852]: debug Sympa::Session::store()
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT id_session FROM session_table WHERE prev_id_session = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT id_session FROM session_table WHERE prev_id_session = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "UPDATE session_table SET date_session = ?, remote_addr_session = ?, robot_session = ?, email_session = ?, start_date_session = ?, hit_session = ?, data_session = ? WHERE id_session = ? AND prev_id_session IS NOT NULL OR prev_id_session = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "UPDATE session_table SET date_session = ?, remote_addr_session = ?, robot_session = ?, email_session = ?, start_date_session = ?, hit_session = ?, data_session = ? WHERE id_session = ? AND prev_id_session IS NOT NULL OR prev_id_session = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug Sympa::Session::renew(id_session=80889355860585)
Sep 22 11:06:04 listes wwsympa[9852]: debug Sympa::Session::renew(id_session=80889355860585)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT id_session FROM session_table WHERE prev_id_session = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "SELECT id_session FROM session_table WHERE prev_id_session = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_query() Will perform query "INSERT INTO session_table (id_session, prev_id_session, start_date_session, date_session, refresh_date_session, remote_addr_session, robot_session, email_session, hit_session, data_session) SELECT '00035266018246', id_session, start_date_session, date_session, 1506071164, '192.168.0.1', 'listes.xxxxxxx.xx', email_session, hit_session, data_session FROM session_table WHERE (id_session = '80889355860585' AND prev_id_session IS NOT NULL OR prev_id_session = '80889355860585') AND (remote_addr_session <> '192.168.0.1' OR refresh_date_session <= 1506071133)"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_query() Will perform query "INSERT INTO session_table (id_session, prev_id_session, start_date_session, date_session, refresh_date_session, remote_addr_session, robot_session, email_session, hit_session, data_session) SELECT '00035266018246', id_session, start_date_session, date_session, 1506071164, '192.168.0.1', 'listes.xxxxxxx.xx', email_session, hit_session, data_session FROM session_table WHERE (id_session = '80889355860585' AND prev_id_session IS NOT NULL OR prev_id_session = '80889355860585') AND (remote_addr_session <> '192.168.0.1' OR refresh_date_session <= 1506071133)"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "UPDATE session_table SET prev_id_session = NULL WHERE id_session = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "UPDATE session_table SET prev_id_session = NULL WHERE id_session = ?"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "DELETE FROM session_table WHERE id_session = ? AND prev_id_session IS NULL"
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::Database::do_prepared_query() Will perform query "DELETE FROM session_table WHERE id_session = ? AND prev_id_session IS NULL"
Sep 22 11:06:04 listes wwsympa[9852]: info Sympa::Session::renew() [robot listes.xxxxxxx.xx] [session 80889355860585] [client 192.168.0.1] [user [email protected]] new session 00035266018246
Sep 22 11:06:04 listes wwsympa[9852]: info Sympa::Session::renew() [robot listes.xxxxxxx.xx] [session 80889355860585] [client 192.168.0.1] [user [email protected]] new session 00035266018246
Sep 22 11:06:04 listes wwsympa[9852]: debug Sympa::Session::set_cookie(.xxxxxxx.xx, session, secure= )
Sep 22 11:06:04 listes wwsympa[9852]: debug Sympa::Session::set_cookie(.xxxxxxx.xx, session, secure= )
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::search_fullpath(listes.xxxxxxx.xx, css.tt2, subdir)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::search_fullpath(listes.xxxxxxx.xx, css.tt2, subdir)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::get_search_path(listes.xxxxxxx.xx, subdir, web_tt2)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::get_search_path(listes.xxxxxxx.xx, subdir, web_tt2)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::get_search_path(listes.xxxxxxx.xx, subdir, web_tt2)
Sep 22 11:06:04 listes wwsympa[9852]: debug3 Sympa::get_search_path(listes.xxxxxxx.xx, subdir, web_tt2)

While playing with include_ldap_query, I found what I think is an undocumented behaviour.
If filling attrs with, say, "mail,cn", both the email and name appear when reviewing the list members.
The fact that you can use 2 attributes in the attrs field, first for email and second for name, is not documented.

However, the same behaviour cannot be reproduced with include_ldap_2level_query.
Using attrs2="mail" works, the dynamic list is properly populated with the emails.
Using attrs2="mail,cn" just gives an empty subscribers list.

This is with sympa 6.2.19 beta2.

Hello!

Sympa version: 6.2.18

# grep "lang" /etc/sympa/sympa.conf | grep -v '#'
supported_lang	et,fi,it,fr,pl,en-US
lang    et

I would like to set et to default language, but still en-US is default language. Only how I can change default language is to remove the en-US from the supported_lang parameter. I would like to keep en-US also, so users can choose it from Sympa GUI.

I'dont have any robot.conf, which overrides it.

Is it bug or am I missing something?

thanks
Margo

Hello!

Sympa version: 6.2.18

If changing list owner/editor parameters (profile, reception, visibility), internal server error occurs. For example changing list owner (already set) profile "privileged owner" to "normal owner". And I am able to crash fcgi (needs restart).

I can change owner/editor parameter, if changing "user" email.

Internal Server Error
Sympa encountered an internal error.
Please contact the listmaster.

Error: missing parameter "user" at /home/sympa/bin/Sympa.pm line 519.
Traceback

DIED: missing parameter "user" at /home/sympa/bin/Sympa.pm line 519.
 at /home/sympa/bin/Sympa.pm line 519.
	Sympa::send_notify_to_user(Sympa::List <listname@domain>, 'added_as_listadmin', '', HASH(0x65c3c70)) called at /home/sympa/bin/wwsympa.fcgi line 11847
	main::_notify_added_admin(Sympa::List::Config <listname@domain>) called at /home/sympa/bin/wwsympa.fcgi line 11609
	main::do_edit_list() called at /home/sympa/bin/wwsympa.fcgi line 1680

I tried it in https://demo.sympa.org/sympa, here it works fine.

Thanks

sympa up to 6.2.22 is bundling jquery-ui 1.11.2 which is known to be vulnerable to an XSS.
http://www.cvedetails.com/cve/CVE-2016-7103/

When you install a new version of sympa 6.20 or 6.22, the initscript generated has the following warning on a Debian system (wheezy):
/etc/init.d/sympa: line 262: [: =: unary operator expected

Adding quotes around the NETWORK reference in if [ ${NETWORKING} = "no" ] in sympa-6.2.22/src/etc/script/sympa.in

if [ "${NETWORKING}" = "no" ]

seems to do the trick

Hey,
I get in /var/spool/sympa/tmp/PID.stderr the following message:
Use of uninitialized value in numeric le (<=) at /usr/share/sympa/lib/Sympa/List.pm line 1391.
The PID from sympa_msg.pl
I'm using debian 9 (Stretch), with sympa 6.2.16~dfsg-3 and perl v5.24.1

I have the following definitions.

/deploy/sympa/etc/data_sources/owner_or_moderator_sympa_list.incl:

include_sympa_list
name owner_or_moderator_sympa_list
listname [% param.0 %]

/deploy/sympa/list_data/ecs.bmen.staff/config:

owner_include
profile privileged
reception mail
source owner_or_moderator_sympa_list
visibility conceal
source_parameters etech

However, even though the logic seems to work, get the following in the logs:

Apr 21 10:15:49 aispsympa01 task_manager[35865]: info Sympa::List::_load_include_admin_user_file()
Bad entry "listname [% param.0 %]" for key "listname", paragraph "include_sympa_list" in
/deploy/sympa/etc/data_sources/owner_or_moderator_sympa_list.incl

Apr 21 10:15:49 aispsympa01 task_manager[35865]: info Sympa::List::_load_include_admin_user_file()
Missing key "listname" in param "include_sympa_list" in
/deploy/sympa/etc/data_sources/owner_or_moderator_sympa_list.incl

When a list is configured to accept mail from owners or editors, adding new owners or new editors needs a restart of Sympa for the mail to be accepted when sending by these new ones.

Somebody says that's normal because the scenari are in a cache but we can't restart Sympa at each mdofication of the owners or editors

Hi,

We encounter some problem with some lists when the second query from an include_users_ldap_2level try to query an object that doesn't exist in our LDAP.

First : task_manager.pl died when he was trying to sync those lists.
Second : if we send a mail to those lists, sympa_msg.pl dies too.
Third : this makes "review subscriber" page unavailable to the user.

From the sympa log :

DIED: Can't call method "shift_entry" on an undefined value at /var/lib/sympa/bin/Sympa/List.pm line 5625, <DATA> line 558.
	Sympa::List::_include_users_ldap_2level(HASH(0xa475a9c), '0ad4baf2', HASH(0xad0af90), Sympa::DatabaseDriver::LDAP <bind_dn=uid=sympa,o=mondomaine,c=fr;ca_verify=required;host=ldap://ldap.mondomaine.fr;ssl_ciphers=ALL;ssl_version=sslv2;use_tls=none>, HASH(0xa9484ac)) called at /var/lib/sympa/bin/Sympa/List.pm line 6128
	Sympa::List::_load_list_members_from_include(Sympa::List <[email protected]>, HASH(0xa49f4d8)) called at /var/lib/sympa/bin/Sympa/List.pm line 6900
	Sympa::List::sync_include(Sympa::List <[email protected]>) called at /var/lib/sympa/bin/Sympa/List.pm line 7252
	Sympa::List::on_the_fly_sync_include(Sympa::List <[email protected]>, 'use_ttl', 1) called at /var/lib/sympa/bin/Sympa/Spindle/ToList.pm line 182
	Sympa::Spindle::ToList::_send_msg(Sympa::Message <[email protected]_e4616dc19e1bdf865ccd9d3bfa9e6cf3.distribute>, undef) called at /var/lib/sympa/bin/Sympa/Spindle/ToList.pm line 55
	Sympa::Spindle::ToList::_twist(Sympa::Spindle::ProcessModeration=HASH(0xab31794), Sympa::Message <[email protected]_e461adc12e1cdf465ccd9d3bfa9e6cf3.distribute>) called at /var/lib/sympa/bin/Sympa/Spindle.pm line 92
	Sympa::Spindle::spin(Sympa::Spindle::ProcessModeration=HASH(0xab31794)) called at /var/lib/sympa/bin/Sympa/Request/Handler/distribute.pm line 60
	Sympa::Request::Handler::distribute::_twist(Sympa::Spindle::ProcessMessage=HASH(0xab350b4), Sympa::Request <action=distribute;[email protected]>) called at /var/lib/sympa/bin/Sympa/Spindle.pm line 92
	Sympa::Spindle::spin(Sympa::Spindle::ProcessMessage=HASH(0xab350b4)) called at /var/lib/sympa/bin/Sympa/Spindle/DoCommand.pm line 117
	Sympa::Spindle::DoCommand::_twist(Sympa::Spindle::ProcessIncoming=HASH(0xa903124), Sympa::Message <[email protected],6337>) called at /var/lib/sympa/bin/Sympa/Spindle.pm line 92
	Sympa::Spindle::spin(Sympa::Spindle::ProcessIncoming=HASH(0xa903124)) called at /var/lib/sympa/bin/sympa_msg.pl line 240

I know that our LDAP should be clean and contain no reference to a missing object, but is it possible, for this case, to catch an error and not raise an exception ?

Thanks a lot,
Yoann

It could be useful to propose a tool to import data (configuration and content) from googlegroups to a sympa server.

• Do you know if there is anything existing currently?
• If not, could it be a tool proposed with sympa?

Thank you

When you use the List Administrator's ability to globally change a user's email (/serveradmin/users) it works great.
But once the update completes, you are redirected via the move_user action to your own preferences page (/pref).
This seems odd. Wouldn't it make more sense to redirect either to the Listmaster Admin menu, or right back to the Listmaster Admin / Users submenu, especially since global email changes tend to happen in batches?

Lists can have host parameter overriding host part of list addresses derived from virtual host the list belongs to.

• Cons:

  It breaks alias management: When a list is removed, alias manager cannot find aliases to be removed; If users (owners) change this parameter, aliases won't be renamed. At least current implementaion cannot handle those situations properly.

• Pros:

  Users (listmasters) can categorize lists with multiple domains under one virtual host. It may be useful for some service providors hosting list services to users by each virtual domain.

IMO this feature would be better to be removed for simplicity of implementation.

When packaging Sympa for Yunohost, I soon realized that sympa (and even cpan, during install !?) was getting killed because of OOM. After investigating, I saw that Sympa, when not doing anything (i.e. right after install) consumes about O(400 Mo) of RAM.

I understand that Sympa is meant to be an entreprise-grade/large-scale application, but imho this is way too much. In the Yunohost community (but probably in the self-hosting community as a whole), people have heard of Sympa and expect it to be a good program to manage a few list for their friends or local club, i.e. basically not more than a dozen of list with O(10~100 people) on it.

But because it takes O(400 Mo) of RAM, the cost of running it is pretty high. ARM board used for self-hosing typically have around 512 or 1 Go of RAM. So basically, running Sympa costs half a Raspberry Pi. In terms of VPS, such as Digital Ocean droplets, 512 Mo of RAM costs approximately 5$ / month, so running Sympa on a VPS costs about 5$ / month.

And this is for a program that is idling 99% of the time. Right now, in the context of Yunohost packaging, I simply added 500 Mo of swap to the system at the install, but I expect this to drastically reduce the life of SD card for people running ARM boards.

Isn't there any way to reduce the RAM consumption to some acceptable level (e.g. O(50 Mo)) ?

For example, rpm versioning system judges that 6.2.17 is older than 6.2.17b.1 by default. There may be any other systems alike.

1. What version number should we give to the next stable release?
   Either of 6.2.17 (problematic), 6.2.18, 6.3.0 ...and so on.
2. What kind of policy should we adopt to update version numbers?
   How may we determine development and stable releases by version numbers?

Currently (as of 6.2.22), WWSympa (wwsympa.fcgi) may use either FastCGI or CGI. Latter is unuseful in practical use. CGI support would be given up and FastCGI would be made mandatory.

N.B.: SOAP server (sympa_soap_server.fcgi) requires FastCGI support.

Apr 15 09:49:16 post bounced[1513]: notice main:: Bounced 6.2.16 Started
Apr 15 09:49:17 post bounced[1513]: err main::#157 > Sympa::Spindle::spin#75 > Sympa::Spool::next#135 > Sympa::Message::new#180 > MIME::Charset::new#432 > MIME::Charset::_find_encoder#467 > (eval)#1 > (eval)#1 > MIME::Charset::BEGIN#1 DIED: Can't locate Encode/HanExtra.pm in @INC (you may need to install the Encode::HanExtra module) (@INC contains: /usr/share/sympa/lib /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at (eval 204) line 1.

This happened with a Debian install.

So

1. First we need to make sure that this module is installed.
2. Bounced should discard the message and not trying it at every run.

This is related to #25 . In 6.1, under the Admin tab of the web UI, when you searched for a user it would not only show all the lists that user was on, but on the far right there were buttons to edit or delete the subscription. This made it really handy to delete all that user's subscriptions after they left the enterprise. Now, that interface just shows all the lists that user is on, forcing you to visit each list separately and remove that user with much more steps.

There also doesn't appear to be a sympa.pl command option to delete a user from all lists, so unlike with #25, there is no other option to do a mass deletion of a user other than to manually visit each list.

/editsubscriber/test-newsletter/foo.bar%40example.com/review

This link shows "Internal server error" and also spams the listmaster with an email instead of saying "User not found" or something like that.

Sympa version: 6.2.16

Sympa default configuration logs to syslog facility local1.
One needs to configure the local syslogger to have sympa write to, say, /var/log/sympa.log, then restart the syslogger to get any log.
It would be nice to be able to log directly to a file, while still retaining the capability to use a syslogger.

Hi to all,
today i find a issue for log list in the sympa 6.2.20. Infact log is not order by date, even if sorting is set by date.

HTML-formatted emails distributed through Sympa may display an error stating that the message has been tampered with since it was signed. The original signing certificate is intact in the email, and viewing the certificate shows that the certificate matches the original sender, but the warning gives recipients pause. Plain text and rich text emails do not appear to be affected. The issue has been replicated in multiple clients. Our installation is Sympa 6.1.11 on RHEL 6 using Postfix MTA. We have asked the user community for assistance, but we received no response.

I'm bringing here an enhancement request regarding LDAP paged queries already filed in this two tickets:

• https://sourcesup.renater.fr/tracker/?aid=3525 (opened 2007-11-18)
• https://sourcesup.renater.fr/tracker/?aid=7369 (opened 2010-12-17, duplicate of 3525, provides a patch made by [email protected])

(The bug tracker at renater.fr seems to be restricted to users from French institutions, so I'm not able to contribute)

The rationale behind this request was already documented in those tickets (I'm adding some opinions from my own)

• As an LDAP administrator I'd prefer to use paged searches than raising the search result limit each time we think a query might be approaching that limit.
• In large deployments it could not be feasible to raise the limit to any arbitrary value.
• Paged searches allow for more escalabe deployments
• As an LDAP user I might not have full control over the settings of the LDAP server I have to use
• It's perfectly fair to use LDAP paged seaches. By no means it's a way to "work around legitimate limitations" of any RFC, as it was estated by someone in https://sourcesup.renater.fr/tracker/?aid=3525

After upgrading to 6.2.16-1.20170331, we are now getting a significant number of idle sessions on the sympa database. If I don't close them by killing the backends we run out of available connections and that then impacts other services.

The last query executed in most of the sessions would appear to be
SELECT bounce_subscriber AS "bounce", bounce_address_subscriber AS "bounce_address", bounce_score_subscriber AS "bounc
e_score", custom_attribute_subscriber AS "custom_attribute", date_part('epoch',date_subscriber) AS "date", user_subscri
ber AS "email", suspend_end_date_subscriber AS "enddate", comment_subscriber AS "gecos", include_sources_subscriber AS
"id", included_subscriber AS "included", number_messages_subscriber AS "number_messages", reception_subscriber AS "rece
ption", suspend_start_date_subscriber AS "startdate", subscribed_subscriber AS "subscribed", suspend_subscriber AS "sus
pend", topics_subscriber AS "topics", date_part('epoch',update_subscriber) AS "update_date", visibility_subscriber AS "
visibility"+
FROM subscriber_table