I noticed the same issue on a customer ESA and wanted to share my findings.    You will likely see a high Active Recipient count when looking at the ESA GUI > Monitor > Delivery Status or via cli typing >tophosts then Active Recipients.   First locate the Tracking information. Example:    (Machine myesa)> grep "661943" mail_logs ... Thu Oct 18 22:31:42 2018 Info: MID 589979 Message-ID '<685.507661943.201810181731408948659.0007476837@email.amf.com>' Sun Oct 21 17:10:16 2018 Info: Start MID 661943 ICID 1000903 Sun Oct 21 17:10:17 2018 Info: MID 661943 Message-ID '<207965819.2724.1540123818426.JavaMail.SVCE0BI@E1SCG5AP01>' Sun Oct 21 17:10:17 2018 Info: MID 661943 Subject '**Employee Changes Report **' Sun Oct 21 17:10:17 2018 Info: MID 661943 ready 8247 bytes from ... Sun Oct 21 17:10:17 2018 Info: MID 661943 Custom Log Entry: Matched UltiPro_Reports filter Sun Oct 21 17:10:17 2018 Info: MID 661943 matched all recipients for per-recipient policy DEFAULT in the inbound table Sun Oct 21 17:10:17 2018 Info: MID 661943 interim AV verdict using Sophos CLEAN Sun Oct 21 17:10:17 2018 Info: MID 661943 AMP file reputation verdict : UNKNOWN Sun Oct 21 17:10:17 2018 Info: MID 661943 Custom Log Entry: Header has been stripped due to requested read receipt Sun Oct 21 17:10:17 2018 Info: MID 661943 attachment 'Employee=20Changes=20Report=20-=20Scheduled.xlsx' Sun Oct 21 17:10:17 2018 Info: MID 661944 was generated based on MID 661943 by duplicate-quarantine filter 'ultipro_troubleshooting' Sun Oct 21 17:10:17 2018 Info: MID 661943 Outbreak Filters: verdict negative Sun Oct 21 17:10:17 2018 Info: MID 661943 queued for delivery Wed Oct 24 17:42:25 2018 Info: Bounced: DCID 153567 MID 661943 to RID 0 - Bounced by destination server with response: 5.4.7 - Delivery expired (message too old) ('000', ['timeout']) Wed Oct 24 17:42:25 2018 Info: MID 768246 was generated for bounce of MID 661943 Wed Oct 24 17:42:25 2018 Info: Message finished MID 661943 done   Locate the DCID portion and take note of the number.  Via CLI again grep for that DCID    (Machine myesa)> grep "DCID 153567" mail_logs Wed Oct 24 17:42:25 2018 Info: Connection Error: DCID 153567 domain: [10.130.187.243] IP: 10.130.187.243 port: 25 details: timeout interface: 216.71.148.107 reason: connection timed out Wed Oct 24 17:42:25 2018 Info: Bounced: DCID 153567 MID 661943 to RID 0 - Bounced by destination server with response: 5.4.7 - Delivery expired (message too old) ('000', ['timeout'])     This led me to locate the IP address in a message filter from the DCID in the configuration file.    UltiPro_Reports: if (sendergroup == "UltiPro_Exception") { alt-mailhost ("[10.130.187.243]"); log-entry("Matched UltiPro_Reports filter"); skip-filters(); }   Also performing a CLI telnet test confirmed the connectivity issue to this IP.    (Machine myesa)> telnet 10.130.187.243 25 Trying 10.130.187.243... [connection does not open indicating routing issue]       Deactivating this filter fixed the issue! I know 7 years later...Hope it helps others! ... View more

Miguel : Correct. Assuming you've moved the data from one Microsoft SQL instance to the other your next steps are: 1. Stop Postx $sudo service postx status $sudo service postx stop $sudo service postx status << did it stop? if not, try: $sudo service postx stop force 2. Create a backup of your pxeconf.xml file: cp /usr/local/postx/server/conf/pxeconf.xml /usr/local/postx/server/conf/pxeconf-bak.xml 3. Modify the pxeconf.xml with your new hostname, database name and password 4. Start Postx and verify it started $sudo service postx start $sudo service postx status << did it start? Also try to access the GUI of the IEA. If the web page loads you have succeeded. 5. If any issues revert to your old database Repeat Steps 1-4 and replace the following with step 2: cp /usr/local/postx/server/conf/pxeconf-bak.xml /usr/local/postx/server/conf/pxeconf.xml   ... View more

Is SBRS score checking enabled on the mail flow policy that is linked to sender group WHITELIST? Do you have any message filters with an action of drop? CLI> filters command... ... View more

TLS will work with the self-signed certificate that comes pre-installed on your ESA. You may also import a new certificate and configure TLS to use the specific certificate. Documentation below will describe how to enforce TLS as "Preferred" or "Required" using the Destination Controls feature (GUI>Mail Policies>Destination Controls). You can configure the TLS (Transport Layer Security) on a per-domain basis. If the “Required” setting is specified, a TLS connection will be negotiated from the appliance listener to MTA(s) for the domain. If the negotiation fails, no email will be sent through the connection. Example:  Changing the Destination Controls "Default"  TLS setting to TLS "Preferred" means that the ESA will attempt delivery and if TLS fails the message will attempt to be sent in "plain text"  Once you make the change, don't forget to submit and commit changes.   What if TLS Fails? You can specify whether the appliance sends an alert if the TLS negotiation fails when delivering messages to a domain that requires a TLS connection. The alert message contains name of the destination domain for the failed TLS negotiation. The appliance sends the alert message to all recipients set to receive Warning severity level alerts for System alert types. You can manage alert recipients via the System Administration > Alerts page in the GUI (or via the alertconfig command in the CLI). To enable TLS connection alerts, click Edit Global Settings on the Destination Controls page or destconfig -> setup subcommand. This is a global setting, not a per-domain setting. For information on the messages that the appliance attempted to deliver, use the Monitor > Message Tracking page or the mail logs. You must specify a certificate to use for all outgoing TLS connections. Use the Edit Global Settings on the Destination Controls page or destconfig -> setup subcommand to specify the certificate ... View more

Hi, This could not be working based on many factors. The default settings may require manual tweaking. Please look at the "distinguished name" of the LDAP group objects. you may have to get the distinguished names of one of the groups and modify the original query to include the distinguished name like in the example below. Query: (&(memberof=CN={g},OU=Distribution Groups,OU=ExchangeObjects,OU=Corp,DC=swc,DC=local)(proxyAddresses=smtp:{a}))   Also I think your best bet would be to call Cisco Tac and open a case for support. I hope this helps! http://www.cisco.com/support US Toll Free Customer Support +1 800 553 2447 Option #1   ... View more

Probably related to the version you are on Version: 5.1.0-317 ....Have you considered upgrading? Also the virtual ESA is a nice option ... View more

Hi Jason, Thanks for sharing. The error message looks like there is a cipher mismatch. What you can do: 1. >sslconfig >verify paste in the cipher string from inbound and outbound above MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:!DHE-RSA-AES256-SHA256:!DHE-RSA-AES128-SHA256 this shows the list of ciphers available. Then compare to yours. What's different, what's missing? If you could open a support case we can also provide a more thorough investigation. Hope that helps. Stephan ... View more

Jason, I have seen this fix the issue: Symptoms External Authentication (GUI admin access) worked before upgrading to 8.0 Solution: Navigate to: GUI>System Administration>LDAP Open your LDAP profile Under LDAP Server Settings > Server type, explicitly define your server type i.e. "Active Directory" or "OpenLDAP" Submit Commit Changes hope this helps! ... View more