<transmissions-api-listener>
Отдельный список — в версии 1.3 наборы устроены иначе, чем в прежних, и общего языка описания у них нет. tls-ciphers на 1.3 не действует.
Умолчание перечисляет пять наборов — от TLS_AES_256_GCM_SHA384 до TLS_AES_128_CCM_8_SHA256.
Все пять современные. В версии 1.3 слабых наборов нет: комитет выкинул их из стандарта. Сужать список «ради усиления» здесь нечего.
Строка нужна редко — по требованию политики, не ради стойкости:
| Значение | Когда |
|---|---|
| не задавать (умолчание) | всегда |
| два-три набора | требование внешней политики |
| один набор | никогда |
# сужение до двух наборов — по требованию политики, не «для усиления» <transmissions-api-listener 1.2.3.4:8585> tls-certificate /etc/pmta/transmissions-api-certificate.pem tls-v1.3-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256</transmissions-api-listener>
что делают не так и чем это кончается2 ошибки▶
наш опыт
§ 3.3.21.9
2 связи
openssl s_client -connect NODE:8585 -tls1_3 -brief </dev/null
3 статьи
◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Группа, дающая право управлятьЧленство в группе pmta даёт непривилегированному пользователю право звать команды узла и пользоваться подачей.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.