Постфикс + Голубятня с бэкендом MySQL: md5-хешированные пароли и автор CRAM-MD5

Мой вопрос

Каковы риски переключения от MD5 до паролей CRAM-MD5 в базе данных, особенно рассматривая следующее, и как приблизиться к этому для существующей установки (если я знаю незашифрованные пароли)?

С (переключающийся на) CRAM-MD5,

1. для шифрования/проверки PostfixAdmin должен вернуться к внешнему инструменту (doveadm pw) на пользовательском создании и для изменений пароля, таким образом, пароль в виде открытого текста по крайней мере вскоре появился бы в процессе list1
2. Я возможно представляю новую зависимость (тот же самый инструмент)
3. Сомнительный, могут ли другой (третья сторона) инструменты иметь дело с этим

Объект 2 не мог бы быть грандиозным предприятием, поскольку я не планирую заменить Голубятню (и даже если, это хорошо зарегистрировало миграционные пути, по моему скромному мнению). Объект 3 еще не является грандиозным предприятием (поскольку я не знаю о таких инструментах). Негласно существует также SASL, который, IIRC, вносит свой вклад его задания с помощью Голубятни снова (например. smtpd_sasl_type=dovecot в Постфиксной конфигурации). Но это могло бы быть, я пропустил что-то – быть этим больше проблемы или другая опция.

Какие-либо подсказки? Что Вы рекомендовали бы (кроме совершенно другой установки)?

TL; DR (фон)

Я посреди установки нового почтового сервера, с помощью Голубятни, Постфикса, PostfixAdmin, Решета, некоторых дополнительных компонентов – все соединенные с MySQL как бэкенд (losely после этого немецкого учебного руководства). Я имею все и работающий до сих пор, но затем заметил, что это предлагает только ПЛОСКОСТЬ и ВХОД В СИСТЕМУ для аутентификации IMAP. Не грандиозное предприятие для локальных соединений (например, веб-почтовая программа Roundcube на той же машине) и другие "зашифрованные соединения" (HTTPS/IMAPS/POP3S/SMTPS) – но я боюсь, что некоторые пользователи будут использовать незашифрованные соединения вместо этого, которые я не хочу отключать полностью (существуют ситуации, где это могло бы быть необходимо).

Таким образом, я включил CRAM-MD5 и ОБЗОРУ-MD5 в Голубятне – который, конечно, не мог работать: PostfixAdmin хранит пароли в базе данных с помощью ее внутренней процедуры MD5, и таким образом, Голубятня не может соответствовать им (см. мой ответ здесь для деталей). Который в основном оставляет меня с 3 опциями, одним из них даже быть таким:

• отъезд его как есть (с рисками, описанными выше)
• переключаясь на незашифрованные пароли в базе данных (ай, нет, не сделает),
• переключение на пароли CRAM-MD5 в базе данных

Обновление

От исследования "участников" вот сравнение возможностей:

 PwdStore MD5         PwdStore CRAM-DM5
Webmail (Roundcube)

Client/Server       HTTPS only (HTTP requests would be upgraded, so PLAIN = OK)
IMAP                PLAIN                PLAIN / CRAM-MD5 (internal)²
SMTP                PLAIN                PLAIN / CRAM-MD5 (internal)²

Native Clients (connecting to Postfix/Dovecot)

IMAP³               PLAIN / LOGIN        PLAIN / LOGIN / CRAM-MD5
SMTP³               PLAIN / LOGIN        PLAIN / LOGIN / CRAM-MD5
POP3³               PLAIN / LOGIN        PLAIN / LOGIN / CRAM-MD5
IMAPS               PLAIN / LOGIN        PLAIN / LOGIN / CRAM-MD5
SMTPS               PLAIN / LOGIN        PLAIN / LOGIN / CRAM-MD5
POP3S               PLAIN / LOGIN        PLAIN / LOGIN / CRAM-MD5

PostfixAdmin
Create/Update       MD5 (internal)       CRAM-MD5 (via dovecotadm)⁴

^{1: Я просто проверил источники и нашел следующее в postfixadmin/functions.inc.php в строке 928:
Use proc_open call to avoid safe_mode problems and to prevent showing plain password in process table
Таким образом, этот контрдовод, кажется, падает.}

^{2: roundcube/program/lib/Roundcube/rcube_imap_generic.php строка 90ff, в function authenticate()}

^{3: ПЛОСКОСТЬ/ВХОД В СИСТЕМУ обычно отключена на незашифрованных соединениях}

^{4: Мог возможно быть переписан с помощью кода от Roundcube, поскольку оба записаны в PHP – но PostfixAdmin}