Я работаю айтишником в юридической фирме. Меня недавно попросили создать систему, в которой все исходящие электронные письма, поступающие с нашего сервера нашим клиентам, сначала будут приостановлены и будут ждать утверждения, прежде чем они будут отправлены клиенту.
Наш почтовый сервер использует Exim (так написано в cPanel). Я планирую создать фильтры, в которых исходящие электронные письма будут перенаправляться в учетную запись редактора. Затем редактор просмотрит и отредактирует содержимое электронного письма. Когда редактор уже одобряет электронное письмо, оно будет отправлено клиенту редактором, но с использованием исходного отправителя в полях «От:» и «Ответить:».
Я нашел несколько указателей с этого сайта => http://www.devco.net/archives/2006/03/24/saving_copies_of_all_email_using_exim.php.
После того, как фильтры установлены, я хочу создать простой интерфейс PHP для редактора, чтобы проверять пересылаемые электронные письма и редактировать их при необходимости. Затем редактор может щелкнуть кнопку «Утвердить», и сообщение будет доставлено с использованием исходного отправителя.
Я также думаю, что, возможно, будет достаточно системы без PHP. Редактор может получать электронные письма от своего собственного почтового клиента, редактировать их и просто отправлять электронное письмо, как если бы он был исходным отправителем.
Обновление: (6 апреля 2012 г.) Вышеупомянутые вопросы, вероятно, нечеткие, поэтому вот более конкретный вопрос: 1. Могу ли я пересылать ВСЕ исходящие сообщения, идущие ВНЕ нашего домена, для отправки на другой адрес, а НЕ фактическому получателю?
К сожалению, ответ на ваш вопрос - да, такую систему можно реализовать, но, к счастью, нелегко.
Поскольку вы работаете в юридической фирме, я удивлен, что никто не поднял вопросов, связанных с подотчетностью и достоверностью при создании такой ужасной системы. Когда вы имеете дело с любой формой общения, установка неинтерактивного посредника - ужасная идея, и результаты быстро станут сопоставимы с игрой со сломанным телефоном с вашими клиентами.
Самый быстрый способ настроить систему в соответствии с вашей спецификацией - запустить 2 экземпляра Exim; один экземпляр для обработки входящих сообщений и их буферизации на диск, а другой экземпляр для обработки доставки буферизованных сообщений. Базовый рабочий процесс для этой ситуации будет следующим:
/var/spool/exim-in//var/spool/exim-in/input/ и разрешить редактору внести необходимые изменения или полностью удалить сообщение из спула. Затем приложение переместит сообщение в новый каталог буферизации, например /var/spool/exim-out//var/spool/exim-out/Настроить Exim для этого не очень сложно, и аналогичные конфигурации можно получить, просмотрев типичный MailScanner setup, который также разделяет Exim на две очереди, при этом сообщения могут перемещаться из одной очереди в другую только через MailScanner. Видеть эта страница для быстрого обзора того, как MailScanner настроен с Exim.
Менее тривиальным было бы написать приложение, которое обеспечило бы интерфейс для обработки необходимого вам процесса редактирования и утверждения. Существует бесконечное количество препятствий, с которыми вы столкнетесь, если попытаетесь написать такое приложение, например, правильный синтаксический анализ заголовка и работа со сложными сообщениями типа MIME. По сути, вы бы переписали типичный MUA, такой как Outlook или Thunderbird; Если, конечно, ваш редактор не возражает против просмотра необработанных данных SMTP и HTML, и в этом случае вы можете просто отобразить их как простой текст.
Короче, не делай этого. Это не только ужасная идея, но и вы неизбежно столкнетесь со многими препятствиями при реализации, которые сделают эту попытку совершенно невыполнимой для отдельного разработчика.
Возможен ли мой план?
Нет, не совсем. Проблема в том, что (почти) все в электронном письме и его заголовке можно изменить и подделать. Кроме того, любой в вашей компании может отправлять электронную почту через любой другой сервер, который ему нравится (если вы не заблокируете весь их доступ в Интернет, о, подождите, вы не можете, у них все еще есть свои смартфоны и т. Д.), По-видимому, исходящие от вашей компании. Если сотрудник вашей компании хочет избежать проверки со стороны PHB, он просто использует внешний почтовый сервер (MTA).
Вам даже не нужно беспокоиться о доставляемости, например, если приветствие rDNS или EHLO не соответствует пути возврата. Просто сделайте домен обратного пути таким же, как у исходящего MTA, но измените адрес From: на адрес вашей компании, и почти все так думают. ЯВЛЯЕТСЯ от вашей компании.
Будут ли проблемы, которые я упустил?
Да всегда. Это бессмысленное занятие, и его легко обойти. Чтобы избежать головной боли у себя и своих коллег, вам нужно объяснить это своему PHB и убедить ее или его в том, что это неправильный путь. Есть лучшие способы подойти к этому. Но это больше связано с политикой компании, обучением и наймом нужных сотрудников и конкретными правилами, чем с крайними (и которых легко избежать) мерами ограничения свободы. Подобные драконовские меры имеют свойство укусить вас в долгосрочной перспективе почти без исключения.
Есть ли опасность того, что другие почтовые серверы будут рассматривать его как спам, если я испорчу заголовки?
Скорее всего, не. Все, что есть в заголовках, можно подделать и изменить (см. Выше). Это в значительной степени стандарт, MTA все время добавляют и меняют что-то в заголовках. Делаете ли вы это как человек или создаете сценарий, чтобы что-то изменить, MTA на самом деле все равно. Пока он подтвержден и принят MTA, у него не должно быть больше шансов быть помеченным как спам (в разумных пределах, конечно).
В любом случае, я не хочу больше думать об этой поистине ужасающей идее. :-(