HOW-TO: Posting to Gmail servers with non-SSL/TLS-aware MUAs

I'm a long-time user of the nmh mail user agent (MUA), <http://www.nongnu.org/nmh/>, and its predecessor MH before that.

It's an old MUA. It currently does not support submitting emails to mail servers that require SSL/TLS connections. Other venerable MUAs have the same problem. Fortunately, there is an OSS program that provides proxy capabilities that can negotiate the SSL/TLS part, and if necessary, the SMTP AUTH part if the MUA does not support it: DeleGate, <http://www.delegate.org/>.

DeleGate provides proxy capabilities for various Internet protocols (e.g. http, ftp), but for this article, all we care about is its SMTP capabilities.

Nice thing about DeleGate is you do not need root priviledges to run it. You can have it listen to local client requests on any port you choose and forward the request to remote server (which will be smtp.gmail.com in this article).

Best way to show how to use it is with an example:

The following starts delegated on the local system on port 25 (the standard SMTP port):

delegated -Plocalhost:20025 +=$HOME/delegate/conf/gmail.conf

This says to listen for client requests on port 20025 and to read additional configuration parameters from gmail.conf located under delagate/conf of your home directory (you can specify all parameters on command-line, but that gets kind of ugly). In my gmail.conf file, I have something like the following:

SERVER=smtp://smtp.gmail.com:587
STLS=fsv
AUTHORIZER=-list{localuser:MD5:964ba203464913531aa73b9f774b58f7}
MYAUTH=username@gmail.com:pass:smtp

SERVER specifies what remote server the proxy should connect to. In this case, we specify that is the SMTP server smtp.gmail.com on port 587 (TLS port).

STLS setting specifies that SSL/TLS should be used when connecting to remote server (smtp.gmail.com).

The AUTHORIZER parameter is not required, but if specified, client must (SASL) authenticate to the proxy. The username is "localuser" (change to whatever your want). This may be handy so other users on the local system cannot hijack your proxy server and post email thru your Gmail account. If you are the sole user of your system, client authentication may not be needed. Also, if your MUA does not support SASL, you should not set AUTHORIZER.

To determine if your MUA supports SASL, if your MUA provides the ability to specify an username and password when posting a message to a mail server, it probably supports SASL. If no such capability is provided, it probably does not.

The password listed for AUTHORIZER can be provided in plaintext, but DeleGate will show in its log the MD5 hash of it, which you can then insert into the configuration file. A plaintext version of AUTHORIZER is as follows:

AUTHORIZER=-list{localuser:password}

The MYAUTH specifies the username/password to use for authenticating to the remote server (smtp.gmail.com). This should be set to your gmail address and gmail password. Unfortunately, the password cannot be encrypted since DeleGate needs to send the password to the remote server. Therefore, make sure the configuration file is only readable by you and no one else. For Unix-based users, the chmod command can be used:

chmod 600 gmail.conf

For Windows users, right click on the file and select Properties. Then select the Security tab. Make sure you are the only user that has read access to the file.

With DeleGate running, just configure your MUA to post messages to localhost:2005 and you should be good to go.

NOTES:

If you cannot specify an alternate port number for posting messages, you will need to run DeleGate on port 25. If this is the case, you will need to have admin priviledges to start DeleGate. DeleGate does provide an option for it to drop priviledges to a separate user. See documentation for more details.

DeleGate supports multi-user access, but configuration becomes more complex. If you want to support multi-user access, see the documentation.

For nmh user, SASL is supported, so client-based connections can be restricted, especially if running DeleGate as a personal proxy. However, for nmh, if DeleGate is not running on port 25, the whom command at the "What Now?" will not work. The command will also not work if you enable SASL for client connections. For whom to work, nmh code modifications are required. I've committed changes into the nmh project so SASL support is available for the whom command. You'll need to check out the latest source and build if you need the feature.