Как узел выбирает источник и складывает его настройки
критично
Блоки <source> бывают двух пород, и ведут себя они по-разному.
Адресные блоки называют один адрес (10.0.0.5) или сеть в бесклассовой записи (10/8). Соединение попадает под все блоки, чьи адреса его накрывают, и настройки складываются — ровно так же, как у блоков получателей: где два блока говорят разное, побеждает более узкий.
Руководство печатает свой же пример дважды — как он написан и как его видит MTA после слияния. Это самое внятное место главы: читать конфигурацию построчно бесполезно, действует не строка, а сумма строк.
Именованные блоки (<source S1>) под адреса не подбираются вовсе. Они включаются только тогда, когда на них сослались по имени: параметром source= у smtp-listener или директивой source внутри <smtp-user>.
Что при этом происходит с адресными настройками, руководство описывает одним словом: именованный блок перекрывает то, что подобралось по адресу. Слово обещает наследование — настройка, о которой именованный блок молчит, должна достаться ему из адресного.
У нас вышло иначе. Переписывание обратного адреса, заданное в общем блоке 0/0, на авторизованное соединение не перенеслось: адрес остался неизменным, пока ту же строку не повторили в именованном блоке. Отсюда правило, по которому Хаб теперь собирает конфигурацию, — в именованном блоке повторяется весь набор, а не только то, что отличается.
Имена в фигурных скобках зарезервированы. Руководство называет два: {pickup} меняет обработку каталога подхвата, {auth} задаёт умолчания для любого аутентифицированного пользователя.
Отсюда практическое правило: разрешение, выданное в блоке 0/0, действует и на все подсети, для которых не сказано обратное. «Выдать только своим» означает запрет в широком блоке и разрешение в узком, а не наоборот.
В основном файле — адресные: 127.0.0.1 для подачи с самой машины, по блоку на каждый адрес из «Кому разрешена подача» и 0/0 как общая основа. Узкий блок наследует от широкого всё, чего сам не сказал: и выбор потока по адресу подачи, и список выбора, и подавление локальных отчётов. В базовой конфигурации, которая ставится до появления пар, выбора потока и списка в 0/0 ещё нет.
В файле адресов — именованные, по одному на логин подачи: общий {pmta-auth} и по блоку на каждую пару «домен плюс адрес». На них ссылается директива source внутри <smtp-user>. В каждом таком блоке Хаб выписывает полный набор — службу подачи, разрешение ретрансляции, требование авторизации, выбор потока, подавление локальных отчётов, работу с заголовками, — а не только отличия от адресных блоков. Так вышло не из осторожности: наследования на авторизованное соединение мы не увидели.
Имена Хаб берёт в фигурные скобки — формат общий с Protosender. Руководство эту область имён объявляет зарезервированной и называет в ней два своих имени; наши на них не похожи и работают, но область всё-таки вендорская.
# оба блока накрывают подачу с самой машины — действуют слитно <source 0/0> default-virtual-mta by-smtp-source-ip add-received-header false </source> <source 127.0.0.1> always-allow-relaying yes max-message-size 30M </source>
▲
Типичные ошибки и проблемы
что делают не так и чем это кончается4 ошибки▶
Читают конфигурацию построчно
§ 3.3.7
Ждут, что именованный блок подберётся сам
§ 3.3.7
Полагаются на наследование в именованный блок
наш опыт
Разрешают в широком блоке, надеясь ограничить узким
наш опыт
Связанные записи
3 связи
smtp-listenerGlobalПараметр source= у приёмника выбирает именованный блок и отменяет адресный подбор целиком. § 3.3.7source<smtp-user>Аутентифицированного пользователя можно привязать к именованному блоку. § 3.3.7
Заголовки, которыми отправитель управляет доставкойВсе разрешения задаются у источника и подчиняются его слиянию. § 3.3.7bcc<source>Подчиняется слиянию источников, как и любая настройка блока: копия снимается с той подачи, чей адрес попал под блок. § 3.3.7.3smtp-service<source>Слияние источников и делает работающим приём «запретить в широком блоке, разрешить в узком». § 3.3.7.63Как складывается политика для приёмникаТот же механизм слияния для отправителей: там он решает приём, здесь — доставку. § 3.3.10Заголовок балансировщика на входеИзвлечённый из заголовка адрес и сверяется со списком источников. § 3.3.17.16source<smtp-listener>Отменяет для этого порта обычный подбор блока по адресу отправителя. § 3.3.17.3
grep -n '^<source\|^</source' /etc/pmta/config /etc/pmta/virtualhost.txt pmta test config
Что ещё почитать
3 статьи
◇Настройка через API и файл не сходятсяОбъекты, созданные через интерфейс настройки, в файле не правятся: два источника правды о конфигурации не сходятся.◇Логины подачи, пароли открытым текстом и настройки на каждогоОтправитель входит одним из трёх способов; каждый логин — блок конфигурации с паролем в открытом виде, и именованный источник этого логина перекрывает то, что дал бы его адрес.◇Принять, направить, доставитьПуть письма внутри узла: принять, решить куда, доставить — и между этими тремя шагами живут все настройки.
- Цена ошибки
- обратимо: вредит, пока стоит
- Сценарии
- Жизненный цикл конфигурации · Безопасность узла · Разделение отправителей
- Важность
- критично