Can I recieve secure smtp traffic

I've been asked by a manager if we can accept secure emails from outside domains.  In other words I work for company A ( that runs an Exchange 2003 server with an ISA firewall for webmail and a spam appliance for smtp traffic. Company B wants to send one of my users a secure email, how do I set that up?

I have a public cert for and I've read about how to secure internal email traffic using a Cert but does that apply to external as well?

Does it depend on the type of application Company B is using to secure its mail?

Does my spam appliance need to accept the secure email, is this not an Exchange issue at all?

As you can tell I'm grasping at straws here and any help would be appreciated.
Who is Participating?
Dave HoweConnect With a Mentor Software and Hardware EngineerCommented:
ftp has two encrypted "flavours" - ftps (like https, but for ftp) and sftp (sftp doesn't exist, but its helpful occasionally to pretend that it does; I know that sounds confusing, but sftp is actually file-transfer-over-ssh and requires an ssh server)

ftps has a downside in that its notoriously hard to get to work though firewalls - that has to do with how ftp works, in that ftp has a "control channel" on port 21, then sends all data (including dir listings) as separate connections - either from port 20 back to a port on the client, or to a random high port (identified to the client by the server as a connection target)

this is all well and good, until you have to make it though a firewall where the address of client (or server) differs from the ip address seen across the internet. in those cases, the firewall has to "fix up" the ftp control channel so that it rewrites the ports and ips of the data channels in such a way that they are valid for internet use.

with ftps, that can't happen, as the control channel is encrypted; for that reason, the client (for active) or server (for passive sftp) must be directly on the internet, not a good setup.

sftp is different, in that a single tcp connection (on port 22) is used for both control and data; this is very easy to get through firewalls (its just a single port, and it is *only* from client to server) but is notoriously slower than ftp and unless very carefully configured, lets users have far more from the connection than just simple file transfer.

another way to move data is by https - use a file upload script to upload data to a https server (which can then put it wherever is convenient)

The most common way to transfer information securely is to encrypt it, *then* transfer it. at its simplest, that just means putting it in a winzip (or 7z, or winrar) file, getting it to the recipient by whatever insecure method seems easiest, then getting the password to the recipient by some other (hopefully more secure) method. There are ways and means to make that easier too (you can agree passwords in advance, calculate passwords based on date and a fixed string, or use some sort of PKI scheme such as PGP and S/MIME use, but in the latter case, you are better off just using pgp or s/mime :)

Always worth remembering that the highest bandwidth link between two sites in the same country is a few dvd-rs in an envelope. this is high latency (ping time is about 24 hrs :) but you can transfer 10-20gb of data for the price of a stamp and some blank media, and with suitable encryption (truecrypt container files, for example) you can make sure only the recipient has a hope of reading the data from the dvd-rs if they are intercepted in transit.
Dave HoweSoftware and Hardware EngineerCommented:
ok, this depends on what you mean by "secure email".

You already appear to have read about how to set up SMTPS - SSL (actually, TLS) encrypted email transmission, which is similar to how https works (and just as https carries http inside the encrypted "channel", smtps carries smtp traffic)

The issue there is that smtps (aka smtp/tls) is a per-connection security option, and is not only per-link, but has to be chosen by both sides (the sender must choose to use tls when it sees "STARTTLS" as one of the replies to the "EHLO" command, and the recipient in turn must provide a valid X509 certificate. If you have a spam appliance, then the odds are good that that receives inbound mail as it arrives in your network, so that must be the one that provides the X509 certificate to the "outside world". Similarly, Company B must send to your site directly (not via an smtp smarthost at their ISP) or they can't ensure that the link from isp to you is encrypted, or even that their ISP allows the link from Company B to the ISP to be protected. Further, they must configure their server to *insist* that TLS be used - otherwise, an attacker could just substitute their own mailserver between you, and not offer TLS at all (which would cause most mailservers to fail back to unencrypted mail)

For these reasons, apart from deliberately created links (smtp bridgeheads) between predefined sites, TLS is rarely used in the real world.

Slightly more common (but still pretty rare) are per-email encryption schemes. This is noticably harder to set up (because the recipient must first transfer an encryption key, per recipient, to the sender) but still not massively hard - there are two schemes in common use (actually, there are better than thirty, but between them, OpenPGP and S/MIME are more than 90% of all encrypted traffic out there, everything else is a bit player)

if you have a Company B interested, you might want to discuss with them how they would like to approach this. you can fit a TLS certificate to your spam device, and have them enforce that all mail to yourselves is encrypted (this is a setting for most mailservers) or you can discuss exchanging keys so that the mail client can handle the encryption.

there is a third option, in that cisco/ironport supply a device which can encrypt mails to a key, then supply that key at need from a cisco server  (called a "key oracle" in the literature) once the recipient logs in with a username and password. That has to be set up by the sender though (although there is a "secure reply" option for recipients)
dtabrown2Author Commented:
Wow,  Dave that was the best answer i've ever gotten on this site.  

Is there another more common way to transfer encrypted information?  We have a secure FTP site would that be a better solution?
dtabrown2Author Commented:
thank you for the very detailed responses.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.