форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Открытые системы на сервере (Public)
Изначальное сообщение		[ Отслеживать ]

"Помогите продумать схему для почтовой системы"		+/–
Сообщение от netc (??) on 21-Янв-10, 12:04
Посоветуйте пожалуйста как организовать почтовую систему для организации. Исходные данные: 1. Шлюз интернет с ОС FreeBSD находиться в первом здании, подключен через ADSL 2 Mb/s, первый провайдер 2. Шлюз интернет с ОС FreeBSD находиться во втором здании, подключен через ADSL 8 Mb/s, второй провайдер 3. VDSL Модем между зданиями ~ 30-40 Mb/s Помимо почты по VDSL линии будут ходить пакеты от AD, DNS, SMB, FTP ну все как обычно. Внутри ЛВС пользователи должны работать с почтой по протоколу IMAP. Почтовых аккаунтов будет ~ 20. В корневых DNS будет: MX 10 mx1.domain.ru шлюз1 MX 20 mx2.domain.ru шлюз2 С этим думаю понятно, чего я хочу. В качестве почтового(ых) сервера(ов) будет использоваться zimbra, выбор руководителя. Основной вопрос как сделать? 1. Вариант 1. На шлюзе 1 делаем проброс портов на виртуальный сервер 1 с MTA. На шлюзе 2 делаем проброс портов на виртуальный сервер 2 с MTA. Они соответственно складывают почту на отдельный виртуальный сервер хранилище, откуда пользователи по IMAP работают с почтой. Для отправки почты пользователи связываются с одним из MTA, например с 1-ым. 2. Вариант 2. На шлюзе 1 и шлюзе 2 делаем проброс портов на один виртуальный сервер с MTA и хранилищем почты. Пользователи работают только с ним. Всего для организации почтовой системы используется один сервер. 3. Вариант 3. На шлюзе 1 шлимылом делаем проброс почты на один виртуальный сервер с MTA. На шлюзе 2 шлимылом делаем проброс почты на тот же виртуальный сервер с MTA. 4. Вариант 4. Пробросить линию подходящую к шлюзу 2 в серверную к шлюзу 1 (тех. возм. есть). Таким образом сделать один шлюз. Оправдано с точки зрения экономии. На этом шлюзе сделать проброс портов и трафика с внешних ip на один внутренний почтовый сервер. 5. Вариант 5. Пробросить линию подходящую к шлюзу 2 в серверную к шлюзу 1 (тех. возм. есть). Таким образом сделать один шлюз. Оправдано с точки зрения экономии. На этом шлюзе сделать проброс шлимылом сообщений с внешних ip на один внутренний почтовый сервер. 1. Как поступили бы вы? 2. Есть ли совсем неправильные варианты? 3. С точки зрения надежности какой из вариантов выбрали бы вы? 4. У руководителя есть мысль вынести почту в отдельные руки. Хотелось бы услышать Ваши "за и против. 5. Может бы у вас совсем иной взгляд на организацию почтовой системы в моей ситуации?
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Помогите продумать схему для почтовой системы"		+/–
Сообщение от Raduga on 21-Янв-10, 12:11
what does шлимылом mean
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	2. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от netc (ok) on 21-Янв-10, 12:21
	>what does шлимылом mean sendmail - mta, который будет использоваться для получения почты а затем ее пере направления на локальный mta сервер он также используется в вариантах (№3,5) где не используется простой проброс трафика с 25 внешнего порта на 25 порт внутреннего(внутренних) серверов. просто про шлимыло мне подсказал один умный товарищ, и сказал, что именно с ним будет сделать проще, правильней и лучше. конечно он очень хорошо знает sendmail, но он имел в виду просто обычный mta то есть это не обязательно должен быть sendmail. другими словами использовать не проброс портов а проброс писем используя пограничный (на шлюзе) mta. он еще кстати был против пробросов портов в варианте 1, т.к. он сказал, что входящие пакеты (с ними письма) я пробросить то проброшу, а вот как быть с исходящими он не знает и я соответственно тоже не знаю. к тому, же я более его не увижу в ближайшее время, а мне нужно решить этот вопрос чем скорее тем лучше. поэтому собственно и завел тему.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от Golub Mikhail (ok) on 21-Янв-10, 13:29
	>[оверквотинг удален] >шлюзе) mta. > >он еще кстати был против пробросов портов в варианте 1, т.к. он >сказал, что входящие пакеты (с ними письма) я пробросить то проброшу, >а вот как быть с исходящими он не знает >и я соответственно тоже не знаю. > >к тому, же я более его не увижу в ближайшее время, а >мне нужно решить этот вопрос чем скорее тем лучше. поэтому собственно >и завел тему. Использовать третий почтовик, который будет принимать письма от граничных серверов. На нем же и база с письмами. Отправка с локальной сети через тот третий почтовик, который роутит на граничный MTA, где канал шире. А если надо отслеживать падение одного из каналов в Инет и в зависимости от этого менять граничный MTA для отправки - поищите по форуму ...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от netc (ok) on 21-Янв-10, 13:42
	>Использовать третий почтовик, который будет принимать письма от граничных серверов. 1. почему третий потому, что если шлюзов будет два да?(да/нет) а если я обе линии adsl заведу в один шлюз 2. то у меня будет два mta один пограничный т.е. на шлюзе второй внутри локалки?(да/нет) >На нем же и база с письмами. ага с этим понятно >Отправка с локальной сети через тот третий почтовик, который роутит на граничный >MTA, где канал шире. с этим тоже ясно >А если надо отслеживать падение одного из каналов в Инет и в >зависимости от этого менять граничный MTA для отправки - поищите по >форуму ... думаю это отдельная тема, разберемся позднее в связи с чем еще вопрос: 3. то есть вы советуете вариант 3 или 5 в зависимости от того, сколько шлюзов я оставлю это понятно. но лично мне не понятен остается один вопрос: можно ли обойтись без пограничного(ых) mta на шлюзе(ах) ? и как если можно ? хотелось бы сделать проще
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от Golub Mikhail (ok) on 22-Янв-10, 19:00
	>[оверквотинг удален] >3. то есть вы советуете вариант 3 или 5 в зависимости от >того, сколько шлюзов я оставлю >это понятно. > >но лично мне не понятен остается один вопрос: можно ли обойтись без >пограничного(ых) mta на шлюзе(ах) ? > >и как если можно ? > >хотелось бы сделать проще Можно, как написали: "а если я обе линии adsl заведу в один шлюз 2. то у меня будет два mta один пограничный т.е. на шлюзе второй внутри локалки?(да/нет)" Только если обе линии будут заходить на один шлюз, то можно обойтись и одним MTA.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Помогите продумать схему для почтовой системы"		+/–
