Secure Mail Services at JTAN

In order to improve password security both for JTAN's network and for individual popmail customers, JTAN has implemented various Secure Mail protocols. We highly encourage you to use these protocols rather than inferior plaintext systems like direct POP or IMAP. Note although our main servers offer in-secure protocols, our shell servers exclusively serve the secure protocols. If you require insecure plaintext POP or IMAP, you are restricted to reading your mail from pop.jtan.com or imap.jtan.com.

For sending mail, we also support secure protocols. If you can't use a local server to send your mail, consider using one of our secure SMTP alternatives.

What is a Secure Mail Protocol?

Any scheme, either for sending or receiving email, that does one or both of the following is a secure mail service

Protects your password from snooping
Protects your message text from snooping

Using secure mail protocols is good to do. It means that your email password is less able to be electronically "stolen" and used by someone else. Also, the contents of your mail stays private.

Many protocols we describe below do one or both of these. However, ordinary POP and IMAP do neither of these. This is a dangerous problem. If you read mail with POP or IMAP, unscrupulous people on the net can snoop on both your email password and the contents of your message. This is not theoretical paranoia -- we see it happen all the time. That's why we recommend secure mail Protocols.

Security is also important when sending mail. It is convenient for uses with operating systems that do not have built in mail transport services (e.g. MS Windows) to use remote SMTP servers. JTAN maintains SMTP servers for this purpose, but it is important that these servers are only used by JTAN customers. If they were left unguarded, spammers and other evil doers would choke them with spam and other abusive stuff. For everyone's benefit, outgoing mail servers must be secured against unauthorized use.

Finally, a very important point that should be made with regard to many of these protocols that encrypt your mail, like POPS and SMTPS. The encryption used only protects your mail as it travels the first hop between your mail client (e.g. Outlook) and our mail server. Although protecting that first hop may be useful, as in the case of a wireless link or if PLAIN SMTP/Auth is used, still you should keep in mind that the mail server, there is no encryption. The only way to get full protection for your mail from your computer to your recipient's computer is to encrypt the message body itself. This must be done with a tool like PGP/GnuPG or with the S/MIME feature built into many mailers.

Why should I switch to Secure mail Protocols?

Secure protocols are a way to increase network and individual electronic mail security. Although JTAN makes every effort to keep our network secure and free of hacking devices like password sniffers, it is possible that your password might be detected as you connect to the popmail server. This risk increases if you read your email from other Internet service providers, wireless links, college campuses and the like.

Electronic Mail Security
With your popmail password, some network miscreant can read your electronic mail whenever they feel like it. Even without your password, if your mail is not encrypted, it can be read in transit by a snooper.
Account Security
If your conventional popmail password is identical to your network and/or members area and/or shell password, and if your password is sniffed via electronic mail transfers, someone could use your password to access your shell account and steal your service (costing your money), send illegal messages, or practice some other illegal activity like coordinating terrorist plots or crashing Amazon.com's web site (resulting in a personal visit by some tall men with sunglasses and grey suits). Use of a secure protocol to protect your password allows the popmail password to always be transmitted over the network in a secure, encrypted form, lessening the likelihood of compromise.
Security from Abuse
The major threat to outgoing mail is forgery and spam. Nobody wants a spammer to use their domain to relay mail. Can you imagine to problem you would have if some abusive email was sent to 1000's of people using your return address?

We *strongly* recommend that people begin using secure mail protocols immediately.

What if my mailer dosen't support Secure Protocols

Most modern mailers support secure protocols. Our first suggestion, if your mailer doesn't support security, is to get a new mailer! However, sometimes people face actual workplace/school/accessibility restrictions in what they can use.

If you use SSH you may use an ordinary POP mailer and get both password security and have your messages themselves securely encrypted as the cross the network. With SSH, the ordinary POP protocol is made secure by means of port tunneling. See the SSH resources for more information.

Another alternative you can try if your mailer isn't capable of secure protocols is to use the secure webmail system. If your browser is capable of SSL encryption, our webmail system is a painless way to secure your email even when you aren't at home at your PC.

