By Weldon Whipple <weldon@whipple.org>
SMTP (Simple Mail Transfer Protocol) Authentication lets you send e-mail from your e-mail client through a remote mail server to other e-mail addresses on the Internet.
If your ISP's e-mail server supports SMTP authentication (SMTP AUTH), here is how to configure your Pine e-mail client to send your user name and password to the mail server.
The above will let pine authenticate to the outling mail server (for relaying).
If your copy of pine was compiled with SSL support, and if the outgoing mail server also supports STARTTLS (in addition to SMTP AUTH), you can encrypt your user namd and password as it is sent to the mail server by changing smtp-server to:
mail.whipple.org/tls/user=weldon
(inserting the literal string "/tls" after the name of the mail server. If your server supports SSL but not TLS, you can use the string "/ssl" instead.)
If the mail server is also your incoming mail server, you can have pine get remote mail as follows:
If your incoming mail server supports STARTTLS, you can tell pine to use it by changing the inbox-path to:
{mail.whipple.org/tls/user=weldon}inbox
(inserting the literal string "/tls" after the name of the incoming mail server. If your server supports SSL but not TLS, you can use the string "/ssl" instead.)
When you start Pine, it will prompt you for the user name and password you use on the e-mail server.
The first time you use STARTTLS after configuring pine, it will probably display something like the following:
There was a failure validating the SSL/TLS certificate for the server
mail.whipple.org
The reason for the failure was
unable to get local issuer certificate (details)
We have not verified the identity of your server. If you ignore this certificate validation
problem and continue, you could end up connecting to an imposter server.
If the certificate validation failure was expected and permanent you may avoid seeing this
warning message in the future by adding the option
/novalidate-cert
to the name of the folder you attempted to access.
To avoid the above message, find the SSL/TLS public certificate of the Certificate Authority (CA) that signed mail.technoids.org's certificate. Store a copy of that certificate where pine can read it (in the directory /etc/ssl/certs on my machine).
If the CA certificate is stored at /etc/ssl/certs/Equifax_Secure_CA.pem (for example), you will need to issue the following commands as root. (If your shell isn't bash or Bourne shell-like, issue the "bash" command before the following.)
# cd /etc/mail/certs # C=Equifax_Secure_CA.pem # ln -s $C `openssl x509 -noout -hash < $C`.0
The above will create a file named xxxxxxxx.0 (where xxxxxxxx represents 8 hexadecimal digits), which is a symbolic link to the file Equifax_Secure_CA.pem. (In my case, the symbolic link file was named /etc/ssl/certs/594f1775.0)
When pine receives the server's certificate (during the SSL handshake) it runs it through a one-way cryptographic hash whose output is an 8-digit hexadecimal number. Then it looks for a file by that name (with .0 added at the end) and attempts to verify the server's certificate.
Sometimes pine is compiled to look for certificates in places other than the directory named /etc/ssl/certs. One way to identify where pine expects to find certificates is with the truss utility (available on many Unix platforms). The -o option of truss will direct output to a file (so that you can browse it after you exit pine). You could invoke truss as follows:
% truss -o truss.out pine
After reading and sending mail in pine, exit pine and view the file truss.out. Search for the string "certs". You will probably see one or more lines that read:
stat("/etc/ssl/certs/594f1775.0",0xbfbfce28) ERR#2 'No such file or directory'
(The example above shows that my pine expects to find certificates in /etc/ssl/certs. I saw the message before I stored the Equifax CA cert and the hash symbolic link in /etc/ssl/certs.)