Назад | Перейти на главную страницу

Безопасное облако для настройки внутренней почты с использованием UUCP или чего-то более современного

Некоторые из наших серверов Linux будут перенесены в облако. Но серверы должны иметь возможность отправлять электронные письма нашим пользователям внутри страны и должны использовать наше доменное имя в качестве отправителя. Сервер не может инициировать передачу данных в нашу сеть, т.е. единственный способ отправлять электронные письма - через наш почтовый сервер.
К сожалению (но это понятно) наши специалисты по безопасности не позволяют внешним серверам отправлять электронные письма, используя наш домен в качестве отправителя, поэтому ...
Я собираюсь настроить систему, в которой внутренний сервер инициирует соединение через SSH, собирает электронные письма и отправляет их локально нашим пользователям. потому что нам не разрешено открытое подключение извне к нашей внутренней сети, что может быть использовано хакерами, и это не вариант для добавления сервера ретрансляции.
В старые добрые времена (30 лет назад) мы использовали (технологию под названием) UUCP (Unix-to-Unix-Copy) для передачи файлов, почты, публикации новостей (NNTP), ... с использованием модемов :-) и я подумал эта установка была бы полезна снова более безопасным способом - но есть ли более современные альтернативы / установка?

Насколько я понимаю вашу проблему, в настоящее время у вас есть один или несколько входящих MX: es. Когда сервер вне вашей системы подключается к этим MX: es, а электронное письмо, которое он пытается отправить, содержит либо From: -header, либо отправителя конверта в вашем домене, ваш MX-сервер не принимает его.

UUCP - это один способ, да, и я действительно видел, что он используется через TCP / IP, но это было больше десяти лет назад, если не больше ... Но вот несколько альтернативных способов решения проблемы без открытого соединения в вашу сеть (чего, я согласен, следует избегать).

Ваш MX: es может иметь белые списки хостов, которым разрешено использовать ваше доменное имя, и вы можете добавить свои облачные серверы в этот белый список. Это предполагает, что ваши облачные серверы имеют фиксированные IP-адреса.
Если ваши облачные серверы не имеют фиксированных IP-адресов, вы настраиваете отдельный сервер, который делает, и вы занесли его в белый список.
Ваш MX: es может иметь белые списки адресов электронной почты в вашем домене, которые разрешено использовать извне, и вы настраиваете свои облачные серверы для использования этих конкретных адресов.
Если MX: es проверяет только отправителя конверта, ваши облачные серверы могут использовать любого отправителя конверта, который им нравится, но заголовок From: в электронном письме по-прежнему может быть в домене вашей компании.
Вы настраиваете отдельный SMTP-сервер, которого нет в списке MX, который разрешает входящий почтовый трафик только с ваших облачных серверов (либо с помощью белого списка IP-адресов, либо с помощью аутентификации, либо и того, и другого), и который может доставлять сообщения в вашу внутреннюю почтовую систему. Затем этот сервер должен находиться в том же или аналогичном DMZ / сегменте сети / в любом другом месте, что и ваши существующие MX. Вам необходимо настроить свои облачные серверы, чтобы использовать его в качестве ретранслятора.
РЕДАКТИРОВАТЬ Ваш MX: s может разрешать входящую электронную почту с их собственными доменами после аутентификации, и ваши облачные серверы могут быть настроены для аутентификации перед отправкой.

Все это имеет то преимущество, что вы можете продолжать использовать обычный SMTP без каких-либо нестандартных решений. Если ваш отдел безопасности не принимает ни одного из них, вы можете решить это, например, fetchmail с внутреннего сервера, который будет повторно вводить электронные письма из вашей организации.