Переброска почты через сервер

поставь на 2.2.2.2 простой смтп релей и перенаправляй им всю почту на 1.1.1.1

такой вариант не очень нравится, несколько лет назад делал как то так что при отправке с 1.1.1.1 адреса натились и перебрасывались на 2.2.2.2 и с 2.2.2.2 уже шли в мир, сейчас хоть убей не могу вспомнить как я это делал...

такой вариант не очень нравится,

смтп сервера прекрасно маршрутизируют почту, и притом делают это правильно, а с прокидкой портов или натом велик шанс наступить на какой-нить dsbl.org, который тебя внесет в блэклист из-за неправильного баунса

после работы постмастером, у меня сложилось твердое убеждение, что натинг смтп до добра не доводит

Аргумент серьезный, сейчас буду делать как Вы советуете, спасибо !

Аргумент серьезный, сейчас буду делать как Вы советуете, спасибо !

ты еще подумай на тему нужен ли вообще смтп на Serv_db, если он у тебя работает только как MDA то проще будет сразу с Serv_world туда по lmtp почту отдавать

в этом случае схема еще проще получиться

Вроде у вас всё нормально, только посмотрите FORWARD на 2.2.2.2. Если в FORWARD всё разрешено, то беритесь за tcpdump. Выбирайте адрес какого-нибудь smtp-хоста и пытайтесь сделать telnet на этот ip на 25 tcp-порт. А перед этим запустите по экземпляру tcpdump'а на каждом стевом интерфейса на перехват пакетов для этого ip-адреса. Тогда будет видно куда и какие пакеты идут.

Если вы установите smtp relay на 2.2.2.2 (serv_world), то думайте как его настроить, потому что по идее он должен принимать всю почту для домена (в том числе и для не существующих пользователей) и только при передаче на 1.1.1.1 узнавать что такого пользователя нет...

Ничего старшного в изначальной схеме я не вижу, главное проследить, чтобы smtp-сервер на 1.1.1.1 представлялся DNS-именем 2.2.2.2, а не своим собственным. И в заголовок ″Received:″ писал правильное имя. То есть сначала настроить и оправить одно письмо на тестовый адрес, чтобы убедится в правильности его содержимого, а уже потом рассылать почту на все сервера Инета.

Настроил пока так что 2.2.2.2 принимает почту, а так же является релеем для 1.1.1.1 + на 2.2.2.2 настроил что бы менялись заголовки на нужные. Пока временно такого решения хватит, так как сейчас почты особо нет, чуть позже буду рыть дальше в сторону iptables, как нарою отпишу - может кому интересно будет.

Ничего старшного в изначальной схеме я не вижу, главное проследить, чтобы smtp-сервер на 1.1.1.1 представлялся DNS-именем 2.2.2.2, а не своим собственны

а соль ты хранишь в банке из под чая с надписью сахар? (:

Пищевые продукты храню в банках без надписей, итак всё понятно, надписи для СДЯВ.

Вобще, бывает, что ip-адрес всего один, а нужно отдельный http-сервер и отдельный smtp-сервер и делают NAT на маршрутизаторе. И ничего, всех ещё не заблеклистили.

Вобще, бывает, что ip-адрес всего один, а нужно отдельный http-сервер и отдельный smtp-сервер и делают NAT на маршрутизаторе. И ничего, всех ещё не заблеклистили.

и что мешает на точке входа поставить какой нить нжинксопрокси и смтп релей и форвардить трафик по серой сетке? и что будет с натом когда на этот единственный ип надо будет повесить еще один хттп/смтп/етц сервер?

Вешать несколько smtp серверов на один ip-адрес уже не совсем типичная задача. Один ip-адрес — одна маленькая фирма с одним доменом. Маршрутизатор (граничный) выполняет только функции маршрутизации и NAT, это может быть железячка или PC, но вместо жёсткого диска (флешка в ro).

А по поводу smtp-relay я уже писал, что с ним возникают сложности относительно bounce-email'ов, ведущие к backscatter-email.

Вешать несколько smtp серверов на один ip-адрес уже не совсем типичная задача.

и глупая, один смтп сервер может держать в количестве мх

я тебе говорил за маршрутизацию смтп траффика и про то что это выполнять надо средствами мта, делать это натом, имхо, извращение и следствие непонимания предмета

А по поводу smtp-relay я уже писал, что с ним возникают сложности относительно bounce-email'ов, ведущие к backscatter-email

при правильной настройке не возникает

при правильной настройке не возникает

Подробности правильной настройки можно узнать? А то ещё окажется, что, либо вы считаете правильным полный отказ от bounce-email, либо у вас на relay'е нужно прописывать список всех почтовых ящиков почтового домена.

Если задача вешать несколько smtp-серверов на один ip для вас глупая, то зачем же было начинать с этого:

и что будет с натом когда на этот единственный ип надо будет повесить еще один ...смтп... сервер?

Уж определитесь со своими фантазиями в необходимости нескольких почтовых серверов.

я тебе говорил за маршрутизацию смтп траффика и про то что это выполнять надо средствами мта

Маршрутизация smtp-траффика не отличается от маршрутизации другого трафика. Ставить MTA на каждый хоп это безумие.

делать это натом, имхо, извращение и следствие непонимания предмета

Да, и установите smtp-сервер на cisco или бездисковый PC'юк.

Другой аргумент, что если Serv_world принимает почту из внешнего мира, то именно на нём нужно будет настраивать и регулировать первичную фильтрацию спама (black/while листинг, gray-listing), так как именно он принимает письмо и «знает» с какого ip-адреса идёт попытка передачи письма и, допустим, резолвится ли на момент передачи письма ip-адрес отправителя.

При этом если на Serv_db тоже работает MTA, то мы получим, что нам нужно настраивать два MTA, а не один.

В случае с DNAT у нас один MTA, и коннект идёт к нему и на нём можно делать что угодно с фильтрацией спама.

Подробности правильной настройки можно узнать? А то ещё окажется, что, либо вы считаете правильным полный отказ от bounce-email, либо у вас на relay'е нужно прописывать список всех почтовых ящиков почтового домена.

если мне не изменяет склероз, баунц должен идти с смтп который есть МХ, и тут есть несколько вариантов:

1) таки прописываем все почтовые ящики и домены которые он обслуживает, очень даже ничего для конторы с парой доменов и десятком ящиков

