** NOTE ** You might want to read this entire thread -- there was security discussion about the solution proposed in this HOWTO, it was resolved, and I have updated this post as indicated in red below. FYI, the security issue involved using the "-r localhost:smtp" argument to stunnel, which makes all incoming connections appear to come from localhost and thereby opens your server to any incoming e-mail, including spammers. **

There used to be a HOWTO thread on setting up SMTPS, or at least I seem to remember one. A couple other threads discuss quick stunnel commands, but nothing dedicated to this subject.

First some background. SMTP is the service that your mail client uses to send e-mail through your server. Since SMTP is typically in clear-text (unencrypted), anything sent between your mail client and your server could potentially be monitored. This is not such a big deal once your message gets into switched router-land on the 'net, but might be a security concern for you within your company network or shared networks such as cable modems. The risk is greater if you use the authentication features of SMTP, where your username and password are sent over the connection so that you can send e-mail from any network or ISP.

Setting up secure SMTP is pretty simple. Add a new service file named "smtps" in your /etc/xinetd.d/ directory and populate it with this information. Note: here is where I have edited the HOWTO with the results of the discussion below -- thanks to everyone who contribued! The stanza here should be correct:


Then cd to /usr/share/ssl/certs and create a certificate file for stunnel either by copying some other .pem file to stunnel.pem (if you don't already have a stunnel.pem file) or by typing "make stunnel.pem". I'd suggest using the same certificate .pem file for both stunnel and ipop3d so that you only need to upload one certificate to your e-mail program (unless of course you bought a "real" certificate from Geotrust or whatever).

Make sure you restart xinetd by typing "/etc/init.d/xinetd restart" so that your smtps server will start.

Also make sure you open port 465/tcp in your firewall settings.

Different e-mail clients behave in different ways, but typically your account settings will have a place to enter the server names and specify whether the outgoing server requires a secure connection and/or authentication. This may be under an "Advanced" tab. The port should be 465 instead of 25. Authentication is configured the same way but separately, and you should generally select to use the same account settings used to retrieve your mail.

If your e-mail client refuses to accept your certificate, then you may need to download it and install it as a trusted certificate. Go back to the stunnel.pem file you created, copy out the bottom part (between and including the BEGIN and END CERTIFICATE lines), and save just that part into a file named with a ".cer" extension. DO NOT COPY THE "PRIVATE KEY" SECTION. The procedure for installing the certificate varies by OS, but Windows users should be able to just double-click the ".cer" file and select to install the certificate into the Trusted Root Store.

Well, there it is. I've probably forgotten about 16 things, but we'll see how it goes.

-britt

A shotgun wedding is a case of wife or death.

Thanks for educating me on SMTP. I am using my ISP's smtp server to send and to tell you the truth, setting up smtp scares me because people might abuse the service. I don't want users to send out newsletters from huge mailinglists.

Great howto.

Cant see how people can abuse it by default smtp is open on ensim anyway to receive and send emails. All you're doing is giving your users a way to secure the connection.

Using stunnel in that way make your smtp server work as OPEN-RELAY.
It's security hole. BIG HOLE.

When you connect to SMTPS port, stunnel connects to SMTP port as LOCALHOST!!!! Stunnel doesn't use your IP! So ALL connections to smtp-server will be from LOCALHOST. So everyone can send email through your server.

Welcome spammers!

DO NOT USE STUNNEL ON WEB-HOSTING SERVERS!

O nice, sorry my mistake - surely you can bind it to external ip addie and then sendmail would take the relay rules....

Why use stunnel?

Just setup STARTTLS in sendmail and you will get your secure connection!
http://www.sendmail.org/~ca/email/starttls.html

You know, that makes a lot of sense, and I think I just verified that you're absolutely right. Shows how, just when you think you start to get the drift of web hosting, you can always learn something new.

Thanks for the heads-up!

-britt

Marriage is like long banquet with the dessert served first.

That is what I am talking about.

howabout either deleting this post or atleast change the top portion with a HUGE warning not to do this as it apperantly will open up a big security hole.

just my 2c.

Thats not correct at all! cPanel uses stunnel for many things as well as SMTP if you allow it. Our users connect thru port 993 and 995, 465 and we dont have any relays at all on our servers. It all depends on how you setup your server.

Can you post the appropriate setup steps? I've got stunnel securely forwarding port 465 to port 25, and have verified that my e-mail client can send mail as anyone to anyone else without authenticating on port 465. If I point it to port 25 then the relay rules kick in and my client gets an error.

I suppose you could remove "localhost" from the /etc/mail/access relay rules, but is this really a good solution, considering that many PHP/Perl scripts talk directly to SMTP as a secure alternative to running sendmail?

I plan to explore that TLS option as soon as I can get a few free minutes to rub together. If sendmail itself is handling incoming connections on port 465 then it will presumably do it right.

Is there some configurable communication between stunnel and sendmail that I'm missing?

-britt

Madam is someone for whom the belles toil.

An update: I've been doing some google searches and have encountered several threads where people are beginning to realize that stunnel shouldn't be used for SMTPS (at least to port 25), and many other threads where people are having problems getting sendmail's TLS to work with various mail clients.

It seems to boil down to: If you want ease of use and broad compatibility, at the risk of being an open relay to spammers, use stunnel. If you want security but lots of headaches from users, use TLS.

Stunnel does have a -T flag for transparent proxying, but it only works on a gateway machine or by forking a child process (sendmail -bs?). Worth investigating.

I've just found another article presenting a sendmail option for opening another SMTP port on something other than port 25, where sendmail would require authentication of any client connecting on that port. Stunnel would then forward to *that* port instead of 25. I'll post more after I've tried it. The relevant article is:

Google search article

-britt

Money is poor man's credit card.

Woo-Hoo! I think I found a simple solution that does not require changes to sendmail (yuk!).

Could someone else please try modifying the above instructions as follows. Change the server_args to:



That's minus capital T, minus lowercase L. This makes stunnel transparently wrap a newly executed "sendmail -bs" command (which runs the SMTP protocol on stdin/stdout) using a Linux library feature that fools sendmail into thinking that the incoming connection originates from the external host.

I have verified that, with this approach, I must authenticate or it will not relay my mail. Any comments?

-britt

All work and no play, will make you a manager.

So could you please post here YOUR xinetd/inetd conf for stunnel for SMTPS?

Are you talking about cPanel or Ensim? Im talking about cPanel in my msg which doesnt use Sendmail at all. It uses Exim.

I suppose I'd like to see whatever arguments cPanel is passing to stunnel in order to activate SMTPS on port 465. Not knowing where cPanel sets this up, one could telnet to port 465 in one window while running a "ps auxww | grep stunnel" in another window.

-britt

/Earth is 98% full. Please delete anyone you can.

Now it works. But IP is always 0.0.0.0.

Why would telnet even be active on the server?

Laugh. If you can't telnet to port 465 from inside or even outside the server then I'd argue that your SMTPS is truly secure.

-britt

They're coming to take me away, ho ho!

That is for Ensim (to count traffic & use domain's mqueue):


But IP is always 0.0.0.0. I don't know what to do.
But with this configuration I'm not affraid to use stunnel on our servers.

Will this work globally for all domains, or just site1?

Does anyone know how to get the IP to at least show as localhost (127.0.0.1) instead of 0.0.0.0???

I just found out that Hotmail & MSN ignore all incoming emails with an originating IP of 0.0.0.0. Not good. :-(

Anyone??

I added:
bind = eth0

To my xinetd.d/smtps file; so it would bind to ip of eth0. Since my server hostname has a valid SSL certificate, the main ip is all i need smtps on. Set all clients to connect to 'secure.server.com' port 465 and it works fine.

If you have an SSL Certificate (.crt) and key (.key) file for your servers hostname; to generate it to a .pem file do:

cat secure.server.com.key > /usr/share/ssl/certs/stunnel.pem
cat secure.server.com.crt >> /usr/share/ssl/certs/stunnel.pem

Does not work.

It should work; try telneting to your server ip like so:
# telnet 1.1.1.1 465
And see if you get an SMTP prompt. My xinetd.d/smtps file is pasted below; it works perfectly thus far.

My configuration is the same as yours.
But I get the error:
Jun 8 09:30:09 serv1 xinetd[12068]: Reading included configuration file: /etc/xinetd.d/wp_smtps [line=17]
Jun 8 09:30:09 serv1 xinetd[12068]: bad address [line=11]
Jun 8 09:30:09 serv1 xinetd[12068]: Error parsing attribute bind - DISABLING SERVICE [line=11]


Line 11 is "bind = eth0".

Seems to make no difference. My smtps file in /etc/xinetd.d is exact same as what you have. I am connecting to the hostname on port 465. After I made the bind = eth0 change I restarted xinetd, no change. I then restarted the server (shutdown -r now)...no change.

I think you might be looking at a different part of the email headers. The IP address of the host does show up (always has), the problem is the originating IP (my PC). If I use port forwarding in SSH it shows my IP as being 127.0.0.1, which hotmail etal, seem to accept as being valid. Using stunnel this way, it's always 0.0.0.0, which they consider invalid (Rightly so). I'd go back to port forwarding...but why have another program running all the time if I can just get stunnel working properly (and I'm sure all that is missing is some sort of option on the server_args line of smtps).

I'd LIKE to have it show 127.0.0.1 instead of my REAL IP address.

FYI here is a copy of my email headers when I send through smtps (with bind=eth0): (info changed to protect the innocent)

X-POP3-Rcpt: me@anotherserver.com
Received: from host.myserver.ca (ns1.myserver.ca [64.246.XX.XXX])
by host.anotherserver.com (8.11.6/8.11.6) with ESMTP id h58GpvY25300
for ; Sun, 8 Jun 2003 12:51:58 -0400
Received: from beavertail ([0.0.0.0])
(authenticated (0 bits))
by host.myserver.ca (8.11.6/8.11.6) with ESMTP id h58Gl0T01226
for ; Sun, 8 Jun 2003 12:47:00 -0400

*******************

beavertail is the name of my computer. Without SMTPS it would show my actual IP address instead of 0.0.0.0...THAT is the problem line. Are your emails showing up like this?? Have you tried sending an email to yourself at a hotmail account?? Just curious if this is only a problem I'm having??

Try change 'bind' to 'interface'.

Changed it..restarted xinetd....same result.

I'm sure it's something in this line:

server_args = -n smtp -T -l /usr/sbin/virthost /usr/sbin/sendmail -- sendmail -bs

Sendmail doesn't know the IP address of the client sending the mail...because of the tunnel. So I'm thinking it's sendmail that's assigning 0.0.0.0 (or the tunnel??).

well similar server args are applicable to stunnel as well:
-I host
IP of the outgoing interface is used as source for
remote connections. Use this option to bind a static
local IP address, instead.

-d [host:]port
daemon mode

Listen for connections on [host:]port. If no host
specified, defaults to all IP addresses for the local
host.

But this does not matter; why ? cause it is xinetd holding the port open not stunnel. On cpanel stunnel is run standalone, as with us we are running stunnel via xinetd so we must edit the xinetd options for the given service to change bind IP.

bind = x.x.x.x

IP of the interface you want it to use not the interface name.

He is right, binding to the IP in xinetd and also chaning the stunnel arguments to bind too the IP still says connection from 0.0.0.0

I know the man page says bind = ip and interface = if , but on my version they are cross compatible -- so it seems; and yes without a bind/interface directive i get default to 0.0.0.0.

Will it "break" anything in ensim if I upgrade stunnel??? I notice there is an stunnel.pyc file in opcenter.

My version of stunnel is 3.13 and I notice on stunnel.org they are up to version 4.04 (and 3.23 was released AFTER it...not sure what the difference is between the 2 branches).

Anyone? Would this solve the problem???

when I use interface = eth0 I get an error saying eth0 is an invalid IP address. When I do bind instead it won't let me connect to send mail. (in the man page is says bind and interface do the exact same thing).

I removed the -T from the server_args line...mail then has the proper header...showing the mail originating from my computer name at 127.0.0.1...but as you all know...that then is an open relay. There's got to be a way to get this working correctly....or maybe not??

Can you send me an email thru the stunnel to ameen[@]msba.com so i can look at your headers rxfn?

Thanks,
Ameen

Ok i see what you all mean now; e-mail over smtps is not received by msn and the likes. But my question is, is it the received from server that shows 0.0.0.0 or the X-ClientAdrr -- if thats the case then the problem is the server not properly tracking the client IP ?

Yes that is correct, the X-ClientAddr and the Recieved: from ..

I got a theory that im going to test later on, ill let you know if i can figure out a solution.

The below seems to work very well. I tested sending mail to MSN and it worked fine. Likewise can someone confirm that relaying protection is still enabled with this forward style setup (my tests showed it still required usr/pass to send mail).

Did you get this working? I had one successful test, but can't seem to get it working now. Strange! Did you remove the smtps file from /etc/xinetd.d and then restart xinetd? I'm guessing you just typed in the line at a prompt...or added it to your /etc/rc.d/rc.local file???

Just curious to know if this is still working for you...and if so...exactly what you did to get it working?

Thanks!

Yes removed smtps from xinetd, and restarted it. Then i made a service init script for 'smtps', below (place in /etc/init.d/smtps):


# chmod 755 /etc/init.d/smtps
# chkconfig --add smtps

Then start it up:
/etc/init.d/smtps start

And you should be good to go; works for me. Also for the xinetd version, removing the '-T' flag (transparent proxy) makes it work for sending to msn hotmail (from my tests - could be wrong) -- but still dont like the looks of the headers with it in xinetd and the connection seems much faster this way in sending e-mail by as much as 10-20 seconds.

However for abuse purposes the X-Client addr is still seen as your servers so essentialy anyone using secure SMTP in terms of your clients -- it will be much harder to track abuse.

Yes, you are correct! With digging in logs you would be able to know who sent whatever the offending email was...but it's more work for sure.

I only plan to use this myself anyway.

It's not working for me....I'm getting errors that alternate (in Outlook) between "Your outgoing (SMTP) server does not support secure connections" and "The operation timed out waiting for a response from the sending (SMTP) server"

And it's taking a long time to give me those errors. Hmmmm. Any ideas what I should check on that could be interfering??

COULD it be a new router I installed here at home earlier tonight??? Hmmmmm. I'll check into it.

I take that all back...while I was typing the message here I had incoming mail...my send finally went. I think I may have been trapped in some sort of "deny" list on the server for failed attempts. ??? We'll see if it holds up!

Thanks for your help!!! It's nice to not be 0.0.0.0 anymore!

smtps init file does not work, it connects but sendmail says commands were sent and outlook express the test client says server unexpectedly terminated the connection.


also removing the -T does not change anythng either



changing -d 0.0.0.0:smtps too
-d smtps

In
stunnel -s nobody -g nobody -p /usr/share/ssl/certs/stunnel.pem -d smtps -r $BIP:25 -n smtp

gets rid of the error but makes it so it is an open relay, i am assuming if it worked the way i left it, it would also be an open relay.

because with my change it is listneing on 0.0.0.0


tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN

It DOES work, but you have to wait a while if you have been having failed attempts. The server remembers you failing and has added you to it's deny list. I'm not sure of the exact length of time, but I'd give it an hour or so....after you setup the smtps script that rxfn provided, and remove your xinetd smtps info. You might even want to reboot the server just to be sure.

I just tried sending without authentication...and it fails (YAY). It doesn't fail "properly"...but at least it doesn't allow the mail to go through (it times out...as you described). Now that I have re-enabled authentication before SMTP in Outlook....I can't send again....for the reason I wrote in the last paragraph. I suspect within an hour I will be able to send again.

Give it a try ameen, but have patience...the server is remembering you!

Ok seems like a logical explanation, but why does it not just deny you the normal way with a relayign denied message?

Good question. I THINK it has to do with stunnel. During all this I know I read something about the server keeping a "deny list". stunnel would be reading that list and would see your IP address and not even forward you to SMTP so that would explain why there is no "relaying denied" message. It just shuts down the connection without saying why.

The end result is the same. If you really wanted to, I think you can disable that deny list...which should let the "Relaying denied" message get back to you. Personally...I think it's "safer" to just have the connection cut off. Anyone who's going to be using the smtps service on my box will know to make sure they have authentication turned on. Anyone else doesn't need the courtesy of a friendly error message.

Hmmm...booted up this morning and have failed sends on the 2 servers I tried this on. Not sure why it won't connect since nothing has changed since I logged off last night.

I did /etc/init.d/smtps status and both say they are running.

Outlook reports that my SMTP server does not support secure connections. Sometimes it just times out. Will tinker later on.

You sure you got "My server requires a secure connection (SSL)" enabled ?

This has been working flawlessly for me and my partner for a few days now.

Yep, I checked that, and it's set to use Port 465. Outlook IS trying to use a secure connection but the server (both of them..I applied this to 2 boxes) is saying it's not supported. Don't know what's going on with it.

I'm going to close outlook for a while and restart the server and see what happens.

It kept on failing so I did some digging and found this in /var/log/secure:



I made no changes and waited a bit longer and it is now working! (that's what the last 2 lines are about) I'll see if it holds now. Are you using Outlook?? (I'm using Outlook XP (2002), just wondering if maybe it's a bug in SSL with outlook???)

Yes i am using outlook for office XP.