The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

"Помогите продумать схему для почтовой системы"  +/
Сообщение от netc email(??) 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 email(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 email(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 email(ok) on 25-Янв-10, 12:12 
Мне больше нравится вариант 3.
В фильтрации спама есть два подхода: принимать всё, а потом анализировать, либо анализировать в ходе SMTP-сеанса. Второй предпочтительнее, поэтому спам-фильтр надо прикручивать к тому MTA, к которому непосредственно коннектится отправитель. А если так, то лучше иметь либо два полноценных MTA на каждом гейте, которые фильтруют входящую почту (при этом либо юзают один на двоих фильтрующий демон, либо у каждого свой, но с общей базой Bayes в SQL), а потом передают её внутреннему MTA для распихивания в майлбоксы. Иметь один внутренний МТА удобно в том отношении, что он постоянно прописан на всех персоналках, а в случае каких-то событий (канал упал/поднялся, подключились к новому провайдеру) всё меняется на нём, плюс можно на нём сделать спам-фильтр с другими настройками (спам-фильтр исходящей почты обязателен, иначе вы рискуете при заражении одного компа оказаться на сутки во всех чёрных списках).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Помогите продумать схему для почтовой системы"  +/
Сообщение от netc email(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 email(ok) on 26-Янв-10, 11:31 
>[оверквотинг удален]
>>как считаете?
>>
>>>плюс можно на нём
>>>сделать спам-фильтр с другими настройками (спам-фильтр исходящей почты обязателен, иначе >вы
>>
>>тоже бейсов ? и тут вот интересно к какой его базе sql
>>к отдельной тоже с репликацией или можно одну вообще на всех
>>держать?
>
>не много ли для 20 пользователей заморочек?

да, мне и самому так начинает казаться ;(
но хочется сделать почту надежной и качественной

может пойти по пути наименьшего сопротивления т.е. выбрать вариант 2

тогда вопрос как все таки отправлять и получать почту.

получиться ли так настроить один единственный виртуальный(в vm) почтовый сервер

вот тут я описал в чем мне видится проблема с одним единственным mta
https://www.opennet.ru/openforum/vsluhforumID1/87918.html#1

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Помогите продумать схему для почтовой системы"  +/
Сообщение от Alan Makoev email(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 email(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 email(ok) on 26-Янв-10, 17:42 
>для исходящей?

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Вот как считаете если допустим на SMTP сделать авторизацию для отправки почты, откуда вирус спамбот узнает логин/пароль? Разве что украдет? - Но это мне кажется для него не будет легкой задачей. Ну да на счет сессий а также всевозможного "брутфорса" можно и позаботиться конечно, будет не лишним. А так в целом согласен. Но может я в чем не прав ?

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Если честно, я не очень в курсе, как организовано взаимодействие разных MUA с программами, которые хотят отправить почту, но у меня сильное подозрение, что спамбот может через соответствующий API рассылать сообщения через MUA, в котором сохранены все необходимые пароли. Например, у SpamAssassin'а есть правила, нацеленные на отлов сообщений, отправленных Outlook и Outlook Express - насколько я понимаю, бот просто передаёт им тело письма и адрес, а остальное они делают за него :)).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Помогите продумать схему для почтовой системы"  +/
Сообщение от netc email(??) on 26-Янв-10, 15:24 
>обойтись меньшим количеством телодвижений при переходе с одного канала на другой.

с входящей почтой почти все ясно, есть две mx записи на разные ip

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

а вот при двух МТА вообще ни чего трогать не нужно будет да?

или какие могут быть еще телодвижения?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Разные записи есть, но когда пакет придёт на вторичный шлюз, тот прокинет его во внутреннюю сетку к MTA, а тот отправит ответный пакет по своему дефолтному маршруту, в результате к удалённому хосту придёт пакет с src-IP вашего основного шлюза, а он отправлял - на вторичный.
При двух MTA надо будет внутреннему MTA указать другой адрес форвардера.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "Помогите продумать схему для почтовой системы"  +/
Сообщение от netc email(??) on 27-Янв-10, 13:31 
>Разные записи есть, но когда пакет придёт на вторичный шлюз, тот прокинет
>его во внутреннюю сетку к MTA, а тот отправит ответный пакет
>по своему дефолтному маршруту, в результате к удалённому хосту придёт пакет
>с src-IP вашего основного шлюза, а он отправлял - на вторичный.

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

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


>При двух MTA надо будет внутреннему MTA указать другой адрес форвардера.

А можно поподробнее с этого момента, ну пожалуйста. Совсем не понимаю что это может значить на деле ;(

Спасибо за помощь!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Помогите продумать схему для почтовой системы"  +/
Сообщение от Alan Makoev email(ok) on 28-Янв-10, 18:42 
> А можно поподробнее с этого момента

"Нормальный" MTA поступает с письмом так: берёт доменную часть адреса и ищёт для неё в DNS MX-запись. Если такой нет - ищет A-запись (т.е. просто IP-адрес).
Если есть MX-запись (или, при её отсутствии, A-запись) - коннектится к полученному IP на 25 порт и передаёт ему письмо. Если нет, или подключиться не может - отбивает сообщение об ошибке.
В некоторых случаях это не нужно (например, если это файл/SQL/http/... сервер, на котором MTA нужен только для того, чтобы репорты на мэйл админа скидывать), тогда на MTA прописывают адрес форвардера (полноценного MTA), которому данный урезанный MTA будет передавать всю почту, а тот уже будет отправлять её по назначению.


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Помогите продумать схему для почтовой системы"  +/
Сообщение от iasb email(??) 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ообщить модератору

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

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




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру