Мы - довольно небольшой стартап, который занимается предоставлением почтовых услуг как часть портфолио. До сих пор все электронные письма наших офицеров высшего уровня проходили через наш собственный почтовый сервер и, следовательно, в том же магазине, что и наши клиенты. Почтовый сервер - это специально написанное решение, которое часто обновляется, но большая проблема в том, что наша команда DevOps имеет полный доступ как к серверу, так и к почтовому хранилищу. Есть кое-что, что можно сказать о тестировании нашего собственного программного обеспечения, но в какой-то момент по мере роста стартапа потребуется немного больше конфиденциальности.
Наши сотрудники используют тот же адрес электронной почты, что и наши клиенты, для более эффективных маркетинговых целей. Например, ceo.bob@product.com или client.su@product.com. Было принято решение сохранить этот шаблон, но найти способ, если возможно, перенаправить определенные псевдонимы на другой почтовый сервер или службу. Добавить @ corp.product.com было бы просто, но это не рекомендуется.
Мне было интересно, есть ли продукт, который действует как первая строка почтовых серверов @ product.com и проверяет соответствие псевдонимов [employee] @ product.com и отправляет его на другой почтовый сервер или службу, например Office365, а остальные отправляются на наш внутренний почтовый сервер продукта. Исходящие электронные письма должны выглядеть так, как если бы они исходили от @ product.com, как для сотрудников, так и для клиентов.
Спасибо, и любая помощь приветствуется.
Существует любое количество агентов передачи сообщений (MTA), которые будут делать то, что вы ищете, как коммерческих, так и бесплатных / с открытым исходным кодом. Вам нужно будет «делать покупки» для этого самостоятельно, в зависимости от набора функций, который вы ищете.
С точки зрения функциональности, ваш собственный почтовый продукт должен поддерживать неавторизованность адресного пространства SMTP "@ product.com", если вы хотите, чтобы эти пользователи сохраняли свои адреса электронной почты "@ product.com". Ничего не зная о вашем продукте, я не могу говорить об этой возможности, но большинство стандартных MTA прекрасно справляются с этой конфигурацией.
Конечно, есть некоторая обоснованность в том, что вторая группа системных администраторов обрабатывает это конфиденциальное электронное письмо с точки зрения разделения обязанностей, но похоже, что шифрование может быть лучшим ответом, чем «о, просто положи его туда». Вроде слабый способ «решить» эту проблему.
Компания может рассматривать это как возможность улучшить ваш продукт. Предположительно, поскольку ваши люди хотят большей функциональности конфиденциальности, ваши клиенты тоже могут этого захотеть.