What Secure Protocols does JTAN Support?

As an alternative to POP and IMAP, we support several secure protocols for reading mail:

POPS
IMAPS
APOP
Secure Webmail

We also support secure protocols for sending mail:

POP-Auth
SMTP/Auth
STARTTLS

Note that STARTTLS is is an SMTP extension for swtiching plaintext SMTP to a SSL tunnel directly on port 25 (or 587), as compared to the obsolete SMTPS which uses a dedicated SSL port (465) and standard SMTP protocol. JTAN does not currently support SMTPS on port 465.

The following sections describe the protocols we support in detail.

Certificates used in SSL Security

When you first access a mail service secured by SSL, you may be warned that the certificate is not "trusted". This is perfectly normal. Your system is asking for you to "introduce" the new site to it. You can then study the credentials offered and make your decision about the authenticity of the site. The creditals used on the internet are called a "certificate". Normally, your browser or mailer will "remember" the certificate (or let you load it permanently) and you will not have any future problem.

Alternatively, you could go to our Secure CA Page and get JTAN's Root Certificate. Here's an example of the error you might see when connecting to pop.jtan.com with SSL for the first time. :

Site authenticity is established by a certificate issued by a Certificate Authority (CA). JTAN Serves as its own CA and issues JTAN signed certificates identifying our servers and services, as well as authenticating our customers with certs and key signatures. Our root JTAN CA key (as well as the certs for smtp.jtan.com and pop.jtan.com) can be downloaded and verified from a secure page on our CA site. and our https://www.jtan.com/pgp/

For your convenience, here are our most important certs. Try clicking on the DER or PEM links. One of them will probably load the cert into your browser automagically. That may be enough to get your mailer to work with it. Otherwise, try downloading them and installing manually.

Incoming Mail Server pop.jtan.com: DER, PEM
Outgoing Mail Server smtp.jtan.com: DER, PEM
Certificate Authority: DER, PEM

Depending on your OS and software, you might need to manually install the JTAN root CA key and the JTAN smtp and pop keys into your OS and mail client keystore (Under WinXP look under Internet Options...)

We welcome any questions about the authenticity of our certificates. Unlike large companies like Verisign that assume everone will trust them by default, we at JTAN are happy to let you make your own mind up. We know you will see the good credentials we provide and probably decide to trust us.

Secure Protocols for Receiving Mail

POPS (POP over SSL)

POPS is a good choice of a secure protocol for receiving mail if you want to download your mail to your PC. We feel that is the most secure choice. If security is your primary concern, use POPS. Microsoft Outlook supports POPS. If you are using outlook now with POP, consider switching to POPS. It's simple to do.

However, POPS is not a good choice if you want to freely switch between our new web based email system (that uses IMAP folders) and your PC based mailer. If you want to do this (at some sacrifice in security) we recommend using IMAPS rather than POPS. The reason for this is that IMAP/IMAPS folders are extensions of the POP/POPS inbox, so once you look at your mail with IMAP using the web system and move it to another folder, it will become invisible to POP/POPS. This is particularly problematic if you like to use folders to sort your mail and you tend to leave your mail on our servers for perusal from various locations.

POPS works well for accessing mail from an inbox on a shell machine, but again, if you want to access mail folders on your shell account, only IMAPS can do that.

Note that if you receive an error about an untrusted certificate, refer to our discussion above about how to proceed.

Configuring your PC to use POPS
If you have an existing mail account that uses POP, it's almost trivial to switch it to use POPS. Just go to "Accounts->Properties" or whatever the menu is that allows you to configure your incoming mail server and make sure that SSL is required and port 995 is used.

That's all there is to it. Everything should still work as it did before, but now you get much better password and message security.
Note: You may get an error from the SSL certificate offered by the POP server. This certificate is signed by JTAN. You need to tell your mail client to accept the cert. The way to do this for Microsoft Outlook is to fire up the MSIE web browser and visit the URL https://pop.jtan.com:995 and accept the certificate.

IMAPS (IMAP over SSL)

