Outlook rules don't work

ozy · 2026-06-30T06:25:07+00:00

Running gromox 3.7.345.xd02abaf, I noticed that Outlook rules don't work anymore. Created a simple rule "from user X move to folder Y and stop evaluating oth...

Duese6

Upgraded to gromox 3.8.109 this morning. Since then, no inbox rules are working on any of my servers.

A rollback to 3.8.103 fixes the issue immediately. The rest of the system is fully up to date.

Mister2

Can confitrm same issue here since applying this mornings updates.

grommunio-web - 3.18.146.g81fa9c8f8-lp160.528.1 gromox - 3.8.109.m4da521a-lp160.44.1 gromox-debuginfo - 3.8.109.m4da521a-lp160.44.1 gromox-debugsource - 3.8.109.m4da521a-lp160.44.1 libfreetype6 - 2.14.3-160000.1.1 mapi-header-php - 2.1.35.f3199a1-lp160.14.1

ozy

I'm running with lda_twostep_ruleproc=1, can you guys confirm that this also happens without the new rule processor ?

Duese6

ozy or @WalterH
Could you please tell me in which configuration file this needs to be set? I couldn't find a reference to lda_twostep_ruleproc

WalterH

I use lda_twostep_ruleproc=1, all rules works as expected with 3.8.109.

Duese6

Okay, found it in the comment above:

/etc/gromox/exmdb_local.cfg

Is that the correct place for this setting?

Myexmdb_local.cfg currently only contains x500_org_name, so I just want to make sure I'm not editing the wrong configuration file.

mwilliams

yes, lda_twostep_ruleproc=1 in /etc/gromox/exmdb_local.cfg

Duese6

Adding lda_twostep_ruleproc=1 and lda_mrautoproc=yes fixes the issue on all of my servers.

However, this was quite unexpected from an administrator's perspective. After the update, inbox rules simply stopped working, while both Outlook and grommunio Web continued to show them as enabled and correctly configured.

Since nothing indicated that the rule processor configuration had become relevant, troubleshooting this took quite some time. On an existing installation, one wouldn't normally expect inbox rules to stop working after a routine update due to a missing configuration option.

mwilliams

Duese6

yeah, sorry for the noise, we are discussing internally to make lda_twostep_ruleproc the new default with the next release. stay tuned.

ozy

@mwilliams Initial issue isn't fixed yet, regardless of ruleprocessor configured.
Willing to do all testing required.

mwilliams

ozy

I don't understand, for what reason do you want to keep the non-twostep?

ozy

@mwilliams I was using non-twostep rule processor earlier, but switched to two step rule processor as described in the 3rd post. Two step rule processor also doesn't work for me, intra-domain mail move rules not being executed.

Current system config:

mail:~ # grep lda /etc/gromox/exmdb_local.cfg
lda_twostep_ruleproc=1
lda_mrautoproc=yes
mail:~ # rpm -qa | grep gromox
system-user-gromox-9-lp160.6.1.noarch
gromox-3.8.137.m650fd5b-lp160.58.1.x86_64
gromox-debugsource-3.8.137.m650fd5b-lp160.58.1.x86_64
gromox-debuginfo-3.8.137.m650fd5b-lp160.58.1.x86_64

ozy

For the sake of testing, I've updated to gromox-3.8.150.m2329331 that came out this morning.

Test setup:
Created a rule in outlook for user A@mydomain.tld that moves mail from B@mydomain.tld to draft folder.
Created a rule in grommunio-web for user B@mydomain.tld that moves mail from A@mydomain.tld to draft folder.
Both rules don't work.
Creating a rule for user A@mydomain.tld tyhat moves mail from C@otherdomain.tld to draft works though.

Am I the only one experiencing this ?
I mean I just outruled outlook since the same problem happens when using Grommunio-Web. Any chance there's some mixup in addressing between EX and STMP prefixes ? That would explain why only internal mails aren't moved around.

ozy

In order to try to debug, I set the following:

In /etc/gromox/exmdb_local.cfg:

lda_twostep_ruleproc=1
lda_mrautoproc=yes
ruleproc_debug=1

In /etc/gromox/delivery.cfg:

lda_log_level=6

In /etc/gromox/http.cfg:

http_log_level=6
http_debug=1

After restarting all services, I tried to check logs, ie journalctl -S "2026-07-28 19:15:00" | grep -i rule but only got one line which doesn't really look like it has anything to do with the two step rule processor:

juil. 28 19:23:43 mail.netperfect.fr gromox-http[1895]: mod_rewrite: defaulting to built-in rule list

Can anyone point me to the right log settings and path to diag the two step ruleprocessor ?

Thanks.

WalterH

Update to gromox-3.9.17 and test again. Second test: create the rule with g-Web and test?

ozy

@WalterH both done without success.

Do you know by any chance where I am supposed to find the ruleproc debug logs ?

ozy

Okay, so I finally got the ruleproc debug logs.
My bad, I enabled ruleproc_debug=1 in /etc/gromox/exmdb_local.cfg instead of /etc/gromox/gromox.cfg.
Really a keyboard-chair interface problem ^^

I created a fresh "TEST-RULE" in grommunio-web, which moves messages from surname.familyname@mydomain.tld to folder "TEST" in account othersurname.otherfamilyname@mydomain.tld

Now when sending a message from surname.familyname@mydomain.tld to othersurname.otherfamilyname@mydomain.tld , the rule doesn't get executed and I get the following log (username and domain properly redacted to reflect the above rule while keeping case and exact syntax):

juil. 30 09:51:34 mail.mydomain.tld gromox-delivery[1355]: Rule_Condition RES_COMMENT{props[4]={PT_LONG{1/0x1},PT_BINARY{[116]="EX:/O=I6509FB5C/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=0100000001000000-SURNAME.FAMILYNAME^@"},PT_UNICODE{[46]="Surname Familyname <surname.familyname@mydomain.tld>"},PT_LONG{0/0x0},},res={RES_PROP{val(c1d0102h) == PT_BINARY{[116]="EX:/O=I6509FB5C/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=0100000001000000-SURNAME.FAMILYNAME^@"}}}}

Perhaps I will post this on github, I have no clue what to do with that debug log, except noticing that the comparaison lacks PT_UNICODE property on one side ^^

WalterH

Today grommunio released a huge update. Try the update first.

ozy

Unfortunately I am already running gromox-3.9.17 and still got this issue.
I think I cannot get more debug info than that.