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