IMAPS is the best choice of a secure protocol for receiving mail if you want to freely switch between our new web based email system (that uses IMAP folders) and your PC based mailer, particularly if you tend to leave your mail on our servers for perusal from various locations.

It also works well if you want to access mail folders on your shell account. Our shell machines only support IMAPS -- not IMAP.

However, there are some downsides to IMAP/IMAPS you should be aware of. Storing your mail folders on a public server has a number of security weaknesses that don't occcur when you download your mail to your PC. For one, backup is not guaranteed. Email can be among the most valueable files that you have and they deserve to be backed up securely. We recommend writing email to CD-ROM periodically and storing it in a fireproof safe (JTAN can do this for you if you ask). Another problem with storing your email on a public server is that it may be vulnerable to snooping by other users on that server. With POP/POPS and other protocols that download your mail off the server immediately, there is far less chance of snooping. Finally, it is important to mention that IMAP has had a history of security weaknesses leading to shell account compromise. This is not so much an issue with regard to the IMAP server on pop.jtan.com, but if you elect to use IMAPS with your shell account mail folders, you may be making your shell vulnerable to attack through IMAP.

Note that if you receive an error about an untrusted certificate when using a SSL connection for the first time, refer to our discussion above about how to proceed.

Configuring your PC to use IMAPS
When you set up your email account with your PC email program (e.g. Outlook) specifiy that your incoming mail server uses IMAP

Then go to "Accounts->Properties" or whatever the menu is that allows you to configure your incoming mail server and make sure that SSL is required and port 993 is used.

That's all there is to it. On pop.jtan.com, IMAP uses the same password as POP, however, IMAP requires the mailbox ID, not the username to be specified when logging in. POP will accept either.
Note: You may get an error from the SSL certificate offered by the POP server. This certificate is signed by JTAN. You need to tell your mail client to accept the cert. The way to do this for Microsoft Outlook is to fire up the MSIE web browser and visit the URL https://pop.jtan.com:993 and accept the certificate.

APOP (Authenticated POP)

APOP is basically POP, but your password is encrypted before it travels over the network. That's good. It prevents your popmail password from travelling bare naked over the network. Instead it uses it to encrypt a session password which can be checked against one encrypted by the popmail server also using your password. This means that a hacker using a network sniffer can only capture your session password, which cannot be used on a second session to read your electronic mail or do any other damage.

However, there is still a downside. The text of your messages are not protected. Therefore, use APOP when you can't use a fully encrypting protocol, like POPS or IMAPS. For more detailed information on the technical workings of APOP, look at the POP3 RFC1939.

At JTAN, the APOP protocol is not supported on the main POP server (pop.jtan.com). Sorry. Nor is it supported on new shell machines. However, on some of the old of the shell machines (e.g. callisto), APOP is supported. Assuming you have mail sent to a shell machine that supports APOP, configuring APOP at JTAN is easy. Configure your mailer to use APOP as described below. On shell machines, APOP passwords must be set manually. If you don't have a working APOP password and need it set manually, go to the Members Only area and log in. Using the "Service: Passwords" link, request an APOP password. Make sure you let us know what shell account and on what machine.

Configuring your PC to use APOP
Many PC mail programs support APOP. Eudora, Netscape, and Outlook for Mac do, however Outlook and Outlook Express for Windoze don't. Ask Bill why.
If you are lucky enough to have a mailer other than Outlook, Setup is simple on most systems. You will need to enter your APOP password and select a checkbox to use APOP. That's about it. In Eudora for look for "Authentication Style". That must be set to APOP, not "passwords".

Secure Webmail (Webmail over SSL)

Simplest of all the secure mail protocols is JTAN secure webmail.

Click here for JTAN WebMail

Using SSL based encryption in a web browser, you can read and answer your email through a SSL encrypted tunnel. That means that the data sent to and from your PC as it travels to the webmail server is fully encrypted and thereby protected from snooping. Effectively, secure webmail achieves security comparable to IMAPS. The same folders are used as IMAPS, and all communication is encrypted with SSL, just like IMAPS. The only difference is that the email client "runs" on our server rather than on your PC. Choose Secure webmail as a good counterpart to IMAPS

