Conflicting config.inc.php files due to installer autocopy

[williamdes]

Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
    key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
    (No client certificate requested)
    by xxxx.xxxxx.wdes.eu (Postfix) with ESMTPS id 32C204606D
    for <williamdes@wdes.fr>; Wed, 6 Jul 2022 00:27:21 +0000 (UTC)

Do you want me to make a PR and fancy tests ?

[GermanCoding]

This looks like the usual Postfix TLS received header, so this should work already?

But yeah generally I'm not opposed to supporting other header formats.

[williamdes]

It seems like it does not work, I have set for two ignored hops but it does not help
I think it would be helpful to build a unit test suite

[GermanCoding]

Yeah definetly, testing is always useful. The received header above definetly looks like it should work, but maybe some other headers get in the way?

Edit: Oh, also the support for ignoring headers isn't currently in 1.1, only if you pull dev-master via composer. Probably going to make a new release soon.

[williamdes]

Thank you for the release !
French translations work as expected, the hops do not help and internal or external emails are not handled correctly
So I will make other PRs to improve and test all that ;)

[williamdes]

By the way my mails use the docker mailserver project

[williamdes]

Just added a test for this in #8

[williamdes]

After some debug I found out that the config is set to 0 for some reason (probably the default config is loaded, why ? how ?)

["tls_icon_ignore_hops"]=> int(0)

[williamdes]

Hi @GermanCoding
I did figure out what was wrong, it comes from this plugin:

