SMTP - any security?

[snootalope]

I'm not an expert on the smtp protocol. Been working with it forever, just never payed much attention to the protocols security, or lack there of.

I was recently asked by a compliance person "what kind of encryption do we have on our emails?" - I was stunned because first off I really don't know if the messages between company A and company B have any encryption at all. As far as I know, there's zero encryption. With no encryption, there's really no security on it all. Now I know I can lock down our Exchange server as far as relay's and what not, but I'm talking about the actual security the message has as it's broke down and sent across the internet to another mail exchange.

Does any know what security there might be by default? Is it just as vulnerable as someone's traffic flowing to and from any given webserver? Is there anything I can do or should be doing with our smtp messages?

 

[cckens]

This article works well for describing the types of e-mail security that can be used Exchange-wise and Outlook-wise.

http://searchexchange.techtarget.com/generic/0,295582,sid43_gci1251867,00.html

There's some setup involved for using some of it, but the article itself is a pretty good primer for the topic.

cckens

"Not always my best shot, but I hit the target now and then"
-me

 

[58sniper]

You need clarification from the compliance person as to which emails they're referring to. Inbound SMTP from outside your org generally isn't encrypted unless a user encrypts them on a per message basis with something like S/MIME. You can encrypt the connection using TLS, but you can't enforce that for all inbound email (well, not without dropping most inbound mail).

You could encrypt email within the org using certs and stuff.

But your question is a little too vague to give a more complete answer.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[allywilson]

This is actually a pretty interesting question, and not something I've really thought about before.

SMTP sends your password in clear-text (if your ISP or whatever requires authentication). The user/pass combo is usually your ISP's logon/sign in name as well

On another note secure certificates can be used between domains - but it's not a universal solution, as an admin has to import it each one.

 

[58sniper]

Admins don't have to import them unless they're not trusted certs. And since a trusted cert is $20..... and that goes back to my comment earlier - that's TLS. That doesn't encrypt the mail. It encrypts the connection.

As for user IDs, that's only if you're not using an internal email server, and using something trivial like POP3 or IMAP4.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[SteveRoadWarrior]

SPF doesn't encrypt messages but does help identify the sending server as an authorized representative for that domain. You can put a little trust in the sending IP address, like anything else, so that does help provide a little validation that the message actually came from the domain.

It only takes a few minutes to set up. It would be nice if more people used it properly... if for no other reason than to prevent spoofing.

http://www.openspf.org

 

[58sniper]

But SPF does nothing to keep it secure in transit.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[Davetoo]

Correct...which is what he opened up his statement with..."SPF doesn't encrypt messages..."

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

There are no more PDC's! There are DC's with FSMO roles!

 

[compuveg]

I worked at a bank 2 years ago, and there was practically no viable solution when I researched it about 2 years before my layoff. S/MIME and other stop-gap attempts at securing SMTP are just that, stop-gap. If everyone from Spam King to Symantec weren't making money hand over fist on spam they would come up with a better email protocol.

The best you can hope to do is to setup a web based mailserver in your DMZ, and only allow in HTTPS traffic. Allow that web baased mailserver to transmit SMTP only to or from your internal mailserver.

I got something from IPSwitch that was just a web based mailserver, and put it on a spare machine, and the whole thing cost under $1500. Turnkey solutions can cost anywhere from $25/month per account to $125,000. There are open sourced solutions, but we wanted to pay for something so we could have someone to hold accountable.

If you're really slick, like most of the major banks, you can integrate this messaging system. That will result in a single signon to access both your account and your secure mail with them. Otherwise your IT folks are going to be setting up secure mail accounts on an as-needed basis.

 

[58sniper]

Correct...which is what he opened up his statement with..."SPF doesn't encrypt messages..."

My bad - I meant to add something and got side tracked.

The OP was asked by the auditor about encryption of email. So - we have to look at just that. You can setup TLS so that it encrypts the connection between servers when TLS is available. The problem is that it's not opportunistic in 2003, so it doesn't come on when both sides support it unless you force it on. And that brings up other administrative headaches. It also doesn't encrypt the mail - just the path it takes.

The next problem is third party encryption of email, and what that does for the internal workings of Exchange, including archiving and compliance monitoring.

So - you can do S/MIME and digital encryption and signing if you want to publish CAs, etc. Quite a bit of work, but it can be done.

When SMTP came around, no one in the world was thinking about the problems we have today with spoofing, spamming, interception, etc. The industry has come up with many ways to deal with these issues, but implementing them without breaking something is quite difficult.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[snootalope]

soooo.. There's just not good solution for encrypting email, or even the connection itself. Both parties have to have encryption turned on, but whats the chances of that happening for every email to the millions of domains out there. It's interesting, the most popular form of communication, and it's all sent in plain text.

There ya go, become a multi-billionaire over night and invent an industry standard that we can all apply in our next M$ update.

 

[58sniper]

It's not a Microsoft issue.

If you have a preferred vendor or partner you deal with often, setting up TLS between the two is very straightforward (each side creates a new connector for just that address space, and forces TLS).

In Exchange 2007, it's opportunistic by default, so it will negotiate TLS if the other side presents it in the EHLO handshake. Mutual TLS will take that one step further and authenticate with the other side when so configured.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[snootalope]

all the more reason to update to Exchange 2007.. I need to get rolling on that, but my expertise in the MS Command Shell is very VERY lacking.

Thanks for all the information guys!!