Hello,

Hmm, looking at it we return a list of blocked senders and signatures as well as a couple settings. I could maybe see a very large signature causing an issue? Could you check this user's blocked sender count, it would have to be astronomical to be 11mb though. Another thing to check is their signatures, and more specifically if they've some how managed to embed an inline image or something like that INTO their signature.  I could see that causing an issue as well.

If you don't see anything odd, you can try checking that user on your system and seeing if they have any large JSON files in their directory, C:\SmarterMail\Domains\<domain>\Users\<user>

Let me know if you see anything.

Hi Matt,

Thank you for the suggestion. They do have a signature but it references an externally hosted image so it is not embedded. However, they do have a 498Kb settings.json file, scrolling through it mainly consists of 'trusted sender' entries. Perhaps hundreds of them.  This would still seem strange to equate to an 11.2MB 'user-startup-data' stream?

Thanks,

Hi Matt,

I have noticed in the 'Signatures' section for this user that under 'Mapped Field' they have the same three addresses repeated 10's maybe 100's of times. e.g. I see

...

The same block of addresses is repeated many, many times. Surely there should just be 3 on the basis the domain has two aliases?

Examing settings.json for the user I see in excess of 1,300 blocks like this:

    {
      "id": 1329,
      "signature_guid": "",
      "signature_key": "dev.domain.com",
      "map_option": 1,
      "type": 1,
      "allow_users_to_override": true
    },

However, some have a blank signature_guid whilst some have a populated value.

I am guessing this needs tidying up, do you have any thoughts?

Yea I would go ahead and remove those, just curious what version of SM are you on? Curious on how a bunch of those got created and if it's something you've noticed recently.

When you remove those just stop the service, remove all those entries, then start it back up. Can log into the user and check the size of that call to see if it was the cause.

Build 7008, upgraded from v15 to v17 around 6 weeks ago. Only just received reports but possibly in place since the upgrade.

Would a 'reload domain' be sufficient after modifying the settings.json file or does it need a full service stop / start ?

Based on a quick inspection that should work. I can't say for sure though. What you can do is remove those bad blocks then also change something else obvious like add a '!' to their display name. That way if you do Reload Domain and you notice the "!" then you can know for sure the user's settings got reloaded. Then just remove '!' in the interface after you confirm that it worked.

EDIT: look for display_name

With 17 settings are cached in memory then delay written to disk. So there is a chance it was referencing the old-cached version. Reload should probably nuke that cache but it may currently not. Glad to hear that fixed your issue.