broken-auth-clients
<source>устарела
Раздел § 3.3.7.16 состоит из одного слова: «Deprecated». Ни описания, ни синтаксиса, ни умолчания, ни имени замены — руководство не говорит даже, что директива делала, пока была живой.
Таких случаев в каталоге два: так же, одним словом, помечена pickup-retry-interval. У большинства прочих устаревших директив замена названа: smtp-ip отсылает к smtp-listener, max-msg-per-hour — к max-msg-rate. Здесь отсылки нет, и карточка не показывает плашку «вместо неё» не потому, что мы её не заполнили, а потому, что подставлять нечего.
Что известно точно. Директива относилась к блоку <source>, то есть к приёму почты, и стоит сразу за группой настроек входа и шифрования (§ 3.3.7.7–3.3.7.15): от allow-auth и require-auth до require-starttls-before-auth. Указатель директив главы 15 имя знает и ссылается на этот же пустой раздел.
Что подсказывает имя — и чего оно не доказывает. «Клиенты со сломанным входом» читается как послабление для программ, реализовавших команду AUTH не по правилам. Это чтение имени, а не факт из руководства: чем именно строка послабляла и в какую сторону, вендор не написал. Строить на такой догадке настройку нельзя — а вот узнать имя в старом файле она помогает.
Настройки входа у Хаба только описанные: логин на каждую отправляющую пару и общий логин пула — в источниках с require-auth; вход открытым паролем разрешён (allow-unencrypted-plain-auth), STARTTLS предлагается, но не требуется. Послаблений для нестандартных клиентов там нет. Подают почту платформы рассылки и прогрев Хаба; если чей-то клиент не сможет войти, разбираться придётся по журналу входа, а не этой строкой.
Что ставить. Ничего. Строку следует убрать из конфигурации — это единственная рекомендация, которую можно дать, не выдумывая.
| Значение | Когда |
|---|---|
| не писать | всегда |
| что-либо | никогда: чем строка управляет, неизвестно |
Если строка нашлась в унаследованном файле — убрать и проверить вход тех клиентов, что подают почту на этот узел. Обратная замена не потребуется: по смыслу имени строка могла лишь разрешать нестандартное поведение, а не запрещать, и её удаление ужесточает проверку, а не ослабляет её.
# примера руководство не даёт — вот как строка выглядит # в унаследованной конфигурации, и её надо убрать <source 0/0> broken-auth-clients yes require-auth true </source>
▲
Типичные ошибки и проблемы
что делают не так и чем это кончается3 ошибки▶
Ищут описание в другом разделе руководства
§ 3.3.7.16
Оставляют строку «на всякий случай»
§ 3.3.7.16
Толкуют имя как документацию
§ 3.3.7.16
- Синтаксис
- broken-auth-clients <boolean>
- Значения
- не документировано — раздел руководства состоит из пометки об устаревании
- Применение
- reload, перезапуск не нужен
- Очередь
- уже поставленное в очередь не затронет
- Где писать
- <source>
- Сколько раз
- один раз в блоке
Связанные директивы
2 связи
grep -rn 'broken-auth-clients' /etc/pmta/ pmta test config
Что ещё почитать
3 статьи
◇Принять, направить, доставитьПуть письма внутри узла: принять, решить куда, доставить — и между этими тремя шагами живут все настройки.◇Четыре типа значений, на которых написан весь конфигЛогическое, образец домена, регулярное выражение и промежуток времени — определены один раз в § 3.2 и дальше используются всеми директивами.◇Перезагрузка настроек против перезапуска службыКонфигурация читается при старте, дальше правки подхватываются командой перезагрузки — кроме тех директив, которые руководство помечает как требующие перезапуска.
- Цена ошибки
- безопасно: неверное значение ничего не ломает
- Сценарии
- Жизненный цикл конфигурации