Secure email transport with instant arrival notification

Underlined text denotes things you MUST adopt to your situation. Italic text denotes filenames - you may change them, if you change all references to them accordingly.

Required situation

A mail server (irz301). You must be able to put arbitrary commands in your ~/.forward.
A login server (irz601; login ob6). The mail and login servers are assumed to have a secure connection between them an MUST be in the same NIS-domain. If you can log directly into the mail server, then the system becomes a bit simpler.
A permanent connection between the client computer (at home; login ossi) and the login-server. This connection may be insecure. A dial-in will probably serve the purpose as well.

Goals

Make the connection between client and mail-server secure.
Fetch the mail immediately from the mail server when it arrives and get instant notification.

Implementation

tunneld.c is the main client side component of the system. Compile it with "gcc -O2 -o tunneld tunneld.c" and save it as /urs/local/sbin/tunneld.

As this program needs to run all time, we want it started by an init-script.
The one for Debian Linux should be saved as /etc/init.d/tunnel and activated by running "update-rc.d tunnel defaults"; additionally it requires this program for "one-shot" invocation.
The one for SuSE Linux (outdated version!) should be saved as /sbin/init.d/tunnel and activated by creating the required symlinks by hand.
Make sure to change all parameters according to your setup. The user specified in the init script (root for the old SuSE script) needs a password-less RSA (or DSA) authentication key for the login server.

You need an /etc/fetchmailrc (permissions 600!). If your mail server does not support imap, then use pop3 (the pop3 port is 110; map it to 50110 or something else).
poll irz301 via localhost proto imap port 50143 user ob6 pass !$%#$* is ossi fetchall expunge 0

tunnelk.c is for the server side and has to be compiled and stored on the login server, best as ~/bin/tunnelk. This implementation is specific to Solaris (the proc-filesystem handling is done in a non-portable way), but can be easily adopted to any other *nix with proc-fs.

Finally we need a proper ~/.forward on the mail server. The "/bin/rsh mail-server" and the "; exit 0" can be omited, if you can log directly into the mail server. Note, that this syntax works only with MTAs fully compatible to sendmail.
ob6, "| /bin/rsh irz601 /usr/users/mat98/ob6/bin/tunnelk; exit 0"

If you want to send email via a secure channel, too, then you need to tell your MTA to use localhost:50025 instead of mail-server:25 for outgoing mail. The relevant part of the configuration file for Exim looks like this (consult your MTA's manual, if you use another one). Note, that this requires an already running ssh tunnel at port 50025, best created with the above tunneld.


### Transport config section ###

remote_smtp:

  driver = smtp

  port = 50025

  hosts = 127.0.0.1

  hosts_override = true

  allow_localhost = true

If you want instant mail notification, then you need an MTA or MDA, which makes comsat notifications (i think all do; procmail does for sure). Note, that this is independent from the above system and could be installed directly on a mail server acting simultaneously as a login server.

Compile comsatd.c and save it as /usr/local/sbin/comsatd. It directs global comsat notifications to the affected users by executing their ~/.mailinfo, what allows individual notification.

To activate the whole thing you must insert this line into your /etc/inetd.conf:
comsat dgram udp wait root /usr/sbin/tcpd /usr/local/sbin/comsatd

You may put mailinfo in /usr/local/bin/, so every user can symlink it from his home directory (you need tones for it). These are the /etc/mailinforc and ~/.mailinforc i use.

Feedback to ossi@kde.org