Hello,   Telnet server is no longer offered in newer AsyncOS releases due to security restrictions.   Thanks! -Dennis M. ... View more

Perhaps you're confusing TLS with other forms of encryption? TLS does not encrypt the payload itself, but instead the connection/session when sending between MTAs.   As mentioned, all you need to do for TLS encryption between hops is to enable TLS on your Exchange server. Assuming, of course, you've already enabled it on the ESA (which you said you did?).    Thanks! -Dennis M. ... View more

Hello,   Assuming you simply want TLS encryption between gateways, all you would need to do is implement TLS on the other end (if already configured on the ESA). For example, if using Exchange, you would enable TLS on the Send/Receive connectors.    On the ESA, you can review the mail logs and/or message tracking to confirm if TLS is being used when receiving mail (ICID) or when delivering mail (DCID).   Thanks! -Dennis M. ... View more

Hello,   It's only going to prepend [SUSPICIOUS] if the email is flagged as Suspect Spam. Was this the case?   Thanks! -Dennis M. ... View more

What does the output show on the ESA itself? Can you share a screenshot?   Thanks! -Dennis M. ... View more

Hello,   One thing to note would be that CheckTLS automatically rearranges (or corrects if not already) your certificate chain. So, that is one thing you'll want to confirm. You can check this by selecting the certificate on the ESA and then confirming the chain is in the correct order.   Correct chain example:   Server Certificate: esa1.abc.com issued by ca-int.xyz.com Intermediate Certificate: ca-int.xyz.com issued by ca-root.xyz.com   Incorrect chain example:   Server Certificate: esa1.abc.com issued by ca-int.xyz.com Intermediate Certificate: ca-root.xyz.com issued by ca-root.xyz.com   If the chain is correct then it is most likely one of two things, either the ESA does not trust the Mimecast CA or Mimecast does not trust the ESA CA.    Thanks! -Dennis M.     ... View more

Hello,   The Microsoft article is pretty clear about the cause of the registry entry being in that location. If you're able to open a Cisco TAC case then we can help take a look at the machine in question and confirm. If not, then uninstalling and reinstalling maybe your best option.   Thanks! -Dennis M. ... View more

Hello,   The article you referenced brings up a point where you may be running Office 32-bit on a 64-bit OS in order for that particular registry key to be updated.    If you have a 32-bit version of Office installed on a 64-bit version of Windows, add-ins that are registered under HKEY_LOCAL_MACHINE will be registered under the \ Wow6432Node   subkey.   Could you perhaps be running into that issue? Coincidentally, the only time I've seen this particular issue is when multiple versions of Office are installed (ie: 32-bit and 64-bit) and the installer essentially doesn't know where/how to update the registry keys.    Thanks! -Dennis M. ... View more

Hello,   If only outbound then you should only need to modify the send connector on the Exchange side to route through the new vESA. The vESA would not need to process/re-process any incoming email that is encrypted and can go directly back to Exchange.    Thanks! -Dennis M. ... View more

Hello,   It's quite simple but can probably be daunting if it's your first time setting it up.    The general requirements are: Interface -> Routing -> DNS -> Listener (Private) -> Recipient Access Table (RAT) -> Host Access Table (HAT) -> SMTP Routes. The private listener is what you will want to use for outgoing. If you plan to use the same IF/listener in the future for both incoming AND outgoing traffic, then you'll want to set it as public. The primary distinction between incoming vs. outgoing (excluding the listener) is the connection behavior that's set on the mail flow policy. When it's set to accept it's considered incoming and when set to relay considered outgoing.    Thanks! -Dennis M. ... View more