The disadvantages of secure webmail, like IMAPS, is that your mail remains on the server. This weakness can be counteracted by periodically downloading or archiving your mail. You might consider the JTAN CD-R recording service for periodic archiving. We can ship you the disk or hold it here in our safe.

Configuring your PC to use Secure Webmail
There's nothing to do. Simply go to the webmail link with your browser:

https://www.jtan.com/mail
and log in with your mailbox ID and the associated password. Make sure you don't forget the "s" at the end of https. We permit our webmail system to be used with ordinary http for those people that need access from browsers that don;t support SSL, but if you have an SSL capable browser, like Netscape or Opera, be sure to use the https URL.

Secure Protocols for Sending Mail

POP-Auth (POP then SMTP) and Other Related Systems

POP-Auth or POPB4SMTP is a technique developed to support the default configuration of most email programs (like Outlook Express). The way it works is that the user must first check their mail with POP, and then within some period of time afterward, they are allowed to send mail with SMTP from the same IP address.

Although this system was first invented only to use POP, POPB4SMTP does not use encryption but it does a reasonable job of authentication. Most users who set up Microsoft Outlook will end up using this protocol to send mail. You should consider some of the other methods, like SMTP/Auth, if checking your mail prior to receiving is problematic.

It may seem counter-intuitive, but POP-Auth not only works with POP. If you switch to IMAP or even POPS, POP-Auth will still work. On the other hand, POP-Auth will only work if you pick up your mail at pop.jtan.com or alias thereof. If you mail is forwarded to your shell, hotmail, or elsewhere, POP-Auth will not work.

However, JTAN has extended the POPB4SMTP technique beyond strict mail protocols. If you use a JTAN dialup, or log into the JTAN members area, you will also authenticate yourself to our SMTP server. The only thing we haven't quite wired into this is a shell login, but we are working on it.

Configuring your PC to use POP-Auth
If you use pop.jtan.com as a pop server, and smtp.jtan.com as an SMTP server, you automatically are set up for POP-Auth. Just be sure to check your mail with POP before sending with SMTP. On MS Outlook, this happens automatically. Enjoy.

SMTP/Auth (SMTP Server Authentication)

SMTP/Auth an internet standard for SMTP sender authentication. It can use a variety of techniques for transmitting your password to the outgoing mail server. It should not be confused with SMTP/TLS (STARTTLS) which is a whole different beast, but is typically used in conjunction with SMTP/Auth.

JTAN operates a fully functional SMTP/AUTH server. The machine, "smtp.jtan.com" uses the SMTP/AUTH protocol to authenticate users that want to send mail. It can also switch the session into encrypted SSL mode after a command called "STARTTLS" which most mailers these days can issue. Although encrypted password schemes exist for SMTP/Auth, like CRAM-MD5, the world's favorite mailer, Outlook, only supports the plaintext LOGIN method. Good news: our server will also accept PLAIN or LOGIN methods. This table lists mailer compatibility with SMTP/AUTH methods.

Since some mailers support only the plaintext "PLAIN" or "LOGIN" authentication methods. If you want to use SMTP/Auth with these mailers, please configure to use SSL encryption, or you will be sending your LOGIN password in the clear for all to steal. If you have a mailer (like Eudora) that supports CRAM-MD5, you can use that safely without SSL, but turning on SSL can protect the text of your message too.

Configuring your PC to use SMTP/Auth with SSL
First of all, if you want to use SMTP/Auth, you need a SMTP Auth password configured with JTAN. For the last few months we have been setting SMTP/Auth passwords automatically to match POP passwords. So when you get a new POP mailbox or change the password on an existing one, the SMTP/Auth password is set to be the same. Folks that have older POP mailboxes may pre-date when we started to set up matching SMTP/Auth passwords. If your POP password is old, you can change it (and thereby set the SMTP/Auth password to the same thing) or you can request a new password just for SMTP/Auth from the Members page (Service: Passwords). Keep in mind that in many mail clients (e.g Eudora) the SMTP password has to be the same as the POP password.
Configure your PC using smtp.jtan.com as an outgoing server On MS Outlook, you will need to check the box that indicates authentication is required for outgoing mail, and that SSL is required for outgoing mail. Use port 25 (or 587 if your ISP blocks port 25) for the outgoing mail port.

