I’m an ISP providing email services to my clients. One of my clients has had trouble sending to a particular domain, but her email address is being block by Symantec globally because of poor reputation. how can we be re-evaluated?
We installed SEPM 14 MP2 but never got Auto email notification working. After working with Symantec support, it was very frustrating and requested to close the case as it was going no where. Recently I had some time to work on it. Key environment:
1) Email Server: Office 356 and all emails are scanned by Message Lab Email Security.Cloud
2) Web Security.Cloud
Error messages “Symantec Endpoint Protection Manager cannot send a test email using the settings you specified. Verify your email server settings. For more information, see the knowledgebase article: How to configure email server settings“
I was not sure what address to define in Admin >> Server >> Edit Server Properties >> Email Server >> Server address. Symantec supported tried with different O365 addresses like: outlook.office365.com, smtp.office365.com etc. and none worked. TECH240170 was not so helpful and scm-ui*.err log was showing error like this:
26/09/2017 2:09:58 PM STDOUT: Sending test email …
26/09/2017 2:10:27 PM Email INFO: Start to send email to [email@example.com] using server: cluster4.us.messagelabs.com.
26/09/2017 2:10:27 PM STDOUT: Start to send email to [firstname.lastname@example.org] using server: cluster4.us.messagelabs.com.
26/09/2017 2:10:27 PM Email INFO: Sending email…
26/09/2017 2:10:28 PM Email SEVERE: Valid unsent addresses: [email@example.com]
26/09/2017 2:10:28 PM Email SEVERE: Fail to send email to firstname.lastname@example.org using server: cluster4.us.messagelabs.com.
email@example.com was indeed a valid address.
What I figured out: in Admin >> Server >> Edit Server Properties >> Email Server >> Server address – maker sure it matches with the address of O365 Admin Console >> Setup >> Domains >> Required DNS settings >> MX
Now this should obviously match in Message Lab under Services >> Email Services >> Inbound Routes.
Further running a packet capture on SEPM, I found this very interesting:
220 ME1AUS01FT008.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Tue, 26 Sep 2017 04:35:30 +0000
250-ME1AUS01FT008.mail.protection.outlook.com Hello [X.Y.255.70]
250 2.1.0 Sender OK
550 5.7.606 Access denied, banned sending IP [X.Y.255.70]. To request removal from this list please visit https://sender.office.com/ and follow the directions. For more information please go to http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609) [ME1AUS01FT008.eop-AUS01.prod.protection.outlook.com]
250 2.0.0 Resetting
221 2.0.0 Service closing transmission channel
Now the address X.Y.266.70 is our registered IP assigned for our domain in Message Lab under Services > Web Security Services > Web Routes. Further going to the link https://sender.office.com/, I came across our IP was blocked. It gives the option to delist the IP and issue was resolved.
**AFUM0024E:** An error occurred: The store DN and the mailbox DN could not be derived for user ID ‘firstname.lastname@example.org’
The mailbox is hosted on MS Exchange server 2010.
Attached are mail connector trace log snippet. .
[One for successful resolution of email address].
[Other for error we are facing.]
|Message:||The logon to Outlook Web Access failed. If the problem continues, contact technical support for your organization and tell them the following: The Active Directory profile for “%1” does not have a primary SMTP address.This may have happened because the user’s account was not created with the Exchange Management Console or Exchange Server’s command-line tools. The following Exchange Management Shell steps provide one way of correcting the most common cause of the problem. Get-User “%2” | Disable-Mailbox. Get-User “%3” | Enable-Mailbox At the prompt, enter the mailbox database name (normally “Mailbox Store”).|
This Error event indicates that the user referenced in the event description could not log on to their mailbox using Microsoft® Office Outlook® Web Access because their mailbox does not have a primary Simple Mail Transfer Protocol (SMTP) address. Each user can have one or more SMTP addresses, but one of these addresses must be the primary address. The primary SMTP address displays in bold in the Exchange Management Console. This event may occur if the user mailbox was not created by using the Exchange Management Console or the Exchange Management Shell.
To resolve this error, follow these steps:
You can perform these procedures by using the Exchange Management Console or the Exchange Management Shell.
For information about how to disable a mailbox, see How to Disable a Mailbox.
For information about how to create a mailbox, see How to Create a Mailbox for a New User.
If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.
ERROR – The mailbox for has exceeded the maximum mailbox size. This mailbox cannot send or receive messages. Incoming messages to this mailbox are returned to sender. The mailbox owner should be notified about the condition of the mailbox as soon as possible.
Most organizations implement mailbox quotas on their Exchange. While this policy is good for managing disk space and enforce users to clean up their mailboxes, this also poses a challenge for individual users when they exceed their quota. In this case the user has exceeded their send and receive quota. Even though it is recommended to monitor mailbox quotas on a regular basis through custom Exchange reporting, many organizations fail to do this because of the effort required and the IT support team works in a reactive way.
In most cases it is the end-user who reports to the IT support staff that they cannot receive or send email messages anymore. The IT support staff may engage in various levels of troubleshooting to finally come into a conclusion that this issue is mail quota related and can then advice the user to clean up some room – or increase the quota for the user.
This troubleshooting process can be removed when bringing Exchange servers under Intelligent Monitoring – mailbox quota events are picked up by monitoring and an alert is generated. This allows the IT support staff to respond to the issue before the end-user even notices the issue. This, in turn, can greatly improve the IT support staff efficiency and improve end-user perception of IT service level.