Как убить все сеансы для пользователя Linux, кроме первого, и ограничить пользователей одним сеансом входа в систему

Клиент настроен на подключение к mail.example.com.

Сервер, к которому он подключается, утверждает (в сертификате), что это beta.example.com.

Поскольку mail.example.com не совпадает с beta.example.com, клиент жалуется на несоответствие. Это полностью задумано.

Чтобы это работало, вам нужно настроить почтовый сервер для предоставления сертификата, который включает альтернативное имя субъекта, совпадающее с именем хоста, на которое указывает клиент. Вопрос о том, как это имя хоста преобразуется в IP-адрес, не имеет значения.

Раньше имя хоста помещалось в поле «Общее имя» сертификата, но эта практика устарела. Вы по-прежнему можете указать имя хоста в качестве CN сертификата, если хотите, но для лучшей совместимости вам необходимо также указать его как SAN. Я полагаю, что большинство ЦС представят вам CN как SAN как услугу, если вы сами этого не сделаете в своем CSR, но есть риск, что некоторые этого не сделают; проверьте свой сертификат.

Если вы должны использовать один и тот же сертификат для Postfix и Dovecot, но по какой-то причине вы хотите опубликовать для них разные имена хостов (например, smtp.example .com и pop.example.com), то вам нужен сертификат, действительный для обоих задействованных имен хостов. Это можно сделать с помощью сертификата с несколькими именами хостов или сертификата с подстановочными знаками (*.example.com).

Кроме того, MX (почтовый обменник) DNS RR действительно важны только для входящих SMTP-соединений с почтовым сервером, обрабатывающим почту для определенного домена, где удаленный почтовый сервер изначально знает только домен получателя. Вполне допустимо иметь, например,

example.com. MX 0 mail.example.com.
mail.example.com. CNAME beta.example.com.
beta.example.com. A 192.0.2.123

, хотя на самом деле это не рекомендуется, потому что указание RR на неканонический RR может привести к тому, что некоторые распознаватели захлебнутся.Однако, если резолвер удаленной системы принимает его (большинство так и делает), вышеописанное практически аналогично тому, как если бы вы имели

example.com. MX 0 mail.example.com.
mail.example.com. A 192.0.2.123

В обоих случаях удаленный MTA (агент пересылки почты; в наши дни к другим почтовым серверам) будет подключаться к mail.example.com (поскольку это имя хоста MX, указанное в MX RR), и, следовательно, будет ожидать сертификат, действительный для mail.example.com.

Ваш MUA не будет обращаться к записям MX и в любом случае не узнает об этом; он будет сверяться с адресом (A, AAAA и в редких случаях может быть также A6; A6 RR устарели, но какое-то время использовались для IPv6) записи любого имени хоста, которое вы ему даете в качестве сервера входящей (POP/IMAP) или исходящей (SMTP) почты.