One of my users is suffering from a lot of "Administrative Lockouts" to
another internal user.
---------- Forwarded message ----------
Date: 31 May 2011 13:44
Subject: Fw: failure notice
To: YYYYYYYY , zzzzzzzzz
Administrative Lockout - Inbound not allowed
I have checked the "Rejection viewer" and find the following.
It appears, from the knowledge base that I need to add a rejection rule bypass. But I do not understand why this is happening. It was fine last week and the week before that.....
Any in sites greatly appreciated
Help get this topic noticed by sharing it on Twitter, Facebook, or email.
The default 'Inbound Lockout' policies that Mimecast configures upon account creation are designed to prevent spoofed messages from being received by your users. A lot of people (un)intentionally permit their own address or domain. Spammers realise this and often try to masquerade/spoof their items as if they have been sent by yourself or a colleague.
The Inbound Lockout policies work based on originating IP and the domain the item is coming from.Could it be that there have been changes to your IP addresses which have not been updated on your Inbound Lockout policies?
If not we would need additional information you might want to provide in a support request?
I thought that the IP address had changed, but that does not appear to be the case.
I made some changes adding the "new" address, but it appears that this "new" address is just the gateway address used by the router.
I have logged a case, but have had no response.
Where do I go from here?
I have updated your support ticket.
These messages are not being presented to your Mimecast account by one of your IP addresses but are instead coming from several MessageLabs servers. I am not sure why this user started to communicate with his colleagues via this route but I have provided you with 3 options which will resolve the issue:
1. Configure the sending servers to offer authentication details specific to this user when submitting these messages.
2. Change the outbound and/or internal mail flow for this user so that he will be using the local mail server instead of MessageLabs servers.
3. Create an additional Inbound Lockout policy specific for items from this user's address to Internal and set it to 'Take no action'. Since this rule will be more specific it will get applied instead of the one that is currently rejecting this communication.
I hope this helps.