• if you look at other plugins
  • Most of them use config.inc.php.dist files
  • Have commented out the config lines in config.inc.php` files

So I commented out the line in /usr/src/roundcubemail/plugins/tls_icon/config.inc.php and restarted the docker container
And now my config /var/roundcube/config/tls_icon.php is taken in account. And the TLS header that I reported works fine !

What do you think about what I reported ?

---

docker-compose.yml

roundcube-webmail:
        build: ../../docker/roundcube
        restart: on-failure:15
        volumes:
          - ../../config/roundcube/config/:/var/roundcube/config/:ro
        environment:
            ROUNDCUBEMAIL_SIEVE_HOST: imap.example.org
            ROUNDCUBEMAIL_DEFAULT_HOST: ssl://imap.example.org
            ROUNDCUBEMAIL_DEFAULT_PORT: 993
            ROUNDCUBEMAIL_SMTP_SERVER: tls://smtp.example.org
            ROUNDCUBEMAIL_SMTP_PORT: 587
            ROUNDCUBEMAIL_PLUGINS: archive,zipdownload,vcard_attachments,markasjunk,managesieve,enigma,additional_message_headers,acl,show_additional_headers,userinfo,contextmenu,authres_status,show_folder_size,quota,thunderbird_labels,tls_icon
            ROUNDCUBEMAIL_UPLOAD_MAX_FILESIZE: 30M
            ROUNDCUBEMAIL_DB_TYPE: mysql
            ROUNDCUBEMAIL_DB_HOST: db-host
            ROUNDCUBEMAIL_DB_PORT: 3306
            ROUNDCUBEMAIL_DB_USER: ${ROUNDCUBEMAIL_DB_USER}
            ROUNDCUBEMAIL_DB_PASSWORD: ${ROUNDCUBEMAIL_DB_PASSWORD}
            ROUNDCUBEMAIL_DB_NAME: ${ROUNDCUBEMAIL_DB_NAME}
            ROUNDCUBEMAIL_SKIN: elastic
        ports:
            - "80:80"

[GermanCoding]

I don't see a common behavior where roundcube plugins comment out their defaults. You sometimes see commented out config lines where it does not make sense to set an explicit default, but that isn't the case here - it should be a sensible default value (and it also happens to be the same value as if unset). What plugins specifically do you see that have their entire configs commented out?

It's unfortunate that other definitions of the same config key can get ignored, but I don't see any good option to fix this. What I would suggest is to make any modification to the plugin config in the plugin's config file directly and not try to do this anywhere else. The Roundcube plugin installer is what copies config.inc.php.dist to config.inc.php, but it should not touch existing configs. Hence you should be able to reliably modify config.inc.php directly and have that persisted across instance rebuilds. That's what I do for most of my plugins.

This may require persisting plugin folders within docker, which is not great, but it wasn't me who decided to have plugin configs live in the plugin folder.

[williamdes]

What plugins specifically do you see that have their entire configs commented out?

All the plugins of this list (they are not commented but in dist mode):

• archive
• zipdownload (dist mode: https://github.com/roundcube/roundcubemail/blob/master/plugins/zipdownload/config.inc.php.dist)
• vcard_attachments
• markasjunk (dist mode: https://github.com/roundcube/roundcubemail/blob/master/plugins/markasjunk/config.inc.php.dist)
• managesieve (dist mode: https://github.com/roundcube/roundcubemail/blob/master/plugins/managesieve/config.inc.php.dist)
• enigma (dist mode: https://github.com/roundcube/roundcubemail/blob/master/plugins/enigma/config.inc.php.dist)
• additional_message_headers (dist mode: https://github.com/roundcube/roundcubemail/blob/master/plugins/additional_message_headers/config.inc.php.dist)
• acl (dist mode: https://github.com/roundcube/roundcubemail/blob/master/plugins/acl/config.inc.php.dist)
• show_additional_headers
  -~~ userinfo~~
• contextmenu
• authres_status (dist mode: https://github.com/pimlie/authres_status/blob/master/config.inc.php.dist)
• show_folder_size (dist mode: https://github.com/jfcherng-roundcube/plugin-show-folder-size/blob/master/config.inc.php.dist)
• quota (dist mode: https://github.com/jfcherng-roundcube/plugin-quota/blob/master/config.inc.php.dist)
• thunderbird_labels (dist mode: https://github.com/mike-kfed/roundcube-thunderbird_labels/blob/master/config.inc.php.dist)

So I would conclude that there is something did on purpose so that config.inc.php files do not exist

@thomascube @alecpl Could you comment about config loading for plugins ?
On this plugin my config created and mounted by Docker is not taken in account until I comment out the config line at config.inc.php of this plugin or remove the file. As I said in #4 (comment)

[alecpl]

.dist files are samples and usually (I can't talk about the 3rd party plugins) they contain all plugin options and their defaults. User has to copy config.inc.php.dist to config.inc.php because .dist files are not being used. Some plugins will work without config.inc.php file just fine, some might not.

[GermanCoding]

.dist files are samples and usually (I can't talk about the 3rd party plugins) they contain all plugin options and their defaults. User has to copy config.inc.php.dist to config.inc.php because .dist files are not being used. Some plugins will work without config.inc.php file just fine, some might not.

Yes, though nowadays the Roundcube plugin installer copies config.inc.php.dist to config.inc.php automatically: https://github.com/roundcube/plugin-installer/blob/c4335e20b86cfe3a184ccf24d675c6a0338a372a/src/Roundcube/Composer/ExtensionInstaller.php#L64

I think this was added in roundcube/plugin-installer v0.3.0

The question is now, what if the user doesn't actually want that, because the config is managed externally/somewhere else? In this case it appears that the automatically generated config.inc.php takes precedence, which is not desired in this case.

It appears that, for some plugins, config.inc.php is not created automatically. I guess that is because either

• the plugin's composer.json requires an old version of the plugin installer that doesn't have this feature
• for plugins included in the dist, the installer is probably not run in the first place

A suggested workaround seems to be to have everything commented out by default (so that when config.inc.php is created automatically it doesn't contain anything useful), which doesn't sound appealing to me. What's the supposed flow here?

[dilyanpalauzov]

Here come headers inserted by sendmail. I show the two uppermost received headers, only the second one is relative:

Received: from mail.aegee.org ([unix socket])	 by mail.aegee.org (Cyrus 3.4.4) with LMTPA;	 Sun, 18 Dec 2022 07:03:24 +0000
Received: from 69-171-232-143.mail-mail.facebook.com (69-171-232-143.mail-mail.facebook.com [69.171.232.143])	by mail.aegee.org (8.17.1/8.17.1) with ESMTPS id 2BI73F8b1489360	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)	for <my@address>; Sun, 18 Dec 2022 07:03:16 GMT

verify=NO means that the sending server has not volunarily presented a certificate. Another example with verify=OK

Received: from mail.aegee.org ([unix socket])	 by mail.aegee.org (Cyrus 3.4.4) with LMTPA;	 Fri, 16 Dec 2022 22:41:09 +0000
Received: from smtp.github.com (out-18.smtp.github.com [192.30.252.201])	by mail.aegee.org (8.17.1/8.17.1) with ESMTPS id 2BGMf4uY685293	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)	for <my@address>; Fri, 16 Dec 2022 22:41:05 GMT

Please add parsing for sendmail-generated Received: headers and possibly add an option whether only postfix or only sendmail generated headers shall be handled (if this option would make things faster).