Why are my OpenLDAP users marked "(inactive)" ?

[kc8asv]

We're running Jira Core 8.4.1 and the user directory is an OpenLDAP server. Users are managed within Jira only to the extent of applying group memberships (created in Jira). This setup has been working well for years but lately we've noticed users are being marked as (inactive) within Jira. I don't see anything in their LDAP attributes which would indicate Jira should expire their account (eg: shadowInactive, shadowExpire). I've found several postings on the Atlassian forum with others having similar issues but these posts are quite old. Some around five years ago. When I do a full sync of the LDAP directory, I don't see any errors in the logs but Jira IS deleting 42 users. Where is Jira deciding these users need to be deleted?

2021-03-30 06:04:11,562 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteDirectory] INCREMENTAL synchronisation for directory [ 10000 ] starting
2021-03-30 06:04:11,562 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteDirectory] Attempting INCREMENTAL synchronisation for directory [ 10000 ]
2021-03-30 06:04:11,562 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteDirectory] Incremental synchronisation for directory [ 10000 ] was not completed, falling back to a full synchronisation
2021-03-30 06:04:11,562 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteDirectory] INCREMENTAL synchronisation for directory [ 10000 ] was not successful, attempting FULL
2021-03-30 06:04:11,634 Caesium-1-2 INFO ServiceRunner [c.a.c.d.ldap.cache.RemoteDirectoryCacheRefresher] found [ 342 ] remote users in [ 72 ms ]
2021-03-30 06:04:11,639 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanned and compared [ 342 ] users for delete in DB cache in [ 5ms ]
2021-03-30 06:04:11,639 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] deleting [ 42 ] users
2021-03-30 06:04:11,724 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] deleted [ 42 ] users in [ 85ms ]
2021-03-30 06:04:11,724 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanned for deleted users in [ 90ms ]
2021-03-30 06:04:11,727 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanning [ 342 ] users to add or update
2021-03-30 06:04:11,728 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DirectoryCacheImplUsingChangeOperations] scanned and compared [ 342 ] users for update in DB cache in [ 4ms ]
2021-03-30 06:04:11,728 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DirectoryCacheImplUsingChangeOperations] synchronised [ 342 ] users in [ 4ms ]
2021-03-30 06:04:11,781 Caesium-1-2 INFO ServiceRunner [c.a.c.d.ldap.cache.RemoteDirectoryCacheRefresher] found [ 10 ] remote groups in [ 53 ms ]
2021-03-30 06:04:11,783 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanned and compared [ 10 ] groups for delete in DB cache in [ 2ms ]
2021-03-30 06:04:11,783 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DirectoryCacheImplUsingChangeOperations] scanning [ 10 ] groups to add or update
2021-03-30 06:04:11,784 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanned and compared [ 10 ] groups for update in DB cache in [ 1ms ]
2021-03-30 06:04:11,784 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DirectoryCacheImplUsingChangeOperations] synchronized [ 10 ] groups in [ 1ms ]
2021-03-30 06:04:11,786 Caesium-1-2 INFO ServiceRunner [c.a.c.d.ldap.cache.AbstractCacheRefresher] finished group attribute sync with 0 failures in [ 2ms ]
2021-03-30 06:04:12,420 Caesium-1-2 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteDirectory] FULL synchronisation complete for directory [ 10000 ] in [ 858ms ]

There is some suggestion in older posts that a Postgres edit is needed. Is that the official fix?  I don't see any other way inside Jira itself to change the users' status.

Thanks

[kc8asv]

Nevermind. This is due to an (mail=*@.domain.com) user filter and some of these user's email addresses have changed in the past couple months. Total PEBKAC here.