URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 14241
[ Назад ]

Исходное сообщение
"Организация почтовой службы"

Отправлено kostya , 06-Мрт-02 02:43 
Я прошу людей, имеющих опыт построения почтовых служб для крупных _некоммерческих_ организаций (типа институтов или университетов)) поделиться своим опытом. Интересуют прежде всего различные грабли, причем не только технического характера, но и административного.

Содержание

Сообщения в этом обсуждении
"RE: Организация почтовой службы"
Отправлено nik , 06-Мрт-02 08:29 
>Я прошу людей, имеющих опыт построения
>почтовых служб для крупных _некоммерческих_
>организаций (типа институтов или университетов))
>поделиться своим опытом. Интересуют прежде
>всего различные грабли, причем не
>только технического характера, но и
>административного.

Напиши на мыло, отвечу. Держу Институт Неорганической Химии СО РАН.


"RE: Организация почтовой службы"
Отправлено lavr , 06-Мрт-02 14:32 
>>Я прошу людей, имеющих опыт построения
>>почтовых служб для крупных _некоммерческих_
>>организаций (типа институтов или университетов))
>>поделиться своим опытом. Интересуют прежде
>>всего различные грабли, причем не
>>только технического характера, но и
>>административного.
>
>Напиши на мыло, отвечу. Держу Институт
>Неорганической Химии СО РАН.

О-о-о! Наши в городе :)

Попробуй написать на postmaster@jinr.ru или
noc@jinr.ru (Объединенный Институт Ядерной Физики)
Дубна. /Лучше сослаться что lavr порекомендовал/

собственно советы простые:

non-commerce way:

- единый mail-hub который держит ВСЮ почту,
почтовые account'ы либо в mysql, либо сбоку
через pam_pwdfile, либо ldap

- сервер конечно же без login-shell'ов

Все остальное зависит от выбранного средства авторизации - выбор MTA

commerce way:

- CommuniGate Pro и все забудешь (~2500$) и
забываешь о всех проблемах

ни в коем случае не делать

*.domain.    MX   1   mailhub.domain.

и ни в коем случае не релеить внутри по IP вместо
MX (старая релкомовская технология :()

Лучше правильно вести DNS и ставить MX'ы на
те машины внутри где будут висеть MTA и куда
mailhub будет форвардить письма пользователей
заведенных с форвардом. Но при этом зарезать в
firewall всю сеть на tcp_port=25 и оставить только
mailhub, например:

        MX   1   mailhub.domain.

division1    A     ip.address
        MX   1   division1.domain.
        MX   10  mailhub.domain.

division2    A     ip.address
        MX   1   division2.domain.
        MX   10  mailhub.domain.

и тд и тп для внутренних машин с MTA, тогда
извне MTA будут пытаться соединяться с
теми у кого меньший вес, получать отлуп и валить
ВСЕ на mailhub (это удачно для переходного периода), ну и вообще лучше маскарадить домен.

снаружи фильтруются 110(POP3) и 143(IMAP) и
вместо них отдаются 995(POP3/SSL) и 993(IMAP/SSL),
а внутри можно и то и другое.

Где-то так для основных моментов.


"RE: Организация почтовой службы"
Отправлено kostya , 07-Мрт-02 02:58 
Hi!

>О-о-о! Наши в городе :)
>
>Попробуй написать на postmaster@jinr.ru или
>noc@jinr.ru (Объединенный Институт Ядерной Физики)
>Дубна. /Лучше сослаться что lavr порекомендовал/
>
>
>собственно советы простые:
>
>non-commerce way:
>
>- единый mail-hub который держит ВСЮ
>почту,
>почтовые account'ы либо в mysql, либо
>сбоку
>через pam_pwdfile, либо ldap
>
>- сервер конечно же без login-shell'ов
>
>
>Все остальное зависит от выбранного средства
>авторизации - выбор MTA
>
>commerce way:
>
>- CommuniGate Pro и все забудешь
>(~2500$) и
>забываешь о всех проблемах
>
>ни в коем случае не делать
>
>
>*.domain. MX   1  
> mailhub.domain.
>
>и ни в коем случае не
>релеить внутри по IP вместо
>
>MX (старая релкомовская технология :()
>
>Лучше правильно вести DNS и ставить
>MX'ы на
>те машины внутри где будут висеть
>MTA и куда
>mailhub будет форвардить письма пользователей
>заведенных с форвардом. Но при этом
>зарезать в
>firewall всю сеть на tcp_port=25 и
>оставить только
>mailhub, например:

Ничче не понял :) Можно еще раз и...чуть-чуть более по-русски :)

>
>  MX   1
>  mailhub.domain.
>
>division1 A  ip.address
>  MX   1
>  division1.domain.
>  MX   10
> mailhub.domain.
>
>division2 A  ip.address
>  MX   1
>  division2.domain.
>  MX   10
> mailhub.domain.
>
>и тд и тп для внутренних
>машин с MTA, тогда
>извне MTA будут пытаться соединяться с
>
>теми у кого меньший вес, получать
>отлуп и валить
>ВСЕ на mailhub (это удачно для
>переходного периода), ну и вообще
>лучше маскарадить домен.
>
>снаружи фильтруются 110(POP3) и 143(IMAP) и
>
>вместо них отдаются 995(POP3/SSL) и 993(IMAP/SSL),
>
>а внутри можно и то и
>другое.
>
>Где-то так для основных моментов.

