Удаленный IP и прокси SMTP
Действительно ли возможно проксировать электронные письма - с постфиксом, например - прозрачно, таким образом, почтовый сервер бэкенда получит последний IP-адрес сервера SMTP (цель рубля) а не IP-адрес Прокси?
Если это возможно, и в том же уме SMTP мог бы проксировать электронные письма маршрута доменом получателя к различным бэкендам?
То, что вы просите, в основном возможно, но есть несколько предостережений. Я сам несколько лет назад пытался написать такой прокси-сервер, но есть несколько проблем, который я так и не решил полностью.
Как мне кажется, свойство, определяющее разницу между прокси и полным ретранслятором, таково: Прокси никогда сам по себе не берёт на себя ответственность за почту.
Реле получит почту от хоста отправителя и в конце DATA подтвердит хосту отправителя, что он берёт на себя ответственность за доставку почты. Это означает, что уже в это время оно должно быть постоянным на диске ретранслятора, и хост-отправитель может забыть об этом.
Прокси-сервер, с другой стороны, будет соединяться с обратной стороной, в то время как почта всё ещё будет получать почту с хоста-отправителя. Прокси не принимает на себя ответственность за почту самостоятельно. Скорее прокси получает обещание от бэкэнда взять на себя ответственность за почту и просто проксирует это сообщение обратно на хост отправителя.
Но сейчас приходит самая большая проблема в такого рода прокси: Может быть несколько бэкэндов. Предположим, что хост-отправитель посылает вам не один, а несколько адресов получателей, и эти адреса разрешаются на разные бэкенды. Вы собираетесь открывать SMTP-сессии с каждым бэкендом, продолжая получать от клиента?
Если вы откладываете подтверждение клиенту в конце DATA до тех пор, пока не получите подтверждение от каждого бэкенда, то вы часто можете оказаться в ситуации, когда вы получили подтверждение от некоторых бэкендов, но не от всех из них. Если вы сообщаете клиенту об успехе, вы берете на себя ответственность за его доставку всем бэкендам. Если вы сообщите об ошибке или клиенту о тайм-ауте, клиент будет повторно передавать, не зная, что почта уже доставлена некоторым из получателей.
SMTP по замыслу действительно вводит возможность дублирования почты в таких сценариях. Хорошее программное обеспечение на принимающей стороне может дедуплицировать, когда две копии получены с идентичным получателем, Message-ID и содержимым. Но прокси с несколькими бэкэндами делает такое дублирование гораздо более вероятным, и это может легко произойти несколько раз для одной и той же почты.
Как затем сохранить IP клиента при взаимодействии с бэкэндом? Путь, который я выбрал, чтобы внедрить его в домен, я посылаю команду HELO на бэкенд. Я мог отправить домен в виде 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 соединению и ничему больше.
Вы можете иметь постфикс для перезаписи заголовков, чтобы получить желаемые результаты, но это будет НИКОГДА не будет прозрачным, так как это сломает некоторые КСФ.