Сообщение от Alan Makoev (ok) on 25-Янв-10, 12:12
Мне больше нравится вариант 3. В фильтрации спама есть два подхода: принимать всё, а потом анализировать, либо анализировать в ходе SMTP-сеанса. Второй предпочтительнее, поэтому спам-фильтр надо прикручивать к тому MTA, к которому непосредственно коннектится отправитель. А если так, то лучше иметь либо два полноценных MTA на каждом гейте, которые фильтруют входящую почту (при этом либо юзают один на двоих фильтрующий демон, либо у каждого свой, но с общей базой Bayes в SQL), а потом передают её внутреннему MTA для распихивания в майлбоксы. Иметь один внутренний МТА удобно в том отношении, что он постоянно прописан на всех персоналках, а в случае каких-то событий (канал упал/поднялся, подключились к новому провайдеру) всё меняется на нём, плюс можно на нём сделать спам-фильтр с другими настройками (спам-фильтр исходящей почты обязателен, иначе вы рискуете при заражении одного компа оказаться на сутки во всех чёрных списках).
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от netc (ok) on 26-Янв-10, 10:29
	>[оверквотинг удален] >либо у каждого свой, но с общей базой Bayes в SQL), >а потом передают её внутреннему MTA для распихивания в майлбоксы. Иметь >один внутренний МТА удобно в том отношении, что он постоянно прописан >на всех персоналках, а в случае каких-то событий (канал упал/поднялся, подключились >к новому провайдеру) всё меняется на нём, плюс можно на нём >сделать спам-фильтр с другими настройками (спам-фильтр исходящей почты обязателен, иначе вы >рискуете при заражении одного компа оказаться на сутки во всех чёрных >списках). >А если так, то >лучше иметь либо два полноценных MTA на каждом гейте но ведь в принципе можно и один сервер с одним MTA, просто тогда все будет завязано на одну машину, что не есть гуд с точки зрения надежности - слегла машина - слегла почта >при этом либо юзают один на двоих фильтрующий демон, >либо у каждого свой, но с общей базой Bayes в SQL а если делать для каждого свою базу sql, то можно ли и нужно ли их синхронизировать и если "да", то чем ? планирую postgre использовать я имею в виду у postgre есть ведь PGCluster, slony-I, Bucardo для синхронизации есть master-master, есть master-slave как считаете? >плюс можно на нём >сделать спам-фильтр с другими настройками (спам-фильтр исходящей почты обязателен, иначе >вы тоже бейсов ? и тут вот интересно к какой его базе sql к отдельной тоже с репликацией или можно одну вообще на всех держать?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от A Clockwork Orange on 26-Янв-10, 11:22
	>[оверквотинг удален] >синхронизации >есть master-master, есть master-slave >как считаете? > >>плюс можно на нём >>сделать спам-фильтр с другими настройками (спам-фильтр исходящей почты обязателен, иначе >вы > >тоже бейсов ? и тут вот интересно к какой его базе sql >к отдельной тоже с репликацией или можно одну вообще на всех >держать? не много ли для 20 пользователей заморочек?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от netc (ok) on 26-Янв-10, 11:31
	>[оверквотинг удален] >>как считаете? >> >>>плюс можно на нём >>>сделать спам-фильтр с другими настройками (спам-фильтр исходящей почты обязателен, иначе >вы >> >>тоже бейсов ? и тут вот интересно к какой его базе sql >>к отдельной тоже с репликацией или можно одну вообще на всех >>держать? > >не много ли для 20 пользователей заморочек? да, мне и самому так начинает казаться ;( но хочется сделать почту надежной и качественной может пойти по пути наименьшего сопротивления т.е. выбрать вариант 2 тогда вопрос как все таки отправлять и получать почту. получиться ли так настроить один единственный виртуальный(в vm) почтовый сервер вот тут я описал в чем мне видится проблема с одним единственным mta http://www.opennet.dev/openforum/vsluhforumID1/87918.html#1
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от Alan Makoev (ok) on 26-Янв-10, 17:10
	>не много ли для 20 пользователей заморочек? Многовато :)) Просто при схеме с одним MTA во внутренней сетке (к которому форвардятся пакеты на 25 порт от обоих шлюзов) при смене канала придётся: 1. поменять в ДНС MX-запись для домена, которая при такой схеме будет только одна (если на MTA просто прописан маршрут через основной канал), ждать час (обычное значение для "expires") пока новые данные сменят в кэшах старые. 2. Поменять в настройках MTA имя, с которым он представляется в SMTP-команде HELO (оно должно совпадать с PTR-записью для внешнего IP-адреса шлюза) 3. Поменять маршрутизацию на хосте, где живёт MTA. Больше всего времени требует внесение изменений в ДНС, хорошо если ваш DNS не зависит от состояния ваших каналов и вы можете его быстро поменять (например, через web-интерфейс, если вы юзаете DNS от RU-Center или что-то типа того) Это всё, вобщем-то, несложно, но если с канала на канал приходится перескакивать часто - напрягает.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от Alan Makoev (ok) on 26-Янв-10, 14:48
	Один хост с пробросом 25 порта от обоих шлюзов - это вполне работоспособная конфигурация, просто схема с отдельными MTA на каждом входе позволят обойтись меньшим количеством телодвижений при переходе с одного канала на другой. По поводу репликации базы SQL - не могу подсказать, у меня 1 SQL-сервер, попробовать более хитрую схему руки не доходят, но можете прочитать про один эпизод здесь: http://some-wise-man.livejournal.com/141266.html Bayes для исходящей почты нужен, а вот сетевые тесты (проверку в чёрных списках DNS) можно убрать - ничего, кроме лишней нагрузки и задержек они не дадут.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Помогите продумать схему для почтовой системы"		+1 +/–
	Сообщение от A Clockwork Orange on 26-Янв-10, 15:05
	>Один хост с пробросом 25 порта от обоих шлюзов - это вполне >работоспособная конфигурация, просто схема с отдельными MTA на каждом входе позволят >обойтись меньшим количеством телодвижений при переходе с одного канала на другой. > >По поводу репликации базы SQL - не могу подсказать, у меня 1 >SQL-сервер, попробовать более хитрую схему руки не доходят, но можете прочитать >про один эпизод здесь: http://some-wise-man.livejournal.com/141266.html >Bayes для исходящей почты нужен, для исходящей? >а вот сетевые тесты (проверку в чёрных >списках DNS) можно убрать - ничего, кроме лишней нагрузки и задержек >они не дадут.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от Alan Makoev (ok) on 26-Янв-10, 17:42
	>для исходящей? Да. Вначале всегда кажется - у нас антивирус, у нас флешки запрещены, у нас доступ в Интернет только по служебкам, у нас вообще всё закрыто, а потом откуда-то всё-таки появляется спамбот, который начинает рассылать спам. Кстати, поэтому на внутреннем MTA тоже надо ставить ограничение на число одновременных соединений и троттлинг (представьте себе, сколько сообщений он запихнёт в очередь MTA, прежде чем кто-то что-то заметит).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от netc (??) on 27-Янв-10, 13:37
	>>для исходящей? > >Да. Вначале всегда кажется - у нас антивирус, у нас флешки запрещены, >у нас доступ в Интернет только по служебкам, у нас вообще >всё закрыто, а потом откуда-то всё-таки появляется спамбот, который начинает рассылать >спам. Кстати, поэтому на внутреннем MTA тоже надо ставить ограничение на >число одновременных соединений и троттлинг (представьте себе, сколько сообщений он запихнёт >в очередь MTA, прежде чем кто-то что-то заметит). Вот как считаете если допустим на SMTP сделать авторизацию для отправки почты, откуда вирус спамбот узнает логин/пароль? Разве что украдет? - Но это мне кажется для него не будет легкой задачей. Ну да на счет сессий а также всевозможного "брутфорса" можно и позаботиться конечно, будет не лишним. А так в целом согласен. Но может я в чем не прав ? По идее то на всех шлюзах к внешним smtp пропускаем тока почтовик, другие тачки записываем и периодически проверяем логи фаера, или вообще делаем немедленное уведомление на почту
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от Alan Makoev (ok) on 28-Янв-10, 18:57
	>Вот как считаете если допустим на SMTP сделать авторизацию для отправки почты, >откуда вирус спамбот узнает логин/пароль? Разве что украдет? - Но это >мне кажется для него не будет легкой задачей. Ну да на >счет сессий а также всевозможного "брутфорса" можно и позаботиться конечно, будет >не лишним. А так в целом согласен. Но может я в >чем не прав ? > >По идее то на всех шлюзах к внешним smtp пропускаем тока почтовик, >другие тачки записываем и периодически проверяем логи фаера, или вообще делаем >немедленное уведомление на почту Если честно, я не очень в курсе, как организовано взаимодействие разных MUA с программами, которые хотят отправить почту, но у меня сильное подозрение, что спамбот может через соответствующий API рассылать сообщения через MUA, в котором сохранены все необходимые пароли. Например, у SpamAssassin'а есть правила, нацеленные на отлов сообщений, отправленных Outlook и Outlook Express - насколько я понимаю, бот просто передаёт им тело письма и адрес, а остальное они делают за него :)).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от netc (??) on 26-Янв-10, 15:24
	>обойтись меньшим количеством телодвижений при переходе с одного канала на другой. с входящей почтой почти все ясно, есть две mx записи на разные ip т.е. при одном хосте с MTA мне нужно будет перенастраивать основной шлюз каждый в зависимости от того, где есть инет и через какой шлюз я хочу отправлять почту. а вот при двух МТА вообще ни чего трогать не нужно будет да? или какие могут быть еще телодвижения?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от Alan Makoev (ok) on 26-Янв-10, 17:37
	>[оверквотинг удален] >ip > >т.е. при одном хосте с MTA мне нужно будет перенастраивать основной шлюз >каждый в зависимости от того, где есть инет и через какой >шлюз я хочу отправлять почту. > >а вот при двух МТА вообще ни чего трогать не нужно будет >да? > >или какие могут быть еще телодвижения? Разные записи есть, но когда пакет придёт на вторичный шлюз, тот прокинет его во внутреннюю сетку к MTA, а тот отправит ответный пакет по своему дефолтному маршруту, в результате к удалённому хосту придёт пакет с src-IP вашего основного шлюза, а он отправлял - на вторичный. При двух MTA надо будет внутреннему MTA указать другой адрес форвардера.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от netc (??) on 27-Янв-10, 13:31
	>Разные записи есть, но когда пакет придёт на вторичный шлюз, тот прокинет >его во внутреннюю сетку к MTA, а тот отправит ответный пакет >по своему дефолтному маршруту, в результате к удалённому хосту придёт пакет >с src-IP вашего основного шлюза, а он отправлял - на вторичный. С этим согласен, а можно ли как нибудь заставить систему работать как бы с двумя шлюзами? Просто практически возможна такая конфигурация как вы считаете ? Ну думаю вы меня поняли Или это полный бред - такое невозможно, сейчас даже мне кажется это невозможным Или же это лишнее нагромождение в любом случае получиться и стоит все таки остановиться на варианте с тремя MTA >При двух MTA надо будет внутреннему MTA указать другой адрес форвардера. А можно поподробнее с этого момента, ну пожалуйста. Совсем не понимаю что это может значить на деле ;( Спасибо за помощь!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "Помогите продумать схему для почтовой системы"		+/–
	Сообщение от Alan Makoev (ok) on 28-Янв-10, 18:42
	> А можно поподробнее с этого момента "Нормальный" MTA поступает с письмом так: берёт доменную часть адреса и ищёт для неё в DNS MX-запись. Если такой нет - ищет A-запись (т.е. просто IP-адрес). Если есть MX-запись (или, при её отсутствии, A-запись) - коннектится к полученному IP на 25 порт и передаёт ему письмо. Если нет, или подключиться не может - отбивает сообщение об ошибке. В некоторых случаях это не нужно (например, если это файл/SQL/http/... сервер, на котором MTA нужен только для того, чтобы репорты на мэйл админа скидывать), тогда на MTA прописывают адрес форвардера (полноценного MTA), которому данный урезанный MTA будет передавать всю почту, а тот уже будет отправлять её по назначению.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Помогите продумать схему для почтовой системы"		+/–
Сообщение от iasb (??) on 28-Янв-10, 22:09
>Посоветуйте пожалуйста как организовать почтовую систему для организации. > >Исходные данные: > >1. Шлюз интернет с ОС FreeBSD находиться в первом здании, подключен через >ADSL 2 Mb/s, первый провайдер ОК  сетка 1 >2. Шлюз интернет с ОС FreeBSD находиться во втором здании, подключен через >ADSL 8 Mb/s, второй провайдер ОК  сетка 2 >3. VDSL Модем между зданиями ~ 30-40 Mb/s > VPN  маршрутизация между сетками 1 и 2. И как она предполагается ? Это можно только если во Фре - по 3 сетевых карты. И настраивать роутинг. Для первого раза - не такая и тривиальная задача. >Помимо почты по VDSL линии будут ходить пакеты от AD, DNS, SMB, >FTP ну все как обычно. ОК > >Внутри ЛВС пользователи должны работать с почтой по протоколу IMAP. Почтовых аккаунтов >будет ~ 20. > мало как-то на весь паровоз >В корневых DNS будет: >MX 10 mx1.domain.ru шлюз1 >MX 20 mx2.domain.ru шлюз2 > >С этим думаю понятно, чего я хочу. > ОК >В качестве почтового(ых) сервера(ов) будет использоваться zimbra, выбор руководителя. >Основной вопрос как сделать? > это внутристоящий сервак >1. Вариант 1. > >На шлюзе 1 делаем проброс портов на виртуальный сервер 1 с MTA. > >На шлюзе 2 делаем проброс портов на виртуальный сервер 2 с MTA. > все хорошо, но при пробросе портов может оказаться что пакеты, приходящие на внутренний сервак будут приходить от адресов внутренних интерфейсов, а не от истинных интернетовских IP >Они соответственно складывают почту на отдельный виртуальный сервер хранилище, откуда пользователи по >IMAP работают с почтой. Для отправки почты пользователи связываются с одним >из MTA, например с 1-ым. > Нет - с сервером, откуда читают, а он уже на бордеринговый сервак При этом бААльшим гемором будет антиспам >2. Вариант 2. >На шлюзе 1 и шлюзе 2 делаем проброс портов на один виртуальный >сервер с MTA и хранилищем почты. Пользователи работают только с ним. >Всего для организации почтовой системы используется один сервер. > Можно и так. Проблемы с анти-спамом. >3. Вариант 3. >На шлюзе 1 шлимылом делаем проброс почты на один виртуальный сервер с >MTA. >На шлюзе 2 шлимылом делаем проброс почты на тот же виртуальный сервер >с MTA. > Это лучше - антиспам на шлимыле организовывать, но это прийдется 2 тушки препарировать и база спам-обучения уменьшается в 2 раза >4. Вариант 4. >Пробросить линию подходящую к шлюзу 2 в серверную к шлюзу 1 (тех. >возм. есть). Таким образом сделать один шлюз. Оправдано с точки зрения >экономии. > >На этом шлюзе сделать проброс портов и трафика с внешних ip на >один внутренний почтовый сервер. > Нэ - это ближе к реальности, но нэ. >5. Вариант 5. >Пробросить линию подходящую к шлюзу 2 в серверную к шлюзу 1 (тех. >возм. есть). Таким образом сделать один шлюз. Оправдано с точки зрения >экономии. > >На этом шлюзе сделать проброс шлимылом сообщений с внешних ip на один >внутренний почтовый сервер. Это уже лучше. Более приемлимое решение. Вариант 6. 2 шлюза. Я бы их делал на железных маршрутизаторах. На 20 человек - да хоть Линксысы. Нет народа. Нечего выдумывать. внутри - 1 FreeBSD транспортный почтовый сервер - антиспам, 1-й ВПН, Сеть 1, NAT. 2-й  сервер - VPN, NAT, 2-я сеть. Итого сеть заработала. Железный маршрутизатор пробрасывает 25-е пакеты на анти-СПАМ, тот алиасами форвардит почту на внутренний сервер. >[оверквотинг удален] > >2. Есть ли совсем неправильные варианты? > >3. С точки зрения надежности какой из вариантов выбрали бы вы? > >4. У руководителя есть мысль вынести почту в отдельные руки. Хотелось бы >услышать Ваши "за и против. > >5. Может бы у вас совсем иной взгляд на организацию почтовой системы >в моей ситуации? iasb.narod.ru - в принципе эта схема - статьи по FreeBSD. На год написания не смотреть - идеология для данного случая не поменялась.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема