Nick Howitt wrote:

Are you using the paid app or just the free bit?

I was using the free version but Rodrigo was using the paid version and both had the same problem. The fix I wrote above for the free version should also work for the paid version.

I has the same problem as Rodrigo with a brand new install of Roundcube on ClearOS 7 (7.9.1) which is based on CentOS 7 (7.9) which in turn is based on RHEL 7 (Red Hat Enterprise Linux 7.9).

I was accessing Roundcube using my server's internal IP instead of my domain name as that server wasn't live yet. When I logged into a user using Roundcube in the banner section up the top left it displayed my username and part of an internal IP address and the same thing was showing if I tried to compose an email so it was displaying username1@168.1.44. This was fixed by editing:
/usr/share/roundcubemail/config/config.inc.php
and changing this line:
$config['mail_domain'] = '%t';
to my domain name:
$config['mail_domain'] = 'subdomain.domain.tld';
and while your editing that file you may want to add these 2 lines below it:
// add a received header to outgoing mails containing the creators IP and hostname
$config['http_received_header'] = true;

When I logged back into Roundcube using the same user as above the banner was still displaying username1@168.1.44 but when I logged into a new user using Roundcube the banner now displayed username2@subdomain.domain.tld and the new user's email address when composing an email also displayed username2@subdomain.domain.tld so that was one thing fixed.


The next thing to solve was a little harder, why was the hostname set to an IP address? I got a tip off from an old Roundcube config file:
https://searchcode.com/codesearch/view/88688057/
71 // %n - http hostname ($_SERVER['SERVER_NAME'])

A little googling revealed it to be a PHP variable:
https://www.php.net/manual/en/reserved.variables.server.php
'SERVER_NAME'
The name of the server host under which the current script is executing. If the script is running on a virtual host, this will be the value defined for that virtual host.

Note: Under Apache 2, you must set UseCanonicalName = On and ServerName. Otherwise, this value reflects the hostname supplied by the client, which can be spoofed. It is not safe to rely on this value in security-dependent contexts.


Googling Apache came up with this:
https://httpd.apache.org/docs/2.4/mod/core.html#usecanonicalname
https://httpd.apache.org/docs/2.4/mod/core.html#servername
https://httpd.apache.org/docs/2.4/mod/core.html#serveralias



Next it was time to edit the Apache config file:
/etc/httpd/conf/httpd.conf
On line 95 was
ServerName subdomain.domain.tld
and I added the following line underneath
UseCanonicalName On

For testing purposes I changed:
/usr/share/roundcubemail/config/config.inc.php
and changing this line:
$config['mail_domain'] = 'subdomain.domain.tld';
back to:
$config['mail_domain'] = '%t';

Then I started Apache:
systemctl restart httpd


I then accessed Roundcube using my server's internal IP:
https://192.168.1.44/webmail/
and logged in with a third user and I could now see that the banner was no longer displaying an IP address, it was now:
username3@domain.tld
so that fixed the hostname being set to an IP address so then it was time to put back the Roundcube config back by editing
/usr/share/roundcubemail/config/config.inc.php
and changing this line:
$config['mail_domain'] = '%t';
to my domain name:
$config['mail_domain'] = 'subdomain.domain.tld';

Then I started Apache:
systemctl restart httpd


When logging back into Roundcube I still had 2 bad email addresses:
username1@168.1.44
username3@domain.tld
so it was time to fix the database:
mysql -u root -p
DROP DATABASE roundcubemail;
CREATE DATABASE roundcubemail;
exit

I reran the Roundcube installer to initialise the database
https://192.168.1.44/webmail/installer


Now everything was fixed as all the users had an email address in the form of:
username@subdomain.domain.tld

What is ClearOS release 7.9.1 based/built/sourced on?

What is ClearOS release 7.9.1 based on?

Is it CentOS or RHEL? If it is CentOS which version, 6,7, or 8? If it is RHEL which version 6, 7.0, 7.1, 7.2, 7.3, 7.4, 8, or 9?

Hi Peter, I see that ClearOS 6.7 has been released. Any further updates on this:
https://tracker.clearos.com/view.php?id=3681

?

Any reports from the front lines? Is the development environment still plagued by broken/conflicting/missing dependencies in ClearOS 6.6.0? What about in the upcoming ClearOS 7?

Upgrade cyrus-imapd-2.3.X to cyrus-imapd-2.5.X to restore catch-all functionality for emails

ClearOS 6.5.0 currently uses cyrus-imapd-2.3.16-6.v6.4.i686 and suffers from the lack of a working catch-all functionality for email. I work around the problem by using two machines, one ClearOS 6.5.0 machine as the gateway and one ClearOS 5.2 machine just to host email.

cyrus-imapd-2.5.0 introduced catchall directly into the LMTP. This from the release notes:
https://docs.cyrus.foundation/imap/release-notes/2.5/x/2.5.0.html

Catchall Mailbox for LMTP

Thanks to the work by Carsten Hoeger and Ralf Haferkamp, this new feature enables administrators to configure a target mailbox for mail delivered through LMTP to targetted mailboxes that do not exist.

For example, a mail that LMTP would deliver to user/bovik, which for the sake of argument does not exist in this example, setting lmtp_catchall_mailbox to admin will instead deliver the mail to user/admin.

Note

Mailbox name, not Email Address

Note that lmtp_catchall_mailbox must be a user mailbox name, not an email address.

Can one of the 2.5.x versions of Cyrus IMAP be targetted for ClearOS 6.6.0?


P.S. I tried to use the tracker to file a feature request however the getting started page had this very useful statement "Consolodate development framework here "