LINUX.ORG.RU
ФорумAdmin

«кэширование» почтового сервера


0

0

Хотя заголовок не совсем корректный - попытаюсь изложить суть проблемы:

Есть домен DOMEN.RU, хостится у провайдера (внешняя машина где-то там в инете, на ней есть почтовый сервер).

Есть офис - небольшой (машин 30), но там очень интенсивный почтовый трафик (бывает и под гиг на одного юзера, такова специфика конторы, почти все письма - несколько мегабайт аттачей).

Все эти юзеры в нет ходят через гейт, на гейте - debian/linux, много чего (к теме не относится) + настроенный exim & imap4d (это можно поменять на то что нужно).

Задача - почту которую юзеры шлют друг другу (на DOMEN.RU), доставлять не через внешний почтовый сервер - а через внутренний, и что бы они с внутреннего ее и забирали (ради экономии трафика).
Какое идеологически правильное решение посоветуете ?

(блин, чертово форматирование сбилось)

Есть домен DOMEN.RU, хостится у провайдера (внешняя машина где-то там в инете, на ней есть почтовый сервер).

Есть офис - небольшой (машин 30), но там очень интенсивный почтовый трафик (бывает и под гиг на одного юзера, такова специфика конторы, почти все письма - несколько мегабайт аттачей).

Все эти юзеры в нет ходят через гейт, на гейте - debian/linux, много чего (к теме не относится) + настроенный exim & imap4d (это можно поменять на то что нужно).

Задача - почту которую юзеры шлют друг другу (на DOMEN.RU), доставлять не через внешний почтовый сервер - а через внутренний, и что бы они с внутреннего ее и забирали (ради экономии трафика). Какое идеологически правильное решение посоветуете ?

anonizmus
() автор топика
Ответ на: комментарий от anonizmus

Хостить почтовик домена локально.

Варианты:

1. С провайдером договориться о соответствующих MX-записях в DNS и хостить почтовик самим, нафиг. Самое правильное решение в данном случае, если не коммутируемое соединение.

2. Договориться с провайдером о релее почты через их почтовик в обе стороны (т.е., если к ним приходит почта на ваш домен, они сразу кидают на ваш почтовик, а с вашего почтовика на их почтовик релеится только почта, уходящая наружу). Плюсы: DNS менять не нужно. Минусы: нужно менять настройки провайдерского почтовика, на что не каждый провайдер согласится, наверно.

3. Если не трогать настройки провайдера, то можно сделать так. Забирать почту с сервака провайдера на локальный fetchmail'ом по расписанию для всех пользователей. Внутренний сервак считает, что он хостит ваш почтовый домен, но всю почту наружу релеит через почтовик провайдера (возможно, на почтовике провайдера придётся завести фиктивный аккаунт для этого). Плюсы: провайдер в этом деле не участвует (кроме, возможно, заведения фиктивного аккаунта), работает для коммутируемых соединений. Минусы: возможные грабли с имеющимися настройками почтовика провайдера, но это для дерьмовых провайдеров. Я с ROL примерно по такой схеме нормально работал.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от anonizmus

Да просто укажи в почтовике на локальном гейте domain.ru в качестве локального, внутрення почта наружу уходить не будет. С удаленного почту каким-то образом все равно нужно забирать, не нравится fetchmail, напиши свой скрипт на perl :)

chucha ★★★☆
()
Ответ на: комментарий от watashiwa_daredeska

watashiwa_daredeska, санкс за ответ, вариант 2 попробую.

А хостить локально - это конечно лучше всего, только все таки у провайдера - надежнее, там дуальный зеон выделенный, и в датацентре постоянно поддержка, и канал не эти жалкие 2 мегабита что тут, и на трафик - наплевать (пусть лучше к ним валятся эти тонны нетская и прочего - и пусть их машина с этим борется %-)

anonizmus
() автор топика
Ответ на: комментарий от anonizmus

Локальную почту и хостить нужно локально. Для исходящей (SMTP), например у sendmail есть такое понятие, как smarthost, т.е. локальная почта пересылается локально, внешняя уходит на сервер провайдера. Для входящей (POP3), не могу сказать точно, но вроде http://www.remote.org/jochen/mail/popular/ POP3 сервер с несколькими бакендами.

qwe ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.