There are several user records that look to have been created by the "guest" account.
This occurs in all releases.
User records are being automatically created from emails when property "glide.email.create_userid_from_email" is set to true or "glide.pop3readerjob.create_caller" is set to true. If the system does not recognize the incoming email, or they are not from an approved domain, the inbound actions are processed under the guest account.
Additionally, if an instance has SAML enabled or LDAP imports, there is a mechanism by which user accounts can be auto-provisioned, which is also completed through the guest account. If these properties are set to true, users will be auto-provisioned in the system, "glide.ldap.user.autoprovision" and "glide.authenticate.multisso.user.autoprovision".
If the property "glide.pop3readerjob.create_caller" is set to true, user accounts are automatically created from emails. Admins can specify the approved domains user accounts should be created from with property "glide.user.trusted_domain". There is a note about these two properties in our product documentation:
"NOTE: The glide.user.trusted_domain property only prevents user creation if the sender is not from a trusted domain. The system processes the inbound actions of the email as a guest user. If you want the system to ignore these email messages, use the email filters plugin, specifically the "ignore sender" setting. You can also prevent untrusted users from triggering inbound actions by locking out the guest user. "
When the property "glide.pop3readerjob.create_caller" is set to false, the instance runs inbound actions from users who do not match an existing user by impersonating the guest user.
The "glide.email.create_userid_from_email" property was introduced into the system with the Email Automatic User Creation plugin. The property is described as follows:
For situations where the "guest" account has updated user records, please see -- KB0683874