Контроль за безопасностью e-mail информации

Если ПК пользователя контролируется противником, то медицина информационная безопасность здесь бессильна.

Да и не особенно ясно, чем это поможет сервис типа dropbox. Если email перехвачен (предполагается, что не зашифрован?), то злоумышленник может просто скачать файлы по ссылкам. Удалить с сервера – это тоже большой вопрос, даже службы поддержки у некоторых таких сервисов восстанавливают удалённые файлы по запросу пользователей в течение некоторого времени после удаления.
Это всё скорее для удобства передачи больших объёмов, чем для безопасности.

В строгом смысле противник всегда может получить информацию. Но если наложить определённые ограничения на него, что он будет и что не будет делать, то можно пытаться выиграть. Впрочем, вы никогда не узнаете, что именно он делает, поэтому вся такая защита может быть самоуспокоением и профанацией. К примеру, вместо писем можно посылать ссылки на картинки с текстом. Автоматический софт для слежки их не прочитает, нужны будут распознавалки. Если сервер ваш, он может показывать картинку только один раз, а потом удалять. Также ваш сервер может вести лог числа попыток доступа к страницам, что, может быть, позволит засечь слежку. Если противник не сохранял ссылки, он потеряет много информации, если постфактум обнаружит метод (потеряет по сравнению с тем, как если бы вы посылали текст, а не ссылки). Короче, стоит ли в конкретном случае играть в такие игры и полумеры — решать вам.

Посмотрите проект SMS-шифровальщика и протокол Axolotl
Это доработанный OTR для оффлайна. Я еще зимой сделал свой шифровальщик почты по прототипу, но уперся в одну проблему, пока не готов его представить.

Общий концепт таков: в каждое письмо вкладывается DH-ключ, используемый для обновления мастер-ключей переписки. После отправки письма мастер-ключ, с которого был выведен ключ шифрования, тот час заменяется своим хешем (идея от Циммермановского SilentCircle), так что при доступе к машине отправителя ничего из уже отправленного не получится расшифровать. При получении – то же, т.е. при захвате машины отправителя получится расшифровать только вновь приходящие письма, но не уже прочитанные. После получения каждого нового письма обновляется все по полученному в письме очередному DH-ключу (как в OTR).
Плюс автоматические отработки таймаутов: стирание старых ключей для задержавшихся писем. Плюс ручное стирание в эктстренных ситуациях.
Плюс еще отрицаемость (хотя, на мой взгляд, как раз под вопросом) в отношении долговременных ключей, удостоверяющих личности. Т.е. при захвате одной из машин невозможно доказать, что переписка велась с другим абонентом.

У меня есть мысль сделать сервера-пересыльщики (онлайн) на скрытых сервисах (недоверяемых) и организовать почту с адресами вида: онион_получателя@онион_его_сервера,
которые не требуя регистрации, просто будут пересылать все анонимно входящие письма по указанному в них адресу на другой сервер получателя. Получатель анонимно подключается к своему серверу, сообщает свой онион и говорит, что готов считать свою почту, затем рвет соединение. Сервер сам соединяется по указанному онион_получателя, отправляет ему накопленные для него письма и удалает их с хранилища.

Поверх этого всего – описанный выше протокол типа Axolotl.

Те, что были до заражения, прочитать не получится, допустим. Но после заражения все последующие письма сразу по приходу могут копироваться и складироваться зловредом. Пользователь не узнает, когда его заразили, поэтому в полном смысле задача топикстартера не решается — безопасность отправленной корреспонденции целиком в руках получателя.

Если ПК пользователя контролируется противником, то медицина информационная безопасность здесь бессильна.

Золотые слова.
После заражения это уже машина злоумышленника, а не получателя. В таком виде задача нерешаема по определению. Речь идет о полном блокировании доступа к переписке, проводимой перед заражением: возможности расшифровки перехваченного трафика. Т.е. – PFS. Отдельно – проблема отрицаемости: опять же после выполнения протокола нельзя показать, что он был выполнен. Но никак не во время его выполнения.

и ее можно в крайнем случае удалить с сервера.

Да ну?