I85PREP
⌘ K
Cisco 300-720 SESA study materials
Cisco 300-720 SESA study resources

Cisco 300-720 SESA: ESA Deployment and Administration

Cisco 300-720 SESA · Work through your exam, one topic at a time.

All guide sections

ESA Deployment and Administration

This domain tests whether you can bring an ESA into service and keep it administrable: appliance models and virtual options, listeners, host and recipient access control, routing, clustering, and safe configuration management through the AsyncOS commit model.

Core rules

  • Deployment shapes: standalone appliance, hardware or virtual, and clustered appliances under centralized management. In a cluster, most policy and listener settings are cluster-wide; interface, IP, and hostname settings are per-machine. Plan which changes must stay machine-specific.
  • A listener is the SMTP service bound to an interface and port. Public listeners face the internet; private listeners accept outbound mail from internal MTAs and allow relaying.
  • Each listener has a HAT (which connecting hosts are allowed, and which mail flow policy applies) and a RAT (which recipients are accepted). HAT entries are evaluated top-down, first match wins.
  • Mail flow policies carry max message size, max recipients per message, TLS settings, and which scanning features apply.
  • SMTP routes define the next hop per domain; without them the ESA falls back to MX lookup, which is wrong for internal domains that must be delivered to a back-end mail store.
  • Changes are staged until commit. rollback returns to the last committed state; saveconfig and loadconfig move configurations between appliances.

Worked example

A partner relays mail from 203.0.113.0/24 and a back-end Exchange server sends outbound mail from 10.20.0.0/16. On the public listener, add a HAT entry for 203.0.113.0/24 with a mail flow policy that does not permit relaying, placed above any broad accept rule. On the private listener, add 10.20.0.0/16 with a RELAY-enabled policy, and add an SMTP route for the internal domain pointing to the Exchange host. Add a RAT entry accepting only your own domains on the public listener so unknown recipients are rejected at SMTP time rather than bounced later. Commit, then send test messages from each path.

Traps

  • A broad HAT accept entry above a specific deny entry silently opens relaying; order is everything.
  • Leaving a public listener with no RAT entries accepts all recipients.
  • Listener edits propagate cluster-wide while interface changes do not, so a "fix" applied on one machine may not be the one taking effect.
  • Forgetting commit leaves the GUI showing edits that are not running.
  • Deleting a listener or route that other settings reference breaks mail flow silently until the next message arrives.