Псто не читал. Сколько ящиков? Если не очень много, вынесите всю почту на яндекс вместе с доменом.

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

Мой сервер должен забирать почту с почтовых ящиков хостера | ФИЛЬТРОВАТЬ | и отдавать эту почту локальным клиентам.

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

dada, вы неправильно поняли. я настраиваю новый сервер ДО почтовика, он принимает всё входящее, отсеивает спам. И с него же пользователи забирают почту без спама. Чтобы не менять настройки клиентов, я делаю подмену DNS в пункте 4.

как первый пункт будешь реализовывать?

Yur4eg, первый пункт буду реализовывать следующим образом (в первом приближении):

• Забирать почту с почтовика хостера буду через fetchmail с ящика sotrudnik-1@mycompany.ru и помещать в ящик локального сервера sotrudnik-1@mycompany.ru. И так для всех почтовых ящиков.
• Фильтровать почту. Пока не решил чем. Но это я решу в ходе экспериментов. В первую очередь мне нужно запрещать конкретные вложения в письмах. Так же сюда добавлю clamav.
• Клиентам почту буду отдавать через pop3 с помощью Dovecot. Хранить почту мне нужно лишь до получения ее клиентом.
• Отправка почты - наверно это будет проблемой. Внезапно.
  Я хотчу передавать письма через Postfix локального сервера на почтовик хостера (не знаю на сколько реально, чтобы отправителем был sotrudnik-1@mycompany.ru. Т.е. чтобы не происходила подмена адреса отправителя).

Собственно ради выяснения нюансов я и обратился к сообществу.
Пока это мой план на коленке, примериваюсь так сказать..

Не правильно ты, дядя Федор, бутерброд ешь

Свой МТА ставь «параллельно» хостеру. MX записями выставишь приоритеты по-вкусу. fetchmail пусть вытягивает с хостера и отдает почту локальному МТА.

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

ставь «параллельно» хостеру. MX записями выставишь приоритеты

Это добавить устойчивость системе. Если один из mx-ов упадет (твой или хостера) почта не потеряется.

