Thanks Roco!! PGP was discussed here with my co workers and we also agreed supporting the end users was not worth the trouble so i will try your other suggestions. Ill probably test it out this weekend and let you know on monday how it went.
On Fri, Jan 22, 2010 at 1:14 AM, IT-Doc24 Ltd. - Rocco Radisch < [email protected]> wrote: > You can even use PGP (content encryption) and TLS to encrypt on network > layer at the same time. > > Although, > if you encrypt the email content with PGP every receiver needs to have your > distributed key in order to decrypt the message. It is more secure but not > user friendly. > > Assuming you want to use your ISP as a email relay you configure postfix as > a smarthost. > Using TLS is not recommended. TLS encryption is initialised during the > communication. The client (postfix) sends a command (starttls) and if the > server (ur ISP) doesn't support TLS the communication will be continued > unencrypted. That behaviour can be tweaked to enforce TLS usage. Due to > support issues most email providers do not enforce TLS on the client side. > That also means, if someone sits in the middle (MITM-attack), intercepts the > traffic and suppresses the starttls command the email will be send > unencrypted. > It is better to use SSL on port 465. Unfortunately, postfix doesn't support > SSL from scratch, you will need a little workaround via stunnel. > First you need to check if your email provider supports SSL: > telnet EMAIL-SERVER 465 > > Sample config for stunnel4, /etc/stunnel/stunnel.conf: > [ssmtp] > accept = 127.0.0.1:26 > connect = ISP-MAIL-SERVER-SECURE-HOSTNAME:465 > > Furthermore, it is recommended to set-up a dedicated system user (adduser > stunnel4): > setuid = stunnel4 > setgid = stunnel4 > > also to activate chroot: > chroot = /var/run/stunnel4/ > > Performance improvements: > socket = l:TCP_NODELAY=1 > socket = r:TCP_NODELAY=1 > > And you need to determine your OSs certificate root path, with RHEL it > would be: > CApath = /etc/ssl/certs > > Also use at least the root certificate verification: > verify = 2 > (not 1, would have the same effect as TLS) > > Then you open your postfix config file (/etc/postfix/main.cf) and change > your relay host to: > relayhost = 127.0.0.1:26 > > If you need to activate smtp auth you also need to add: > smtp_sasl_auth_enable = yes > smtp_sasl_security_options = noanonymous > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > > Do not mix that up with the lines starting with "smtpd_...". That is for > the postfix server part, not the client settings. > > Then you need to create the login password map, nano > /etc/postfix/sasl_passwd: > 127.0.0.1 username:password > > Then rehash the auth file: > postmap /etc/postfix/sasl_passwd > > Voila! The advantage is: > If someone sits in the middle and tries to fake the SSL certificate, sends > back the faked certificate to the client and again he could intercept the > traffic (because its the attackers certificate and he can decrypt), it would > fail. Stunnel would drop the communication immediately because stunnel > verifies the certificate before letting pass any traffic. It is not likely > that the attacker is able to get a signed certificate matching your > providers hostname. Depending on your email provider's SSL certificate > provider you might need to import the according root certificate in order to > let the system know that the certificate is valid. (look in the log file if > you see funny certificate validation errors) > If you have control to both sites you could also create your own > certificate and use verify=3 in the stunnel config file (plus the cert/key > options). Then, only the server or person who possess this very certificate > would be able to intercept the traffic. But you wouldn't send the > certificate around and keep it somewhere safe. > > Best regards, > Rocco > > > On 21/01/2010 22:32, sanga collins wrote: > > I just finished setting up a zimbra email server for a new client. They are > in the health care industry so there are tons regulations and rules to > follow related to keeping patient information secure. Id like to here what > some of the other Lug are using for encrypting their emails sent out from > their servers and get a general idea of what is out there in the open source > world that i should look into using. > > -- > Sanga M. Collins > Network Engineering > ~~~~~~~~~~~~~~~~~~~~~~~ > Google Voice: (954) 324-1365 > E- fax: (435) 578 7411 > > > _______________________________________________ > LUG mailing list > [email protected]http://kym.net/mailman/listinfo/lug > %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The List's Host is not responsible for them in any way. > --------------------------------------- > > > > > _______________________________________________ > LUG mailing list > [email protected] > http://kym.net/mailman/listinfo/lug > %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The List's Host is not responsible for them in any way. > --------------------------------------- > > > -- Sanga M. Collins Network Engineering ~~~~~~~~~~~~~~~~~~~~~~~ Google Voice: (954) 324-1365 E- fax: (435) 578 7411
_______________________________________________ LUG mailing list [email protected] http://kym.net/mailman/listinfo/lug %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The List's Host is not responsible for them in any way. ---------------------------------------
