Hello,
I am a French self-hosting user, and first of all I want to say that I really like the grommunio project. The idea of having an open-source, Exchange-compatible groupware solution is very valuable, especially from a digital sovereignty perspective.
That said, I encountered a frustrating issue just after a clean installation. For a fresh setup, getting this kind of error immediately when opening the first email is quite discouraging.
Environment
Fresh installation using the grommunio ISO:
grommunio 2025.01.2
Community repository
Core component only
Single-server setup
Domain: domain.tld
Server FQDN: mail.domain.tld
The system was updated after installation, then rebooted.
Installed package versions after update:
grommunio-admin-api-1.18.19.me5b13cd-lp156.13.1.noarch
grommunio-admin-web-5.0.0.28.19b1c07-lp156.169.1.noarch
grommunio-web-3.17.287.g828066784-lp156.466.1.noarch
gromox-3.7.129.me37a10c-lp156.9.1.x86_64
system-user-gromox-9-lp156.6.1.noarch
Also installed:
gromox-debuginfo-3.7.129.me37a10c-lp156.9.1.x86_64
gromox-debugsource-3.7.129.me37a10c-lp156.9.1.x86_64
The issue was reproduced after the update and reboot, so it does not seem to be caused by running outdated packages from the ISO image.
Problem
After creating the domain and the first user, I sent an internal test email from:
user@domain.tld to: user@domain.tld
The email was correctly received in the inbox, but opening the message in grommunio Web produced an unexpected error.
The browser console showed a JavaScript error similar to:
Cannot read properties of null (reading 'sendRecords')
After checking the Network tab, the real backend error was visible in the grommunio.php response:
Undefined constant "PR_RECEIVED_BY_SMTP_ADDRESS"
The error pointed to:
/usr/share/grommunio-web/server/includes/core/class.operations.php:1619
Diagnosis
The constant PR_RECEIVED_BY_SMTP_ADDRESS is used in:
/usr/share/grommunio-web/server/includes/core/class.operations.php
at these lines:
PR_SENT_REPRESENTING_SMTP_ADDRESS, PR_SENDER_SMTP_ADDRESS, PR_RECEIVED_BY_SMTP_ADDRESS,
and later:
$smtpAddr = $smtpprops[PR_RECEIVED_BY_SMTP_ADDRESS] ?? '';
But on my installation, this constant did not seem to be defined anywhere.
I checked with:
grep -R "RECEIVED_BY_SMTP" -n /usr/share/grommunio-web /usr/share/php* /usr/share/gromox 2>/dev/null
Result:
/usr/share/grommunio-web/server/includes/core/class.operations.php:1619: PR_SENT_REPRESENTING_SMTP_ADDRESS, PR_SENDER_SMTP_ADDRESS, PR_RECEIVED_BY_SMTP_ADDRESS,
/usr/share/grommunio-web/server/includes/core/class.operations.php:1678: $smtpAddr = $smtpprops[PR_RECEIVED_BY_SMTP_ADDRESS] ?? '';
So the constant was used but apparently not defined.
Temporary workaround
I backed up the file first:
cp /usr/share/grommunio-web/server/includes/core/class.operations.php /root/class.operations.php.bak
Then I added this temporary definition before the $smtpprops = mapi_getprops(...) call:
if (!defined('PR_RECEIVED_BY_SMTP_ADDRESS')) {
define('PR_RECEIVED_BY_SMTP_ADDRESS', 0x5D07001F);
}
Then I checked the PHP syntax:
php -l /usr/share/grommunio-web/server/includes/core/class.operations.php
Result:
No syntax errors detected
Finally, I restarted the services:
systemctl restart php-fpm nginx
After that, the message opened correctly in grommunio Web.
Expected behavior
A freshly installed grommunio system should allow opening received emails in grommunio Web without requiring a manual PHP patch.
Actual behavior
Opening a received message failed with:
Undefined constant "PR_RECEIVED_BY_SMTP_ADDRESS"
Question
Could you please confirm whether this is a packaging issue, a missing constant in the PHP/MAPI definitions, or a regression in grommunio-web?
The manual workaround works, but it will probably be overwritten by future package updates, so it would be great to have an official fix.
Thank you again for the project. Despite this frustrating first-installation issue, I really appreciate what grommunio is trying to achieve.
I should also mention that I am not an expert and I am not a developer. This workaround is only a proposal based on what I observed, and I am fully open to criticism, correction, or a cleaner and more appropriate solution if there is one.
