Same issue here.

I think it worked correctly in SmarterMail 14, but apparently fails since we upgraded to SmarterMail Build 7125. That was a couple of months ago, but I wasn't aware of the problem until this week.

Just to clarify Jade's post, the Domain actually has Automated Forwarding enabled:

... and the email account has Automated Forwarding disabled:

Even though forwarding is disabled, I can see that the forwarding address (and "delete when forwarded" setting) were saved in SmarterMail. These settings are revealed when I go into SmarterMail and "Enable Automated Forwarding" for the user:

If I use SolidCP to make any change to the email account, it reverts back to disabling Automated Forwarding for that email account.

I have logged a ticket with Smartertools about this issue so hopefully we get some kind of resolution, be it from Smartertools or SolidCP.

I suspect that this is what is happening.

Smartermail has a new api function called enableMailForwarding and SolidCP is not setting this value.

https://mail.smartertools.com/Documentation/api#/reference/SmarterMail.Web.Controllers.Api.DomainSettingsController/AddUser

Based on the above assumption, smartermail is not enabling forwarding if the user defaults are set to true for this option.

For now, we'll have to manually enable forwarding for each user that logs a support request or use the propagate function on a daily bases to enforce this setting

@Dolphyn5 - this worked correctly up until a few versions back on the latest Smartermail.

please add my vote to get this fixed.  i think smarterTools has forgotten about being able to be backwards compatible.

They mentioned this api cal to enable below. But I checked the api call Jade pointed out and saw that is also have the "enableMailForwarding" option.

https://mail.smartertools.com/Documentation/api#/reference/SmarterMail.Web.Controllers.Api.DomainSettingsController/SetUsersMailSettings
POST api/v1/settings/domain/user-mail/{email}
"enableMailForwarding": boolean,

We are looking into this.

Update: We have now confirmed the issue and logged a bug at https://github.com/FuseCP/SolidCP/issues/19. You can track any updates here but no ETA has been set.