1. Do I apply these policies on the incoming mail policies or outgoing? Taking into consideration I have a 2-data port topology where data-1 is configured to face the internet (public) and data-2 is facing the LAN (private)
the decision if a connection is inbound or outbound is made based on the type of listener or mail flow policy. Basically, if a message comes trough a private listener, or a sendergroup with a RELAY mail flow policy, that connection is considered outbound, in all other cases it will be inbound.
About your policies, not sure if they will work as I am unsure how you configured:
“deny from firstname.lastname@example.org to email@example.com ”, could you be more specific on that? Also, why not set those rules up directly on the mail servers instead on the email security appliance? Would make configuration less complex.
Because I want to block firstname.lastname@example.org to send email to email@example.com only, I will have to define specific policies that drops firstname.lastname@example.org to email@example.com, then allow firstname.lastname@example.org to every other email. Something like firewall rules performing specific deny and allow any any at the last line.
I performed some internal testings and I realize that in order to specifically block from email@example.com to firstname.lastname@example.org, I have to define sender = email@example.com in the outgoing mail policy and firstname.lastname@example.org in the outgoing mail filter under filter = envelope recipient; action = drop (or vice versa). Otherwise, if I place sender = email@example.com and recipient = firstname.lastname@example.org in the mail policy, any email from email@example.com OR to firstname.lastname@example.org will hit the policy.
I feel that this is kind of brainless to do such thing and will add operational complexity. Unfortunately, my customer has a very strict security environment. I did say the same thing to him. "Why don't control on the server end?". He replied "what if my servers get compromised?"
ISE 2.7 Guest Access Management Features
The following document explains the guest features of ISE 2.7. For more detail of what ISE 2.7 has to offer please check the associated documentation.
Auto Login on Sponsor Approval
SymptomsOutage during FTD code upgrade DiagnosisThe FTD code upgrade thru FMC will cause the traffic interruptionSolutionBelow process will upgrade the FTD with no downtime and no traffic interruption.Before the upgrade process:Download the FTD platf...
Process for FTD migration with PolicyAs per Cisco documentation, we have below steps for for de-register and register process. Please follow below steps :Step 1 : Break HA pair and de-register your FTD from FMC (old).Step 2 : Register your primary FTD wit...
Hi There,Is there a relationship between the hardware of the Cisco ASA 5505 FWs (V02) and the 9.x software version? Multiple ASA have been successfully updated with the same software. The ASAs that have been updated without any problems are V06 versi...
Dear Cisco Customers and Partners,
We know that the Cisco Identity Services Engine (ISE) is a critical element of your network security and so stability is of paramount importance. As a result, many of you asked us for a suggested release given sev...