The default configuration example file ( /etc/stunnel/nf-sample) only requires a few modifications: cd /etc/stunnel
#Setting up stunnel with psk software#
In fact, one of the major reasons why I decided to go ahead with the switch to Stunnel was knowing that the software had official vendor support. Red Hat Enterprise Linux already comes with Stunnel installed so this was a configuration and set-up problem, not an installation problem. This was a conservative plan because it afforded me with the option to jump back to the old configuration. The use of port 465 technically conflicts (see | this Wikipedia article) but in this case if it’s good enough for Gmail it’s good enough for me. I would set up Stunnel to listen on port 465, the "unofficial" SMTP over SSL port, and forward connections to the Sendmail daemon.
This includes the existing Secure SMTP arrangement which allows clients to connect on the standard SMTP port, port 25, and "upgrade" their connection to encrypted transport using STARTTLS. ProcedureĪs the only service affected by this issue is Secure SMTP I decided to leave my other existing arrangements in place. Switching to Stunnel would allow me to avoid at least one of these issues (the unwanted "may be forged" warnings). One of the reasons for running one’s own mail server is precisely to avoid this kind of problem, but in this case my ISP was thwarting my plans. One of the few Jazztel addresses which does resolve in both directions is These "may be forged" warnings are undesirable because they may increase the likelihood of false positives when outgoing messages hit spam filters elsewhere. In fact, Jazztel doesn’t even provide reverse lookups for some of their static IPs even their own nameserver’s IP address doesn’t reverse resolve.
Secondly, after switching to a new ISP, Jazztel, I discovered that the Received headers in all my outgoing mails had ugly "may be forged" warnings in them because the Jazztel’s administrators have a broken DNS set-up in which they don’t provide reverse look-up for clients with dynamic IPs. This is a necessary evil required by RFC 2821 the connecting mail client must send a host name or address along with it’s EHLO message. I later discovered not only one, but two drawbacks, to my decision to eschew Stunnel.įirstly, I observed information leakage across the boundaries of my internal LAN. Furthermore, it is not clear to me whether it is possible to offer both secure and insecure access at the same time (which would be useful, for example, if you wanted to allow users to access via either IMAP or IMAPS during the transition period). I chose not to use this method because I didn’t want to have to meddle too much with the server configuration (for example, configuring the stunnel-wrapped servers to automatically start up at the correct runlevels). You then set up your local mail client to communicate with SSL to the appropriate ports. For example, you fire up stunnel on the server and get it to listen to port 993 (the standard port for IMAPS), and it forwards incoming, encrypted connections to the real IMAP process running on the server (not encrypted).
Basically, the stunnel process serves as a wrapper for the insecure protocol. I didn’t actually try using but it seems like a viable option. I dismissed using Stunnel and instead decided to configure dedicated servers for Secure SMTP, POP3S and IMAPS. In May last year I decided to secure access to my SMTP, POP3 and IMAP services (see the | original article).
0 kommentar(er)
