Проверка состояния шифрования электронной почты.

Question

Недавно я работал с gpg-mailgate и работаю почти так, как хочу.

Мое последнее маленькое препятствие - как надежно проверить, не входит ли входящее письмо в систему pgp. Вот варианты, которые я вижу.

1. Добавить фильтр содержимого в Postfix, который использует почту :: gpg.is_encrypted и если сообщение возвращается да, то отправить непосредственно. Если нет, то я могу отправить его в gpg-mailgate, чтобы справиться с этим.

2. Вызвать небольшой скрипт perl из gpg-mailgate и еще раз вызвать Mail :: GPG.is_encrypted и перейти оттуда. Я видел несколько примеров вызова perl изнутри python, и я предпочел бы сделать это таким образом.

3. Я ненадежно тест для шифрования с помощью поиска ** НАЧАТЬ PGP MESSAGE **, но это никоим образом не является отличным решением.

Это все, что я придумал. Поскольку в оболочке gnupg python нет ничего, чтобы проверить это, я думаю, что мне придется искать что-то другое.

Что меня беспокоит в первых двух сценариях - это производительность. Я стараюсь держаться как можно больше ненужной нагрузки.

Я открыт для всех предложений, спасибо.

Answer 1

GPG или другое сообщение OpenPGP, отправленное по электронной почте, должно быть отправлено в формате RFC 2015. Это очень легко обнаружить, надежно и эффективно.

В принципе, вы просто проверить, что заголовки RFC822 имеют Content-Type который выглядит следующим образом:

Content-Type: multipart/encrypted; boundary=whatever; protocol="application/pgp-encrypted" 

Идеальный способ сделать это с email и mime модулей в Python, или ваши любимые эквиваленты от CPAN в perl, но вы, вероятно, можете сделать это быстрее с хорошо продуманным регулярным выражением. (Если вы решите пойти этим путем, найдите предварительно проверенные регулярные выражения для заголовков RFC822 и постройте их, потому что вы получите части RFC822 неправильно в первые 20 раз, когда вы это делаете. Продолжающиеся линии, необязательные пробелы по всему месту, переменная порядок компонентов, нечувствительность к регистру и т.д.)

---

Но что, если кто-то просто послал сырое сообщение OpenPGP как текст по электронной почте? По крайней мере, некоторые MUA обнаружат это и обрабатывают его так же, как и соответствующее сообщение OpenPGP. Как они это делают? В принципе, способ, который вы предложили: путем сканирования тела.

Первой частью этого является получение самого тела. Если они просто используют почтовую программу с обычным текстом или причудливую почтовую программу, которая не является глупой, это будет просто сообщение о не-multipart RFC 822, которое легко. Но если вы хотите обрабатывать почтовые программы, которым нравится HTML-код всего, вам нужно найти текстовую/обычную часть, прежде чем вы сможете даже сканировать. Делать это надежно или быстро не так уж плохо, но и то, и другое?

Теперь, как вы узнаете, является ли тело сообщения OpenPGP? RFC 4880 описывает формат. В частности, посмотрите раздел 6.2 о формате брони ASCII.

Но вкратце: Посмотрите на строку заголовка броней, -----BEGIN PGP MESSAGE-----, затем ноль или более RFC-822, затем пустую строку, то блок данных, и все базовые 64 символов и пробелов, то броня хвост линии -----END PGP MESSAGE----- , Вы можете разрешить произвольные строки до и после заголовка и хвоста для обеспечения безопасности (это не делает сканирование труднее). Все, что соответствует этому, очень, скорее всего, будет сообщением OpenPGP; все, что вряд ли возможно использовать с GPG.

Это все равно не будет обрабатывать все возможные случаи, которые могут использовать люди. Если кто-то отправляет многостраничное сообщение OpenPGP, разбитое на два письма, перетаскивает и отбрасывает сообщение OpenPGP таким образом, чтобы их почтовая программа превращала его в вложение вместо тела, вставляя двоичное сообщение OpenPGP вместо ASCII-бронированного, ...

Но я подозреваю, что обрабатываю только правильный OpenPGP MIME, а необработанный доспех OpenSCGP ASCII в теле открытого текста должен быть достаточным.