Send an Email at a future date

There is the option of using a reminder on your calendar. You can tell a reminder to send and email as an alarm. The subject of the reminder will be the subject of the email concantenated with "Alarm: "+your subject+ the date and time of the reminder. The text in the Description will be in the body of the email.

This is a complex question, but putting together a simple system to protect your father-in-law's confidential information should not be that difficult.

Your first suggestion of using separate addresses for separate services probably won't make much of a difference. If someone (say, Mallory) is intercepting email in the network, then they can probably intercept any forwards you make; therefore all services are vulnerable to attack if you are using only one domain for all accounts. Mallory can simply search for any emails containing *@example.com in the To field and assume they're all being forwarded to the hidden address. Just knowing what the email address for a given account on a given service is gives Mallory an advantage, as that's what is authenticated to the service and that's what she will use to compromise it. Even creating email accounts off your domain simply increases the number of vulnerable nodes.

One way that you can considerably improve security is by enabling SSL for all protocols on the mail client used to fetch from the server. That way you eliminate at least one vulnerable hop where Mallory can intercept the plaintext of the emails. Also, contrary to what you've stated, it is very likely that sensitive services are using SSL to send you mail via SMTP, or that you can enable that somehow.

That's the most you can do on the network end. If the service refuses to use SSL-SMTP, it's probably not going to be very secure at all. There's a lot you can do to improve security on the local end, however. You should take standard precautions such as creating a firewall and disabling unused network services, as well as making sure that all your passwords are strong (16 characters or more). The LAMP server can be hardened with Grsecurity or a similar system to prevent buffer overflow attacks. Creating a virtual encrypted drive is of dubious utility, seeing as that unless you want your email to be undeliverable 90% of the time, the drive must be unlocked for you to receive it. Picture a physical mailbox with a padlock!

The local system presumably being used to retrieve email from the server using (SSL-)POP3 can be hardened as well if it's Linux. If you're serious about local security, the whole drive should be TrueCrypted (it's not actually on standby waiting for mail all the time) because applications leak an unbelievable amount of data throughout the whole system in caches and logs, rendering a solely encrypted local mailbox somewhat irrelevant.

So there's a little you can do for the network, a lot you can do for the server, and more you can do for the local system. Remember that the weakest part of your whole security system is the passwords.