Note: If you use SSL, you may get an error from the SSL certificate offered by the SMTP server. This certificate is signed by JTAN. You need to tell your mail client to accept the cert or to manually install it. See our discussion on certs above.
We also understand that there may be some issue with Norton Antivirus. If NAV's option to Scan Outbound E-mail is enabled, the secure connection never gets set up. STARTTLS will work fine with that option turned off.

Setting up SMTP/Auth with Unix Sendmail

Most ISP's will give you detailed instructions for setting up SMTP/Auth with Microsoft Outlook, but if you say you have a Linux box, forget about it. Fortunately, if you use a client mailer, you can usually follow your nose through the menus, entering smtp.jtan.com for the outgoing server.

Some linux/bsd users prefer to relay through a locally running sendmail daemon, giving them the advantage of local queueing and geek points. This is accomplished with a simple

 DSsmtp.jtan.com

line in sendmail.cf. Of course, you will get "relaying denied" errors unless you arrage for some kind of Auth. You can rely on POPB4SMTP by polling the POP server, or you can set up client auth as described here

Using Port 587 With Unix Sendmail

Most client mailers also have a menu config field for the SMTP server port, so if your ISP blocks port 25, just enter 587 into the field. But if you use sendmail locally with the smart_host feature, it's a little tricky to configure the alternative port if smtp.jtan.com can't be reached on port 25.

The workaround is to create a special mailer that you specify to be used for the smarthost.

Edit your /etc/mail/sendmail.cf and search for the string "Msmtp". You should find something that looks like:
	
Msmtp,          P=[IPC], F=mDFMuX, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, 
                T=DNS/RFC822/SMTP, 
                A=TCP $h 
Copy and paste those three lines and modify the pasted lines so the whole thing looks like:
	
Msmtp,          P=[IPC], F=mDFMuX, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, 
                T=DNS/RFC822/SMTP, 
                A=TCP $h 
Msubmission,    P=[IPC], F=mDFMuX, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, 
                T=DNS/RFC822/SMTP, 
                A=TCP $h 587 
Save the file, then edit the /etc/mail/mailertable file and add the line:
domain.com      submission:[domain.com]	
where domain.com is the smarthost. Next, restart sendmail by typing "service sendmail restart" on RedHat or /etc/init.d/sendmail restart on SuSE or Gentoo.
Now when you send to domain.com it will connect to port 587.

STARTTLS (SMTP with SSL, usually with SMTP/Auth)

SMTP/TLS is an extended SMTP protocol that integrates encryption with SMTP on port 25 (or 587). This should not be confused with SMTPS or SMTP/SSL that is normal SMTP over a SSL tunnel. Currently JTAN does not support SMTPS on port 465; we only support SMTP/TLS on the normal port 25. SMTP/TLS uses SSL to encrypt everything sent to an SMTP server. There's value in using it in conjunction with SMTP/Auth as described above. The LOGIN or PLAIN authentication methods need protection. When SSL is used in conjuction with SMTP/Auth, it represents the analogous counterpart to POPS. Without SMTP/Auth, some users still might want SMTP/TLS to give them first hop encryption for their outgoing mail, but keep in mind that beyond our server, the mail will be plaintext again.

The JTAN server "smtp.jtan.com" listens on port 25 and 587 without SSL, and will switch to SSL mode with STARTTLS. It provides the LOGIN, PLAIN, and CRAM-MD5 methods of authentication in either mode. However, if you are using LOGIN or PLAIN (e.g. Outlook) please enable SSL.

Configuring your PC to use SMTP/TLS with SMTP/Auth
See the setup for SMTP/Auth. If you aren't using SMTP/Auth, but rather POPB4SMTP, there really is no need to enable SSL -- although you certainly still can if you want "first mile" security on your outgoing mail.