Можно ли прозрачно проксировать электронные письма - например, с постфиксом, чтобы внутренний почтовый сервер получал последний IP-адрес SMTP-сервера (назначение rbl), а не IP-адрес прокси?
Если это возможно и в том же духе, может ли прокси-сервер SMTP направлять электронные письма по домену получателя на разные серверы?
Вы можете иметь postfix переписать заголовки для получения желаемых результатов, но это будет НИКОГДА быть прозрачным, поскольку это нарушит некоторые RFC.
То, о чем вы спрашиваете, в основном возможно, но есть несколько предостережений. Я сам пробовал написать такой прокси несколько лет назад, но есть несколько проблем, которые я так и не решил полностью.
На мой взгляд, свойство, которое будет определять разницу между прокси и полным ретранслятором, таково: прокси никогда не берет на себя ответственность за почту.
Ретранслятор получит почту от отправляющего хоста и в конце DATA подтвердите отправляющему хосту, что он принимает на себя ответственность за доставку почты. Это означает, что он уже должен быть в это время постоянным на диске ретранслятора, и отправляющий хост может забыть об этом.
Прокси-сервер, с другой стороны, будет подключаться к серверной части, все еще получая почту от отправляющего хоста. Прокси-сервер сам по себе не несет ответственности за почту. Скорее прокси получает обещание от бэкэнда, берущего на себя ответственность за почту, и просто передает это сообщение обратно на хост-отправитель.
Но теперь возникает самая большая проблема с такого рода прокси: может быть несколько бэкэндов. Предположим, хост-отправитель отправляет вам не один, а несколько адресов получателей, и они разрешаются на разные серверы. Собираетесь ли вы открывать сеансы SMTP с каждым сервером, продолжая получать от клиента?
Если вы откладываете подтверждение клиенту в конце DATA пока вы не получите подтверждение от каждого бэкэнда, вы можете часто оказаться в ситуации, когда вы получили подтверждение от некоторых бэкэндов, но не всех из них. Если вы сообщаете об успехе клиенту, вы берете на себя ответственность доставить его всем бэкэндам. Если вы сообщаете об ошибке или время ожидания клиента истекает, клиент будет повторно передавать, не зная, что почта уже была доставлена некоторым получателям.
SMTP по своей задумке действительно вводит возможность дублирования почты в таких сценариях. Хорошее программное обеспечение на принимающей стороне может выполнять дедупликацию, если получены две копии с одинаковым получателем, идентификатором сообщения и содержимым. Но прокси-сервер с несколькими бэкэндами сделает такое дублирование гораздо более вероятным, и это может легко произойти несколько раз для одной и той же почты.
Как тогда сохранить IP-адрес клиента при взаимодействии с серверной частью? Я выбрал путь, чтобы встроить его в домен, я отправляю HELO команда на бэкэнд. Я мог бы отправить домен вида <IP>.example.com конечно, вставив свой домен. Я мог бы даже включить домен из оригинала HELO команда до или после IP-адреса.
Я бы еще вставил полный и правильно отформатированный Received заголовок перед пересылкой почты. В Received Заголовок, вероятно, является лучшим способом получить IP-адрес на бэкэнд, потому что он достаточно стандартизирован, поэтому бэкэнд должен иметь возможность его анализировать.
На самом деле подмена IP-адреса исходного клиента при взаимодействии с серверной частью также технически возможна в определенных ситуациях, но это сложно. Вы не просто выполняете переадресацию или NAT, вам нужно завершить TCP-соединения на прокси-сервере, так что это совершенно новое TCP-соединение.
Если сетевой маршрут от бэкэнда к IP-адресу клиента принимает пакеты через прокси-сервер, то, конечно, прокси-сервер может подделать IP-адрес клиента. Но одновременное наличие того же IP-адреса, что и локальный адрес в некоторых соединениях TCP, и удаленный адрес в других соединениях TCP, скорее всего, запутает уровень TCP. Вы можете отказаться от спуфинга на самом уровне TCP и вместо этого использовать отдельный компонент, который каким-то образом проинструктирован о том, как преобразовывать трафик через NAT.
Это можно сделать с помощью стандартной реализации NAT, например iptables следующим образом. Прокси-сервер сначала привязывается к локальному IP-адресу и номеру порта. Затем он вставляет iptables Правило NAT, которое указывает, что исходящие пакеты с определенной комбинацией IP-адреса источника и порта, а также IP-адреса назначения и порта должны быть преобразованы в NAT к исходному IP-адресу клиента. Перед тем, как прокси фактически выполнит connect системный вызов, он знает все эти адреса и номера портов, поэтому он может создать полностью целевой iptables правило, которое будет соответствовать этому TCP-соединению и никакому другому.