HCHTech
Well-Known Member
- Reaction score
- 4,157
- Location
- Pittsburgh, PA - USA
I have a client with about 30 employees. They are on hosted Exchange with a Microsoft tenant. The workstations are running a mix of Office 2013 and 2016. Today, one employee (running Office 2013) started getting bounce messages when she sent email to anyone, either internally or externally, as follows:
==========
Your message did not reach some or all of the intended recipients.
Subject: RE: Testing
Sent: 8/2/2017 8:22 PM
The following recipient(s) cannot be reached:
'Redacted' on 8/2/2017 8:22 PM
This message could not be sent. Try sending the message again later, or contact your network administrator. The client operation failed. Error is [0x80004005-0x80004005-0x000501].
==========
They also heard from a couple of clients that had received junk emails from this employee. Typical phishing subject line, "Remittance-Invoice for PO#23477" with a bogus Docusign link to see the invoice.
So...someone hacked her email account or something. We immediately changed her email password, and ran full malware and antivirus scans on her workstation (both came back clean). I have been through her account on the Office365 Admin and Exchange Admin screens, and nothing looks out of place, yet she still cannot send email.
Note everyone else at the company is sending and receiving email just fine.
Googling this error has not borne fruit. Old posts dealing with Exchange 2003 suggest to delete the OST file and let it recreate. Didn't help in my case.
I checked the client's domain for blacklisting - it's clean.
Then, I logged onto Office365 as the affected user and tried to send an email there. It failed as well, with this more-helpful message:
"Error: Your message can't be sent because you've reached your daily limit for message recipients"
Ok. So there you go - her account got hacked, it sent out 200 emails or whatever our limit is, and she's been cut off for the day. My first reaction, is why there isn't a big, red, flashing message when I log into the Exchange Admin that one of the users tripped this limit? Or...why doesn't the bounce message alert you to the real problem?
The next question is, I wonder what the limit is? I go through the admin screens again looking for where the limit is set and don't find it. Then, I search and find this page - Uh Oh. It looks like the built-in limit for recipients per day is....wait for it.....10,000 per day. Ouch - I hope the spammer didn't send 10K emails, but it looks like they did. There is a separate message rate limit of 30 per minute, but the error message clearly says they exceeded the daily limit for message recipients. Crap.
Ok, so now I go looking for a way to lower this limit...to no avail. I KNOW you can set these limits with on-premise Exchange. It doesn't look like you can change them with hosted Exchange. Awesome.
I think I'm going to take another run at getting this client to agree to having passwords expire more often than NEVER. We're using the standard complexity requirements, and when we first went to hosted exchange in 2014 we were using a 6-month expiration, but the first time one of the partner's passwords expired while they were travelling they requested changing the rule to never expire. I caved.
Please learn from my failure the next time one of your clients asks you to eliminate password expiration or complexity requirements.
==========
Your message did not reach some or all of the intended recipients.
Subject: RE: Testing
Sent: 8/2/2017 8:22 PM
The following recipient(s) cannot be reached:
'Redacted' on 8/2/2017 8:22 PM
This message could not be sent. Try sending the message again later, or contact your network administrator. The client operation failed. Error is [0x80004005-0x80004005-0x000501].
==========
They also heard from a couple of clients that had received junk emails from this employee. Typical phishing subject line, "Remittance-Invoice for PO#23477" with a bogus Docusign link to see the invoice.
So...someone hacked her email account or something. We immediately changed her email password, and ran full malware and antivirus scans on her workstation (both came back clean). I have been through her account on the Office365 Admin and Exchange Admin screens, and nothing looks out of place, yet she still cannot send email.
Note everyone else at the company is sending and receiving email just fine.
Googling this error has not borne fruit. Old posts dealing with Exchange 2003 suggest to delete the OST file and let it recreate. Didn't help in my case.
I checked the client's domain for blacklisting - it's clean.
Then, I logged onto Office365 as the affected user and tried to send an email there. It failed as well, with this more-helpful message:
"Error: Your message can't be sent because you've reached your daily limit for message recipients"
Ok. So there you go - her account got hacked, it sent out 200 emails or whatever our limit is, and she's been cut off for the day. My first reaction, is why there isn't a big, red, flashing message when I log into the Exchange Admin that one of the users tripped this limit? Or...why doesn't the bounce message alert you to the real problem?
The next question is, I wonder what the limit is? I go through the admin screens again looking for where the limit is set and don't find it. Then, I search and find this page - Uh Oh. It looks like the built-in limit for recipients per day is....wait for it.....10,000 per day. Ouch - I hope the spammer didn't send 10K emails, but it looks like they did. There is a separate message rate limit of 30 per minute, but the error message clearly says they exceeded the daily limit for message recipients. Crap.
Ok, so now I go looking for a way to lower this limit...to no avail. I KNOW you can set these limits with on-premise Exchange. It doesn't look like you can change them with hosted Exchange. Awesome.
I think I'm going to take another run at getting this client to agree to having passwords expire more often than NEVER. We're using the standard complexity requirements, and when we first went to hosted exchange in 2014 we were using a 6-month expiration, but the first time one of the partner's passwords expired while they were travelling they requested changing the rule to never expire. I caved.
Please learn from my failure the next time one of your clients asks you to eliminate password expiration or complexity requirements.