2) LMTP в качестве mailbox transport + прописывем все что надо релеить

3) ldap, postgeres, mysql или откуда еще умеет ваш мта выгребать пользователей с доменами

а дальше смотреть по ситуации, мне в случае провайдеровского релея, пришлось автогенерить все транспорты, беганье в постгрес за каждым юзером повергало последнего в ступор

Если задача вешать несколько smtp-серверов на один ip для вас глупая, то зачем же было начинать с этого:

и что будет с натом когда на этот единственный ип надо будет повесить еще один ...смтп... сервер?

тут походу друг друга недопоняли, мне показалось что ты имеешь ввиду на том же тазике еще один смтп (слышал и про такое извращение), а я имел ввиду еще один смтп севрер в инфраструктуре

Уж определитесь со своими фантазиями в необходимости нескольких почтовых серверов.

это не моя фантазия, почта для филиала, который в меру особенности местного прова не всегда доступен, например

Маршрутизация smtp-траффика не отличается от маршрутизации другого трафика. Ставить MTA на каждый хоп это безумие.

зачем пользоваться шелом, если все равно все сводиться в вызовам сисколов, можно же просто писать программки си и их выполнять, ведь пофакту эфект будет тот же, правда?

Да, и установите smtp-сервер на cisco

на цыско не надо, и в случае дмз без проброса портов никак, хотя при наличии несколько ипов, один можно и пробросить (:

или бездисковый PC'юк

вот тут не надо, опыт запуска всякой хни на бездисковой машине присутствует

зы: имея в руках молоток, любая проблема рассматривается как гвоздь

ты ведь сетевик?

ты ведь сетевик?

Немного, но так я ближе к сисадминам. Несколько лет ативно мучал postfix, правда на лето, когда сетевики уходили в отпуска, мне вручали пароли от цисок и исчёрканый листок A4 со схемой их подключений :-)

Возможно, что это мой личный батхерт против нескольких SMTP, просто в одной конторе мне досталось в наследство заопарк из нескольких SMTP, которые гоняли прочту через друг-друга, в том числе и потому, что только на однин из них была куплена лицензия drweb. Железо было самое дешёвое и глючило, получалось, что уж лучше бы сделали один smtp-сервер за нормальные деньги чем эту кучу Г.

Изначальное нежелание ТС ставить smtp-сервер на Serv_world остаётся загадкой, при условии что он действительно админит оба сервера.

В ряде известных мне небольших фирм почту DNAT'ят по той причине, что маршрутизатор у них админится фрилансером (на договорной оплате), а почту они получают на MS эксчендж, куда пользователей (ящики) добавляет штатный эникейщик. И ничего, как-то работает, во всяком случае работает лучше, чем если бы маршрутизатор админили меняющиеся эникейщики :-)

Если же фирма побольше, то ей, ИМХО, просто нужно получать несколько ip-адресов и выделять под почту отдельный. Сюда же я бы отнёс случай, когда фирме действительно нужны несколько smtp-серверов, допустим для филиалов. На отдельном ip-адресе держать центральный smtp-сервер, который будет делать анти-спам и анти-вирус и раскидывать почту по филиалам. DNAT здесь не нужен.

или бездисковый PC'юк

вот тут не надо, опыт запуска всякой хни на бездисковой машине присутствует

Да, но SMTP-сервер должен где-то хранить почту, и, чтобы она не терялась, лучше бы это был «обслуживаемый» raid. Под обслуживаемым я подразумеваю оперативную замену «сдохшего» диска, а не через неделю, когда админ придёт из отпуска. Причём сейчас, когда госконторы стали использовать e-mail, потери отдельного письма могут быть череваты.

Возможно, что это мой личный батхерт против нескольких SMTP, просто в одной конторе мне досталось в наследство заопарк из нескольких SMTP, которые гоняли прочту через друг-друга, в том числе и потому, что только на однин из них была куплена лицензия drweb. Железо было самое дешёвое и глючило, получалось, что уж лучше бы сделали один smtp-сервер за нормальные деньги чем эту кучу Г.

было дело, принимал похожее хозяйство, по итогу все переделал на 3 физических сервера - вход, исход и хранилище

в теории вход и исход можно было бы и объеденить, а на практике оказалось, что таки решение было правильно, исход слишком часто попадал в днсбл

Да, но SMTP-сервер должен где-то хранить почту

lmtp на сосдений «дисковый» сервер с мда (:

+ если транспорты достаются из какойто базы динамически, то и не надо обновлять конфиги при каждом изменении маршрутов