Let's imagine Bob is sending an email.
That email is going to be sent via SMTP
over to the email server internally, who's
going to send it to the email security appliance, who's then
going to forward it or maybe it won't forward it.
Let's take a look at some of the rules and processes that
are going to be followed by the email security
appliance for outbound email.
So to start off, let's talk about the two listeners
I have on this email security appliance.
If we go to Network and we click on Listeners,
the incoming mail listener is the public listener
that's communicating with all the external MTAs, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's communicating with all the external MTAs,
the external email servers, and this listener
called outgoing email, which I guess I should
go ahead and rename that.
And let me rename it to private, because this
is the listener that's communicating
with our internal email server.
That's a little bit better.
And let me go ahead and click on Submit.
And also with the email security appliance,
once you click on Submit, you also
want to click on Commit Changes and Commit Changes again
to make it all part of the config.
All right, much better. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, much better.
So incoming from the outside world and our private listener
that we're using to communicate with our internal email server.
So for the incoming email server,
we have the HAT, which is all about the reputation scores,
and we also have the recipient access
table, which is specifying what domains this is for.
So traffic coming in for ogit.com anything,
and for these two email addresses at those domains,
those would be allowed, and everything else
will be rejected.
Also we can use LDAP, and we can verify if someone
does send an email to ogit.com.
But it's an email address that doesn't exist in LDAP, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But it's an email address that doesn't exist in LDAP,
we can go ahead and drop it right
here at the email security appliance as well and not even
bother the real email server.
All right, but I digress.
Let me go back to the network and to listeners,
and I want to focus on the private listener.
So for the private listener, we could be sending those emails
to like anybody in the whole world,
so we don't have a recipient access
table on the private side, but we
do have a HAT, the host access table, that's
just identifying who we're willing to basically receive
messages from.
And if we click on the HAT for the private listener, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we click on the HAT for the private listener,
and the default policy here is the sender group is relay list
and the mail flow policy is relayed, meaning
it's just going to forward it.
And this basically means that if email messages are being
sent from our internal server to this email security appliance,
it's going to go ahead and forward it.
And if we click on the sender group called Relay List,
and we scroll down, during the setup
wizard it asked me what my real email server was.
So this 192.168.1.100 is my internal email server,
and so basically it's saying if I get email messages WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and so basically it's saying if I get email messages
from this MTA, that email server, effectively
the sender here, is going to be trusted
because the internal server.
So a big difference here.
If we're receiving from email servers on the outside world,
we have that whole reputation score and checking
and all the rest.
And if we're receiving from our internal server,
we're basically saying, I know who you are, I trust you.
I'm going to go ahead and allow that email in.
But just because it got through that first pass,
and the email security appliance, says, yep,
I'm willing to take in emails from you, Mr. Internal Email
Server, that doesn't mean I'm just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Server, that doesn't mean I'm just
going to forward everything.
So in addition to trusting, OK, I trust you Mr. Email Server
Internal, I'm going to receive these email messages from you,
there's a whole bunch of policy options
we have regarding outbound mail that we can still
put through its paces before the emails are sent.
And those can be found right here.
If we go to Email Policies, and we
go to Outbound Mail Policies.
So regarding outbound mail policies, check this out.
We can do antispam checking.
We don't want our internal user spamming the world
from our email servers, so we want to catch that and stop it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from our email servers, so we want to catch that and stop it.
We also don't want to be sending viruses or malware
from our internal clients going out.
There's options for advanced malware protection,
for graymail, and many of these are
dependent on which features or licenses you have enabled.
We can apply content filters, including
specifying that we want to encrypt certain email
messages based on the characteristics
of those emails.
There's outbreak filters, which are really important for a zero
day attacks.
If something brand new is happening,
we want to be able to be aware of that, see it happening,
and then shut it down as fast as possible
so we're not part of the problem. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so we're not part of the problem.
And for outbound, this is new, which
was not on the inbound policy, and that
is data loss prevention.
So we can specify which elements we want for data loss
prevention, and then it can start
looking for that in the emails.
For example, is there credit card information
or social security numbers or other sensitive information
based on the policy we have, and it
can stop those emails from going out
before they're actually sent.
So here's the major takeaway regarding inbound email
and outbound email.
For email that is coming in, it's all about reputation
and HAT, the host access table, which is driven primarily WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and HAT, the host access table, which is driven primarily
by reputation, and that's going to cause the email security
appliance to drop just a ton of emails
if the reputation of the sender is just too low.
Now, contrast that against email being
sent from our internal server going out.
We don't have all that reputation stuff
for our internal server because we know what it is.
So we configured it, we pointed to its IP address,
and email from the internal server going out
isn't going through that whole reputation game.
Now in either case, even if we pass the reputation coming in,
and we know who that server is on the inside going out, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we know who that server is on the inside going out,
we still have all the policy and rules that have to be followed.
And the biggest difference with all those individual rules,
which we'll take a closer look at,
is the data loss prevention, which
applies only to the outbound.
So we're looking for credit card information or social security
number information or other details that
shouldn't be sent out.
That's an additional rule that we
can have as a check for outbound email traffic.
So thanks for joining me in this video.
In the next video, I'd like to chat with you about everybody's
favorite topic, spam, and doing some additional spam filtering WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
favorite topic, spam, and doing some additional spam filtering
on the email security appliance.
So I'll see you in that next video in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.