Постфиксная ретрансляция, мультидомен, безопасность и практически все

Я хочу настроить сервер ретрансляции со статическим IP-адресом в сети, который должен принимать почту для нескольких доменов, а также отправлять почту для этих доменов. К сожалению, мой опыт работы с postfix менее чем ограничен, поэтому у меня есть несколько общих вопросов по архитектуре.

Кроме того, так как мне не удалось найти руководство по настройке почтового сервера «состояние, если искусство, следуя текущим рекомендациям», я более чем рад добавить сведения о механизме или конфигурации на основе рекомендаций (BSI, NIST, M3aawg и т. Д.). ) и связать их в качестве ссылки.

Что я имею в виду

Ретрансляторы будут вызываться ( список хостов ретрансляции )

• a.mx.my-company.com
• b.mx.my-company.com

и они собираются получить каждый сертификат SSL через Let's encrypt, выданный на их соответствующее имя хоста, для STARTTLS на порту 25.

Кроме того, у меня есть список доменов, для которых сервер должен принимать почту ( список принятых доменов )

• onedomain.com
• onedomain.net
• otherdomain.com

Существует еще один список хостов отправителей, которые подключаются к ретрансляторам для отправки почты и подключаются к ретрансляторам для получения почты ( список хостов отправителей )

• a.mail.intern.onedomain.com
• b.mail.intern.onedomain.com
• a.mail.intern.otherdomain.com
• mail.holdingcompany.com

Определено несколько пользователей (hostname_sender + "_up"), которые должны получить права на отправку имени домена ( принятые пользователи ретрансляции доменов )

• пользователь: a.mail.intern.onedomain.com_up ; грант: onedomain.com, onedomain.net
• пользователь: b.mail.intern.onedomain.com_up ; грант: onedomain.com, onedomain.net
• пользователь: a.mail.intern.otherdomain.com_up ; Грант: otherdomain.com
• пользователь: mail.holdingcompany.com_up ; грант: onedomain.com, onedomain.net, otherdomain.com

И наоборот, определяется список пользователей (hostname_sender + "_down"), который позволяет ретранслирующим хостам подключаться к хостам отправителя ( список пользователей доставки ).

• пользователь: a.mail.intern.onedomain.com_down
• пользователь: b.mail.intern.onedomain.com_down
• пользователь: a.mail.intern.otherdomain.com_down
• пользователь: mail.holdingcompany.com_down

Разрешение подключений через порт 25

Для внешних серверов

Обычный почтовый сервер, такой как Yahoo или Gmail, может хотеть доставлять сообщения через мои реле. Затем сервер должен проверить основные вещи, такие как статический ip, а не в черном списке, и если целевой домен находится в моем списке принятых доменов . Это соединение может использовать или не использовать STARTTLS.

Я думаю о игнорировании SPF, так как это не надежный дизайн. С другой стороны, я хотел бы использовать DKIM для жесткого перехвата любых писем, приходящих с домена, для которого настроен DKIM, но входящая почта не совпадает с подписью. Кроме того, я думаю, что было бы неплохо отправить копию письма с ошибкой руководителю поста с описанием ошибки, на случай, если какой-то пользователь пожалуется, он не получит ожидаемое им письмо.

Для доверенных / внутренних серверов / пользователей

Почтовый сервер внутри какой-либо сети может подключаться через порт 25, не выполнять любые проверки (находясь в черном списке, иметь динамический IP-адрес и т. Д.), Но должен включить STARTTLS, а затем выполнить аутентификацию через принятых ретрансляторов домена . С этого момента соединение может использоваться для рассылки писем от имени любого домена, доступ к которому разрешен пользователю. Через него должны подключаться только ретрансляторы, а не конечные пользователи. Этот сервер также не должен добавлять какую-либо информацию DKIM, так как это просто публично «доверенный» почтовый сервер со статическим ip, а не в черном списке.

Доставка почты ответственному узлу отправителя с узла ретрансляции

Внутри конфигурации моего ретранслятора я найду список ( список переадресации доменов )

• onedomain.com, onedomain.net -> a.mail.intern.onedomain.com, b.mail.intern.onedomain.com [, mail.holdingcompany.com]
• otherdomain.com -> a.mail.intern.otherdomain.com [, mail.holdingcompany.com]

Запрос комментариев

Я пытаюсь установить для себя хороший и современный стандарт в настройке почтовых серверов. Я думал об этой архитектуре, чтобы дать мне большую гибкость и возможность предоставлять почтовые серверы на динамических IP-адресах. Потенциально это может доходить до того момента, когда «постфикс с сайта», доступный через брандмауэр сайта через нестандартный порт, будет принимать только соединения TLS с allow_tls_clientcerts.

Если пересылается входящая почта для userA@onedomain.com, она должна в моем конфиге принять маршрут через любой хост из списка переадресации моего домена для данного домена. Сами серверы могут находиться в двух отдельных местах, и только каждый из них подключен через линию 16/1 Мбит, с разными почтовыми ящиками на соответствующих серверах IMAP. Хотя это будет работать, поскольку внутренние серверы могут напрямую обмениваться сообщениями друг с другом, я хотел бы знать, есть ли способ пойти дальше:

• a.mail.intern.onedomain.com -> responese: пользователь существует, но я не отвечаю
• b.mail.intern.onedomain.com -> responese: спасибо

Или же:

• a.mail.intern.onedomain.com -> responese: пользователь существует, но я не отвечаю
• b.mail.intern.onedomain.com -> responese: пользователь существует, но я не отвечаю
• mail.holdingcompany.com -> responese: пользователь существует, но я не отвечаю
• Сообщите почтмейстеру, действующий адрес, но никто не несет ответственности

Или же:

• a.mail.intern.onedomain.com -> responese: неизвестный пользователь

Или же:

• a.mail.intern.onedomain.com -> responese: пользователь существует, но я не отвечаю
• b.mail.intern.onedomain.com -> время ожидания
• mail.holdingcompany.com -> responese: пользователь существует, но я не отвечаю
• уведомить почтмейстера после нескольких попыток на b.mail.intern.onedomain.com

С чем я борюсь

В основном, если возможно иметь такую ​​настройку с postfix и как проверить правильность работы механизмов forward, deny и auth.

Я искал что-то вроде в iptables, где у меня может быть набор правил примерно так

• соответствует "внешний сервер, не включенный в черный список" -j external_trustworthy
• соответствует "внутренняя аутентификация с TLS" -j internal_authed
• -j отклонить

И тестируя это поведение, я не буду случайно применять политику черного списка к internal_authed или, что еще хуже, предоставлю external_trustworthy для отправки писем от имени моих принятых доменов. Кроме того, мне бы очень хотелось, чтобы Letsencrypt выпустил доменные сертификаты S / MIME, которые снова могли бы выдавать и отзывать клиентские S / MIME-сертификаты для беспрепятственного шифрования почты. Это еще одна тема, но, тем не менее, она требует прочной базы, чтобы иметь возможность общаться с «высоконадежными» и «не очень хорошо» настроенными SMTP-серверами по всему миру.