<transmissions-api-listener>
Список допустимых шифров для соединений этого входа. Запись — как у команды OpenSSL ciphers, умолчание HIGH:!ADH:@STRENGTH: только сильные наборы, без анонимного обмена ключами, отсортированные по стойкости.
Действует по TLS 1.2 включительно. У версии 1.3 свой список — tls-v1.3-ciphersuites.
Порядок значим только вместе с tls-cipher-server-preference: по умолчанию шифр выбирает клиент, и сортировка @STRENGTH ни на что не влияет.
Умолчание разумно; менять только по внешнему требованию:
| Значение | Когда |
|---|---|
| HIGH:!ADH:@STRENGTH (умолчание) | всегда |
| своё сужение | требование аудита, с проверкой подачи до применения |
| версия 1.3 | этой строкой не задаётся |
# умолчание, записанное явно <transmissions-api-listener 1.2.3.4:8585> tls-certificate /etc/pmta/transmissions-api-certificate.pem tls-ciphers HIGH:!ADH:@STRENGTH</transmissions-api-listener>
что делают не так и чем это кончается2 ошибки▶
наш опыт
§ 3.3.21.10
3 связи
openssl s_client -connect NODE:8585 -tls1_2 -brief </dev/null
3 статьи
◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Группа, дающая право управлятьЧленство в группе pmta даёт непривилегированному пользователю право звать команды узла и пользоваться подачей.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.