WEBVTT 0:00:02.100000 --> 0:00:06.320000 In this video, I'm going to talk about email encryption techniques. 0:00:06.320000 --> 0:00:11.220000 The topics I'm going to go over is what exactly is email encryption and 0:00:11.220000 --> 0:00:12.560000 why would we use it? 0:00:12.560000 --> 0:00:14.520000 What benefits does it provide? 0:00:14.520000 --> 0:00:17.520000 And I'll talk about two high level types of encryption. 0:00:17.520000 --> 0:00:20.320000 One is called transport level encryption. 0:00:20.320000 --> 0:00:22.240000 One is called end to end encryption. 0:00:22.240000 --> 0:00:25.540000 I'll talk about the differences, the pros and the cons and some of the 0:00:25.540000 --> 0:00:27.440000 challenges about each one. 0:00:27.440000 --> 0:00:31.120000 And then we'll roll in the Cisco email security appliance and see what 0:00:31.120000 --> 0:00:36.060000 role it has to play with regards to email encryption. 0:00:36.060000 --> 0:00:37.720000 Let's talk about this. 0:00:37.720000 --> 0:00:41.700000 So by default, the emails that you send, the emails that you receive are 0:00:41.700000 --> 0:00:46.240000 not encrypted, which means that anybody in the middle could intercept 0:00:46.240000 --> 0:00:50.660000 them and read them and quite possibly change them. 0:00:50.660000 --> 0:00:53.960000 So this is a prime reason why we might want to use encryption. 0:00:53.960000 --> 0:00:58.440000 Now, encryption adds a whole other layer of complexity onto this. 0:00:58.440000 --> 0:01:02.220000 But especially if you're dealing with emails are highly secure in nature, 0:01:02.220000 --> 0:01:06.960000 dealing with financial information, banking information, stock information, 0:01:06.960000 --> 0:01:10.160000 well, you might want to consider encrypting the contents of emails like 0:01:10.160000 --> 0:01:17.560000 that. So when using a native email client like Microsoft Outlook, okay, 0:01:17.560000 --> 0:01:19.440000 Outlook, Eudora, something like that. 0:01:19.440000 --> 0:01:22.940000 And what I mean by native email client is software that you downloaded 0:01:22.940000 --> 0:01:28.180000 and installed onto your laptop per PC and your emails are being locally 0:01:28.180000 --> 0:01:30.560000 stored on your hard drive. 0:01:30.560000 --> 0:01:35.560000 So when you're using a client like that, by default, there is no encryption. 0:01:35.560000 --> 0:01:39.700000 So emails that you're receiving, emails that you're sending, plain text. 0:01:39.700000 --> 0:01:44.420000 Now a lot of people, such as myself, use web-based email services like 0:01:44.420000 --> 0:01:46.200000 Gmail and others. 0:01:46.200000 --> 0:01:51.700000 So in that particular case, nothing is actually being downloaded to your 0:01:51.700000 --> 0:01:55.660000 laptop. You are just opening up a web browser page, just like as if you 0:01:55.660000 --> 0:02:00.020000 open up a web browsing page to INE.com or some news service or something 0:02:00.020000 --> 0:02:05.060000 like that. And all the emails are being stored locally on, for example, 0:02:05.060000 --> 0:02:07.460000 the Gmail email server. 0:02:07.460000 --> 0:02:09.580000 And you're just reading them from the web page. 0:02:09.580000 --> 0:02:15.020000 And if you click like delete or if you click something to star an email, 0:02:15.020000 --> 0:02:17.040000 nothing's happening locally on your machine. 0:02:17.040000 --> 0:02:21.520000 You're just sending up commands to the Gmail server to make those changes 0:02:21.520000 --> 0:02:24.960000 to the email right there on the server. 0:02:24.960000 --> 0:02:28.700000 So in that particular case, you are most likely, you could be potentially 0:02:28.700000 --> 0:02:31.740000 using IMAP to send messages. 0:02:31.740000 --> 0:02:34.500000 Now let's take a step back here. 0:02:34.500000 --> 0:02:39.280000 When you're using a web-based email service, it could be done in one of 0:02:39.280000 --> 0:02:43.840000 two ways. A lot of people, what they do is they just open up their browser. 0:02:43.840000 --> 0:02:48.620000 They open up Chrome or Firefox or Internet Explorer and do everything 0:02:48.620000 --> 0:02:51.500000 there within the confines of the browser. 0:02:51.500000 --> 0:02:56.700000 Or alternatively, you might work for a company that for a while was using 0:02:56.700000 --> 0:03:02.220000 a local email client like Eudora or Microsoft Outlook or something else. 0:03:02.220000 --> 0:03:06.940000 And then they decided that, hey, we don't want to manage our email server 0:03:06.940000 --> 0:03:09.160000 anymore. We want to get rid of that. 0:03:09.160000 --> 0:03:12.260000 We'd rather use Gmail as an example. 0:03:12.260000 --> 0:03:15.220000 And we'll just take advantage of their Gmail, you know, their G Suite 0:03:15.220000 --> 0:03:20.540000 for business and let them do all this build monitor, the mail server, 0:03:20.540000 --> 0:03:22.380000 they'll perform updates on it. 0:03:22.380000 --> 0:03:23.860000 We don't have to worry about that. 0:03:23.860000 --> 0:03:30.320000 But because all of our clients already have, let's say, Outlook installed, 0:03:30.320000 --> 0:03:33.040000 why don't we just use Outlook and why don't we go into Outlook on the 0:03:33.040000 --> 0:03:37.780000 laptop and an Outlook, instead of pointing to the mail exchange server 0:03:37.780000 --> 0:03:42.140000 that's here locally in our company, which we're getting rid of now, let's 0:03:42.140000 --> 0:03:45.120000 change Outlook to now point to Gmail. 0:03:45.120000 --> 0:03:46.080000 And you can do that. 0:03:46.080000 --> 0:03:50.700000 So in that particular case, the user's experience is that they would still 0:03:50.700000 --> 0:03:54.980000 double click the Microsoft Outlook icon on their laptop. 0:03:54.980000 --> 0:03:57.240000 Microsoft Outlook would open up. 0:03:57.240000 --> 0:04:00.520000 They would have no idea that behind the scenes Outlook was actually going 0:04:00.520000 --> 0:04:04.200000 to a Gmail server to send and receive their emails. 0:04:04.200000 --> 0:04:09.820000 So in Outlook, when they are sending messages saying, please give me my 0:04:09.820000 --> 0:04:11.680000 mail or please delete this mail. 0:04:11.680000 --> 0:04:14.460000 Now in that particular case, they are using iMap. 0:04:14.460000 --> 0:04:18.740000 They're using iMap, which is being encrypted by SSL or TLS to talk to 0:04:18.740000 --> 0:04:21.180000 the Gmail server. 0:04:21.180000 --> 0:04:32.520000 Okay. And between the mail exchange servers, now the mail exchange servers 0:04:32.520000 --> 0:04:37.500000 could be a mail exchange server that's administered locally in your company 0:04:37.500000 --> 0:04:41.040000 by your own IT staff, or we could be talking about a mail exchange server 0:04:41.040000 --> 0:04:44.900000 that's maintained and monitored by a company like Gmail or Google, for 0:04:44.900000 --> 0:04:50.840000 example. Either way, when emails are going between mail exchange servers, 0:04:50.840000 --> 0:04:56.220000 that may or may not be encrypted, just depending on what the policy is 0:04:56.220000 --> 0:05:01.260000 for whoever's set up and is maintaining that mail server. 0:05:01.260000 --> 0:05:05.080000 So clearly, if we want to implement encryption, one of the benefits we 0:05:05.080000 --> 0:05:07.080000 get is confidentiality. 0:05:07.080000 --> 0:05:10.620000 Now if someone is able to snoop on our email thread, be able to actually 0:05:10.620000 --> 0:05:14.040000 capture it and transit, they're not going to be able to read what it is, 0:05:14.040000 --> 0:05:15.560000 and they're not going to be able to change it. 0:05:15.560000 --> 0:05:19.540000 It'll just look like meaningless garbage to them because it's been encrypted. 0:05:19.540000 --> 0:05:24.860000 So there are two general ways you can implement email encryption. 0:05:24.860000 --> 0:05:30.620000 There's something called transport level encryption and end to end encryption. 0:05:30.620000 --> 0:05:33.020000 So let's talk about both of those. 0:05:33.020000 --> 0:05:39.300000 So transport level encryption at a real high level, what you're talking 0:05:39.300000 --> 0:05:46.500000 about is each hop in the process gets an encrypted session between hops. 0:05:46.500000 --> 0:05:51.020000 So for example, transport level encryption would mean that on my local 0:05:51.020000 --> 0:05:56.720000 laptop, when I open up my email program, anything I send to the next hop, 0:05:56.720000 --> 0:05:58.600000 which would be my mail exchange server. 0:05:58.600000 --> 0:06:01.420000 So when I'm uploading an email, or when I'm going to that mail exchange 0:06:01.420000 --> 0:06:05.680000 server and downloading an email server, that would be encrypted. 0:06:05.680000 --> 0:06:10.200000 My mail server and myself, my laptop, would have some sort of a pre shared 0:06:10.200000 --> 0:06:14.380000 key, which would be used to encrypt and decrypt the emails. 0:06:14.380000 --> 0:06:16.840000 Now let's say I'm uploading something. 0:06:16.840000 --> 0:06:20.080000 So what I upload to the mail server would be encrypted. 0:06:20.080000 --> 0:06:23.460000 There, the mail server would decrypt it. 0:06:23.460000 --> 0:06:26.920000 And then at that point, the mail server would turn around, re encrypted 0:06:26.920000 --> 0:06:30.980000 again in its communication with the next mail server. 0:06:30.980000 --> 0:06:34.420000 So that would be the next hop from my mail exchange server to the next 0:06:34.420000 --> 0:06:35.680000 mail exchange server. 0:06:35.680000 --> 0:06:39.180000 That would be a completely separate encrypted session. 0:06:39.180000 --> 0:06:42.760000 So each sort of hop along the way, you could say each layer three hop 0:06:42.760000 --> 0:06:48.020000 along the way would be an encrypted session. 0:06:48.020000 --> 0:06:55.960000 So in transport level encryption, any or all of those hops along the way 0:06:55.960000 --> 0:06:59.000000 could be selected for the encryption process. 0:06:59.000000 --> 0:07:02.480000 Like this says right here, maybe between the end client and their mail 0:07:02.480000 --> 0:07:04.680000 server, it's just plain text. 0:07:04.680000 --> 0:07:08.680000 I mean, if that mail server is located here within my company, monitored 0:07:08.680000 --> 0:07:12.920000 and maintained by my own IT staff, maybe we decide, you know what, hey, 0:07:12.920000 --> 0:07:15.960000 from my employees talking to my mail server, we don't need to go through 0:07:15.960000 --> 0:07:18.160000 the hassle of encrypting that process. 0:07:18.160000 --> 0:07:20.560000 Everything is self contained within the company here. 0:07:20.560000 --> 0:07:21.440000 It's all secure. 0:07:21.440000 --> 0:07:22.980000 It's on the inside of the firewall. 0:07:22.980000 --> 0:07:24.540000 We don't have to worry about that. 0:07:24.540000 --> 0:07:28.180000 All we want to have encrypted is when emails are leaving my mail exchange 0:07:28.180000 --> 0:07:31.000000 server going out to the internet and going to some other mail exchange 0:07:31.000000 --> 0:07:35.160000 server, who knows where, we want that part to be encrypted. 0:07:35.160000 --> 0:07:37.920000 So you could do that with transport level encryption. 0:07:37.920000 --> 0:07:39.720000 So where the positive? 0:07:39.720000 --> 0:07:43.260000 Well, certainly, if you're not going to be doing any encryption between 0:07:43.260000 --> 0:07:48.020000 the client and their local mail exchange server, no special user interactions 0:07:48.020000 --> 0:07:50.540000 require. They just do everything as normal. 0:07:50.540000 --> 0:07:54.040000 It mitigates an eavesdropper stooping on the communication and it's pretty 0:07:54.040000 --> 0:07:56.000000 easy to implement. 0:07:56.000000 --> 0:07:57.940000 But there are some downsides. 0:07:57.940000 --> 0:08:01.120000 We're not talking about end to end encryption here. 0:08:01.120000 --> 0:08:05.500000 So because of this, if somebody manages to hack into one of those mail 0:08:05.500000 --> 0:08:10.140000 exchange servers, if they can somehow get access to that, now, remember 0:08:10.140000 --> 0:08:13.140000 when the email is getting to the mail exchange server, it might come in 0:08:13.140000 --> 0:08:16.700000 as encrypted. But that mail exchange server as part of its processing 0:08:16.700000 --> 0:08:20.580000 is going to decrypt that email before it turns around and says, OK, who 0:08:20.580000 --> 0:08:22.480000 do I send it to next? 0:08:22.480000 --> 0:08:24.120000 And who I send it to next? 0:08:24.120000 --> 0:08:26.240000 I may or may not encrypt it. 0:08:26.240000 --> 0:08:30.120000 So if I'm on that mail exchange server, I can see that email in its decrypted 0:08:30.120000 --> 0:08:37.040000 state. So an example protocol that's used for this type of thing for transport 0:08:37.040000 --> 0:08:39.760000 level encryption is Start TLS. 0:08:39.760000 --> 0:08:44.200000 And this is actually what Gmail uses, what Google Mail uses between their 0:08:44.200000 --> 0:08:45.960000 mail exchange servers. 0:08:45.960000 --> 0:08:49.560000 So with transport level encryption, we're talking about each hop, right? 0:08:49.560000 --> 0:08:51.800000 So it's your choice as an option. 0:08:51.800000 --> 0:08:55.260000 You could have between the client and their server. 0:08:55.260000 --> 0:08:57.240000 You could have that encrypted. 0:08:57.240000 --> 0:09:00.400000 You could choose, OK, well, I'm not going to do that, but between one 0:09:00.400000 --> 0:09:02.900000 mail server and another. 0:09:02.900000 --> 0:09:09.660000 I'm going to have that encrypted. 0:09:09.660000 --> 0:09:13.380000 And or you could say, well, between the mail server and the end user. 0:09:13.380000 --> 0:09:16.060000 I'm going to have that encrypted. 0:09:16.060000 --> 0:09:19.680000 Or you could say, I'm going to encrypt each one of these steps here. 0:09:19.680000 --> 0:09:21.980000 So in transport level encryption, you get to choose. 0:09:21.980000 --> 0:09:26.480000 But remember, every place there's a boundary here, like there and there, 0:09:26.480000 --> 0:09:32.360000 that is a point in which mail is being decrypted, temporarily stored in 0:09:32.360000 --> 0:09:36.640000 a plain text form, and then being re -encrypted again as it goes on to 0:09:36.640000 --> 0:09:40.920000 the next hop. So that boundary right there is a security risk. 0:09:40.920000 --> 0:09:50.100000 Your alternative would be to do end to end encryption, in which the clients 0:09:50.100000 --> 0:09:56.260000 themselves, if I'm sending an email to you, my client would encrypt that 0:09:56.260000 --> 0:10:00.560000 email. So it would be encrypted all the way through until it got to your 0:10:00.560000 --> 0:10:04.200000 client when you download that email from your email server. 0:10:04.200000 --> 0:10:09.460000 So this is clearly the most confidential because there's no process. 0:10:09.460000 --> 0:10:14.200000 There's no step in the middle where this email is ever decrypted. 0:10:14.200000 --> 0:10:18.500000 You should know some examples of end to end email encryption protocols. 0:10:18.500000 --> 0:10:21.040000 So here's just a listing of those. 0:10:21.040000 --> 0:10:24.600000 If you're taking certain certification exams, you would probably want 0:10:24.600000 --> 0:10:29.340000 to memorize that list as being examples of that. 0:10:29.340000 --> 0:10:36.320000 And all of these methods rely on the concept of exchanging of public keys. 0:10:36.320000 --> 0:10:41.420000 So what we're really talking about is the usage of asymmetric cryptography. 0:10:41.420000 --> 0:10:43.760000 Now you may have never heard of that term before. 0:10:43.760000 --> 0:10:46.140000 So there's two types of cryptography. 0:10:46.140000 --> 0:10:48.500000 There's symmetric and asymmetric. 0:10:48.500000 --> 0:10:53.140000 Symmetric cryptography is what's used most of the time in bulk encryption. 0:10:53.140000 --> 0:10:56.740000 When you're sending a ton of information back and forth between devices, 0:10:56.740000 --> 0:11:00.940000 you would use symmetric key encryption, which just simply means that both 0:11:00.940000 --> 0:11:06.820000 endpoints are using the exact same key to encrypt and decrypt the information. 0:11:06.820000 --> 0:11:07.920000 That's why it's symmetric. 0:11:07.920000 --> 0:11:11.680000 You and I are using the exact same creep for encryption and decryption. 0:11:11.680000 --> 0:11:15.940000 So that's used when there's bulk encryption involved, lots of encryption. 0:11:15.940000 --> 0:11:18.900000 By the case of email, we're talking about encrypting something that's 0:11:18.900000 --> 0:11:20.900000 rather small in size. 0:11:20.900000 --> 0:11:24.160000 And so that uses what's called asymmetric encryption. 0:11:24.160000 --> 0:11:28.020000 In asymmetric key encryption, what that means is that, let's start with 0:11:28.020000 --> 0:11:33.160000 my device. On my device, I would have to create two encryption keys. 0:11:33.160000 --> 0:11:36.480000 One that's called private and one that's called public. 0:11:36.480000 --> 0:11:41.840000 And so the weird math that gets involved with this is if you use one key 0:11:41.840000 --> 0:11:47.100000 to encrypt something, it can only be decrypted by the other key. 0:11:47.100000 --> 0:11:50.600000 In other words, if I encrypt something with my private key, if I gave 0:11:50.600000 --> 0:11:53.540000 that private key to you, it would be useless to you. 0:11:53.540000 --> 0:11:56.740000 Because now when I send you that encrypted text or then encrypted email, 0:11:56.740000 --> 0:12:01.220000 because I encrypted it with my private key, you cannot decrypt it with 0:12:01.220000 --> 0:12:10.620000 my private key. So in the world of asymmetric key cryptography, the private 0:12:10.620000 --> 0:12:12.940000 key is kept like it sounds private. 0:12:12.940000 --> 0:12:14.860000 You never ever ever give that out. 0:12:14.860000 --> 0:12:18.220000 And the private key is what you use when you're encrypting something and 0:12:18.220000 --> 0:12:19.520000 sending it to somebody else. 0:12:19.520000 --> 0:12:23.540000 So clearly, if I'm going to take my email, encrypt it with my private 0:12:23.540000 --> 0:12:27.160000 key and then send it to you for end -to-end encryption, that means you 0:12:27.160000 --> 0:12:32.960000 would have to have my public key to be able to decrypt and read that email. 0:12:32.960000 --> 0:12:35.700000 And similarly, if you're going to respond back to me and you're going 0:12:35.700000 --> 0:12:41.380000 to encrypt it with your private key, I would need to have your public 0:12:41.380000 --> 0:12:47.640000 key. So that is what makes end-to-end encryption sort of complex and difficult 0:12:47.640000 --> 0:12:52.500000 to implement. Because both sides have to number one, generate a key pair. 0:12:52.500000 --> 0:12:55.980000 Somehow they have to generate a public and a private key pair. 0:12:55.980000 --> 0:12:59.260000 And then number two, they have to have some mechanism in place that they 0:12:59.260000 --> 0:13:03.360000 can exchange their public keys, otherwise these encrypted emails will 0:13:03.360000 --> 0:13:07.220000 be useless. The other side won't be able to read it. 0:13:07.220000 --> 0:13:13.120000 So here's an example of in Microsoft Outlook sort of like what that would 0:13:13.120000 --> 0:13:16.740000 look like here. You would go into email security. 0:13:16.740000 --> 0:13:20.420000 You would select the appropriate boxes there to encrypt messages. 0:13:20.420000 --> 0:13:25.420000 And the important part that we see right here is this part. 0:13:25.420000 --> 0:13:27.440000 You would need a digital certificate. 0:13:27.440000 --> 0:13:33.560000 A digital certificate is an electronic message and it's got a lot of stuff 0:13:33.560000 --> 0:13:37.360000 in it. But the main component that we're concerned with here is that inside 0:13:37.360000 --> 0:13:41.840000 of a digital certificate, inside that electronic file, you put your public 0:13:41.840000 --> 0:13:47.060000 key. So I would have to create a digital certificate or import one that 0:13:47.060000 --> 0:13:49.060000 I purchased from somewhere else. 0:13:49.060000 --> 0:13:52.040000 And then be able to send you that digital certificate. 0:13:52.040000 --> 0:13:57.260000 When I send you my digital certificate, now you would have my public key. 0:13:57.260000 --> 0:14:01.080000 And you'd have to send me your digital certificate, which I would import 0:14:01.080000 --> 0:14:05.420000 right here. And now we could send end -to-end encrypted messages back and 0:14:05.420000 --> 0:14:06.840000 forth to each other. 0:14:06.840000 --> 0:14:10.660000 So this is probably the most secure form of encryption, but like you can 0:14:10.660000 --> 0:14:15.040000 start to get a feel for this, it requires the end users to have some intervention. 0:14:15.040000 --> 0:14:22.280000 It requires them to have a little bit of technical savvy to set this up. 0:14:22.280000 --> 0:14:28.740000 Or, lastly, if you purchase a Cisco email security appliance, one of the 0:14:28.740000 --> 0:14:32.440000 things that you can have it do is to do this encryption. 0:14:32.440000 --> 0:14:40.280000 This would be considered transport level encryption. 0:14:40.280000 --> 0:14:45.720000 And it uses something called the Cisco registered envelope service. 0:14:45.720000 --> 0:14:49.000000 So what's sort of interesting about the Cisco registered envelope service 0:14:49.000000 --> 0:14:53.320000 is that I create my email right here. 0:14:53.320000 --> 0:14:57.880000 So on my client, as I'm sending it, it's just regular unencrypted. 0:14:57.880000 --> 0:14:59.600000 It's a plaintext email. 0:14:59.600000 --> 0:15:04.600000 So from here to the ESA, now this ESA is presumably within the confines 0:15:04.600000 --> 0:15:08.140000 of my company. So it's secured, it's in a wiring closet, we're assuming 0:15:08.140000 --> 0:15:09.620000 that nobody can hack into it. 0:15:09.620000 --> 0:15:15.240000 So this is just, I'll just say plaintext at this point. 0:15:15.240000 --> 0:15:18.120000 And this is why we're saying it's transport level encryption, it's not 0:15:18.120000 --> 0:15:21.260000 end-to-end. But here's the beautiful thing about this. 0:15:21.260000 --> 0:15:27.220000 Now the ESA, once it gets my email, because it's been configured to do 0:15:27.220000 --> 0:15:34.700000 encryption, it generates a special key for me based on my credentials, 0:15:34.700000 --> 0:15:35.600000 a special key for me. 0:15:35.600000 --> 0:15:40.620000 And then it sends that key externally to the cloud to a very secure server 0:15:40.620000 --> 0:15:44.840000 that Cisco maintains called the registered envelope service. 0:15:44.840000 --> 0:15:46.720000 That key is stored there. 0:15:46.720000 --> 0:15:57.260000 Now the email itself is encrypted, sent across to the mail exchange server 0:15:57.260000 --> 0:16:02.280000 at the far end, stays in its encrypted format. 0:16:02.280000 --> 0:16:09.440000 And now this person here, they log on to their email and they also connect 0:16:09.440000 --> 0:16:11.340000 to the registered envelope service. 0:16:11.340000 --> 0:16:15.020000 So as they log into their email, they provide some sort of credentials 0:16:15.020000 --> 0:16:18.580000 to the Cisco registered envelope service. 0:16:18.580000 --> 0:16:21.880000 By providing their credentials, their username and password, they can 0:16:21.880000 --> 0:16:27.660000 retrieve this key, the key that originally generated for me. 0:16:27.660000 --> 0:16:32.040000 And so now when they log in and download their email, they'll see here 0:16:32.040000 --> 0:16:34.880000 a little window that says, hey, this email you're getting is encrypted, 0:16:34.880000 --> 0:16:36.720000 please provide the key and they've got the key. 0:16:36.720000 --> 0:16:39.720000 They automatically downloaded it. 0:16:39.720000 --> 0:16:43.680000 So this is how, so for my end, it's real simple. 0:16:43.680000 --> 0:16:45.180000 I don't have to do anything. 0:16:45.180000 --> 0:16:49.200000 The ESA is taking my email and encrypting it and providing the keys to 0:16:49.200000 --> 0:16:51.260000 the remote users all by itself. 0:16:51.260000 --> 0:16:54.240000 I can just sit back and create emails with assurance that they are going 0:16:54.240000 --> 0:16:57.940000 to be encrypted all the way to the end user. 0:16:57.940000 --> 0:17:05.440000 So some other benefits of using the Cisco registered envelope service, 0:17:05.440000 --> 0:17:09.160000 just in case you're kind of curious about this, is also provide some features 0:17:09.160000 --> 0:17:12.740000 which are called message expiration and recall. 0:17:12.740000 --> 0:17:17.420000 This is really nice because by using message expiration and recall, when 0:17:17.420000 --> 0:17:22.560000 you send out your message, if a few minutes later you decide, oh man, 0:17:22.560000 --> 0:17:23.520000 I shouldn't have sent that. 0:17:23.520000 --> 0:17:24.380000 That was a mistake. 0:17:24.380000 --> 0:17:26.100000 I meant that to go to John. 0:17:26.100000 --> 0:17:28.620000 Or maybe I was a little angry when I wrote that. 0:17:28.620000 --> 0:17:30.060000 I kind of regret having written that. 0:17:30.060000 --> 0:17:31.620000 I wish I could recall it. 0:17:31.620000 --> 0:17:35.040000 With Cisco registered envelope service, you can do that. 0:17:35.040000 --> 0:17:38.880000 As long as the other person hasn't gotten to it first, if you get to that 0:17:38.880000 --> 0:17:42.240000 message, you can click a little button or something and say, hey, recall 0:17:42.240000 --> 0:17:43.880000 the message, retract it. 0:17:43.880000 --> 0:17:45.920000 That way the end user will never see it. 0:17:45.920000 --> 0:17:50.240000 They'll never even know that you sent it in the first place. 0:17:50.240000 --> 0:17:55.820000 So that concludes the session here on Cisco, I should say email encryption 0:17:55.820000 --> 0:17:59.260000 techniques. I hope you found this to be useful.