Что значит «параллельно»? Т.е. мне придеться настраивать на локальном сервере «другие» почтовые ящики, в которых будет лежать почта после fetmail и фильтрации? Я не понял (( Объясните для тупых

Свой МТА ставь «параллельно» хостеру. MX записями выставишь приоритеты по-вкусу

man RFC <номер_найди_сам>

В этом случае, сервер-отправитель будет брать первую попавшуюся MX запись и слать туда письмо. И только в случае, если невозможно соединится с этим сервером сервер-отправитель будет искать следующую MX-запись.

В той компании, где ты услышал эту схему используется еще автоматическое переключение relay-ев (т.е. сервер1 при получении письма доставляет его на сервер2, а сервер2 при получении — на сервер1). Только так можно сделать зеркалирование писем, тем самым отражая смысл твоей «идеи».

--

ТС, все правильно мыслишь. Твоя логика абсолютно верна. Придется немного пофигачить скрипт доставки в mailbox (maildir).

Из поста: Фильтрующий почтовый сервер (комментарий)

Отправка почты - наверно это будет проблемой. Внезапно.

Если в клиенте оставить оригинальный smtp-сервер, то все будет ОК. Альтернативно можно использовать relay, тогда письма будут сразу улетать на сервак хостера.

В этом случае, сервер-отправитель будет брать первую попавшуюся MX запись и слать туда письмо. И только в случае, если невозможно соединится с этим сервером сервер-отправитель будет искать следующую MX-запись.

читай rfc у mx записей есть вес, так что никаких «будет брать первую попавшуюся MX» не будет

ты реально не понял.

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

Я знаю реальность. Дофига серверов чихают на вес. Просто шлют это в одно место. А работать с этим тебе и твоим сотрудникам. Это жизнь.

Даже если так, то в чем проблема?

Без синхронизации, не важно в каком виде, relay один из вариантов, другой — распределенное хранилище, типа OCFS2, ящики на серверах будут разными. На одном 100500 писем, на другом 10 писем. И как назло окажется, что письмо ком.диру каким-то макаром ушло на сервер с 10 письмами. Однако, клиентское ПО работает только с 1 сервером! И что, сказать, а поменяйте как адрес сервера на такой-то, а потом верните взад?

Что-то ты себе нафантазировал. Остановись! Смотри картинку, если слова не доходят.

                .-,(  ),-.    
             .-(          )-. 
         .->(    internet    )<------.
         |   '-(          ).-'       |
         |       '-.( ).-'           |
         |                           |
         | mx=20               mx=10 |
       ____                        ____ 
      |====|    .-----------.     |====|
      |    |--->| fetchmail |---->|    |
      |    |    '-----------'     |    |
      |____|                      |____|
         ^                      Local|server
   Hoster|                           |      
         |                           | pop3
         |                           |
         |                           v
         |       smtp              __  _ 
         '------------------------[__]|=|
                                  /::/|_|

                                  Client    

Все круто, кроме одного «но!». Что будет если локальный сервер уйдет в даун на неделю? Аль на две недели?

Пример. Сотрудник ушел в отпуск на две недели. За это время ему наприсылали на локальный сервер 100500 писем. Этот сервер сдох за 3 дня до его выхода на работу. Вот он пришел, открывает почтовик и видит, что нифига нету.

Ты мне не интересен. Брысь! Были претензии к mx, оказывается не обоснованные, теперь претензии к единственной точке отказа?

Почта перестанет заходить на локальный сервер, ТС переключит юзеров на хостера, как это у него сейчас и побежит чинить свой сервер.

Ох уж эти исправления исх.сообщений.

У хостера письма не надо удалять, а только копировать. Тогда там будет автоматом храниться копия всех писем, кроме тех что пришли на прямую в localserver. Тут уж проблемы ТС обеспечить бекапы и сохранность писем, на то он и админ.

Странно, что ты это воспринимаешь в штыки. Твое право. Я лишь сказал про настоящий опыт. И когда у тебя клиенты корпоративные, перенастроить почту ты им не сможешь.

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

параллельное соединение надежнее последовательного, тебе это любой технарь скажет

и это, давай свою почтовую схему (картинку) разберем ее достоинства

я планирую приоритет mx выставить ниже, чем у хостера. Чтобы письма ВСЕГДА приходили на хостера, а я только fetchmail забирал к себе.

слушай, а что если хостер ляжет? почте вообще кирдык?

У хостера есть 5 дней, чтобы поднять сервак. Письма в 95% не потеряются. По умолчанию bounce висит до 5 дней во всех современных smtp-серверах. Те, кто его выкручивают на меньшее время ССЗБ и ничего не поделать.

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

Со стороны админа конторки, неплохо сделать самому схему, когда уход в даун одного из подопечных ему МХ-серверов не вызывал никаких проблем. Схему я очертил.

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

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

Ну так арендуй пару серваков у hetzner, c бэкапом вместе в ~40 Ойро в месяц можно уоложиться вполне.

Если хостер ляжет, то я ВООБЩЕ ничего не смогу поделать. И в этом проблемы я не вижу. Риск есть, я и мое руководство готово с ним мириться. Отказоустойчивость хостера на порядки выше, чем моя.

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

У ТСа есть теже 5 дней чтобы поднять сервер и клиенты не будут ждать хостера, а продолжат работать

хозяин-барин, а всякая школота с ЧСВ пусть умничает среди одноклассников

Если хостер ляжет, то я ВООБЩЕ ничего не смогу поделать.

нн знаю что ты имеешь в виду, но твой сервер продолжит принимать письма, при «параллельной» схеме

Да даже зачем два - если у тебя клиентов не over9000, то тебе одного такого сервака хватит, я думаю.

Ок, пусть это будет бесплатный бонус. Сейчас у хостера для моего домена указаны 3 МХ-записи. Мой локальный будет 4-ым.

В общем понятно. Дело осталось за малым - внедрять.

Коллеги, спасибо за помощь.

Еще раз. Ключевые моменты, когда нет двусторонней синхронизации меж серверами (далее сервер это smtp-сервер) и когда используется балансировка по MX:

• сторонние сервера чихают на приоритеты (вес)
• из-за этого каждый сервер хранит свой набор писем
• в случае когда один из серверов ложится, а в нем есть незабранные письма, то эти письма вообще никак не извлечь
• восстановление писем из бэкапов (т.е. тупо файлов) еще тот мозготрах, т.к. без failover-сервера их сначала надо будет закинуть на все клиентов, а потом эти клиенты обратно перенастроить на primary-сервер (оно тебе надо?)
• хорошо если раб.станций меньше 100, а если больше? в один день управишься?
• простой в один день 100 сотрудников обойдется тебе в 12 зарплат, ты согласен?

Дальше разжевывать не буду. Твоя схема неплохая, но имеет изъян. Будет клево если изъян придется на твой отпуск или на праздники с 1 января. Все, закрываем спор. Ты прав, но по-своему. Кто-то ищет приключений, кто-то пытается от них убежать.

ты fetchmail видишь? все, давай до свидания

Вижу, смотрит в одну сторону. Всего наилучшего.

Отказоустойчивость будет обеспечена хостером, т.е. вся почта будет принята почтовиком хостера.

... забрана твоим ненадежным костылем и не потенциально недоставлена клиенту? Что за прикол «обеспечивать надежность» за счет добавления точки отказа?

По умолчанию bounce висит до 5 дней во всех современных smtp-серверах.

Ты это AOL расскажи. Я вполне серьезно, сам в шоке был, сервак не работал около 4-х часов, писем нэма.

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

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

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

Спам не просто раздражающий, приходит большое кол-во писем с шифраторами. Антивирус их не видит. Я закинул такое вложение к письму на вирустотал.Результат - только каспер что-то заподозрил, остальные пропустили.

Уповать на инструкцию для пользователей дело неблагодарное. Это невозможно контролировать.

Спам не просто раздражающий, приходит большое кол-во писем с шифраторами. Антивирус их не видит.

Хоть это и выходит за рамки темы, но отпишу. Шифраторы «забавная» напасть, приходит в очень разнообразном виде. Мне довелось несколько экземпляров посмотреть, вообще все очень тривиально, в конечном итоге используют для шифрования стандартные вещи gpg.exe, rar.exe, может что-то еще но я только это встречал, разнообразие в методах получения частей кто-то большую часть кладет во вложение кто-то меньшую и создания зашифрованных файлов, для скачивания даже curl попадался. Вообще при учете на основе чего они работают, удивлен что до сих пор *nix системы не заполонили, сделать никаких проблем нет, все стандартное, а результат будет тот же. Собственно поэтому антивири не особо и ругаются там вирусного кода почти нет, а при учете того что он каждый раз новый то и не успевают в базы добавлять.
Как с этим бороться методами антиспама и при этом не блокировать полезные письма я не представляю.
ЗЫ После разбора очередного виря пришла в голову мысль блокировать на компах пользователей запуск gpg.exe, rar.exe для работы они им не нужны, но насколько это эффективно я хз, «мопед не мой» ( компами пользователей практически не занимаюсь) я только идею подкинул народу.