правильно ли я понял твою мысль, что division1.domain1.ru port 25 и division2.domain.ru port 25 закрыты фаерволом, почта валится на второй MX, а он их пробрасывает куда надо, ибо для него проковырена в файрволах дырочка.

Если я правильно тебя понял, то...к чему, собственно, такие сложности? Какие доводы разума в пользу такой схемы?


"RE: Организация почтовой службы"
Отправлено Kristo , 07-Мрт-02 17:10 
http://matt.simerson.net/computing/mail/toaster/

посмотри вот тут, я ставил, мне очень понравилось


"RE: Организация почтовой службы"
Отправлено lavr , 07-Мрт-02 22:11 
>Ничче не понял :) Можно еще
>раз и...чуть-чуть более по-русски :)

прочитал - все строго, прозрачно и именно
по-русски

>>
>>  MX   1
>>  mailhub.domain.
>>
>>division1 A  ip.address
>>  MX   1
>>  division1.domain.
>>  MX   10
>> mailhub.domain.
>>
>>division2 A  ip.address
>>  MX   1
>>  division2.domain.
>>  MX   10
>> mailhub.domain.
>>
>>и тд и тп для внутренних
>>машин с MTA, тогда
>>извне MTA будут пытаться соединяться с
>>
>>теми у кого меньший вес, получать
>>отлуп и валить
>>ВСЕ на mailhub (это удачно для
>>переходного периода), ну и вообще
>>лучше маскарадить домен.
>>
>>снаружи фильтруются 110(POP3) и 143(IMAP) и
>>
>>вместо них отдаются 995(POP3/SSL) и 993(IMAP/SSL),
>>
>>а внутри можно и то и
>>другое.
>>
>>Где-то так для основных моментов.
>
>правильно ли я понял твою мысль,
>что division1.domain1.ru port 25 и
>division2.domain.ru port 25 закрыты фаерволом,
>почта валится на второй MX,
>а он их пробрасывает куда
>надо, ибо для него проковырена
>в файрволах дырочка.
>
>Если я правильно тебя понял, то...к
>чему, собственно, такие сложности? Какие
>доводы разума в пользу такой
>схемы?

еще раз:

1) вариант настройки с уже работающим mail-service
2) вариант настройки с НУЛЯ

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

Мой совет был - маскарадить домен, типа:

anyuser@mydomain.ru
или
FirstName.LastName@mydomain.ru

что прийти к единому знаменателю и единому mailhub'у

В случае первого варианта, письма один хрен буду
сперва валиться на user@subdomain.mydomain.ru

Вот это и надо учесть, что здесь непонятного и
что здесь не по-русски, прочитай еще раз предыдущую статью, там все четко.

Так вот чтобы MTA извне не отсылала напрямую почту
для pupkin@subdomain.mydomain.ru через MX для
subdomain.mydomain.ru а лишь через mailhub, и
надо отрезать 25 порт извне всем кроме mailhub.

Если с нуля то сделать почту ТОЛЬКО на mailhub,
MX'ы для остальных по желанию и с учетов варианта
1.


"RE: Организация почтовой службы"
Отправлено lavr , 07-Мрт-02 22:30 
суть:

есть mailhub один или разнесенный и маскарадится
домен. Тогда ТЫ контролируешь ВСЮ входящую и ВСЮ
выходящую почту, при закрытом 25'ом порте ВСЕМ кроме mailhub. Это не ради перлюстрации и личных
амбиций, а ради порядка и возможности в любой
момент посмотреть КТО, ЧТО, ОТКУДА, КУДА и принять
меры и иметь возможность фильтровать СПАМ, ВИРУСЫ
- не только отвечать за свои действия, но и иметь
возможность за них отвечать!

Почему mailhub и желательно без остальных MX -
пример:

    IN    MX  1    mydomain.ru.
    IN    MX  30  myoutsidesecondary.ru.
...
это ВСЕ больше хрен, тогда СПАМ и ВИРУСЫ ты ловишь
только в одном месте!

Если открыт 25 порт на всю сеть или даже
еще MX, то СПАМ ты один хрен получаешь!
Почему, да потому чтА ты будешь пропускать
письма через себя на другие MX в твоей зоне,
открыт ли 25 порт, закрыт ли, понятно почему!?

Если нет - я пас.

PS. Почему я предлагал оставлять MX на другие
внутренние релеи при внедрении новой технологии,
да потому-что переходный период и письма будут
сыпать на старые адреса pupkin@sub1.sub2.mydomain
вместо pupkin@mydomain. Пройдет три месяца или
полгода, MX'ы можно истребить. Вроде теперь
разжовано дальше некуда.