Постфикс умеет очень неплохо бороться со спамом. Сам. Рубит соединения уже на этапе HELO. А если ему помогает разбирать контент Amavis, то вообще шоколадно получается. У меня после перехода на постфикс входящий трафик упал кардинально. Настолько упал, что юзеры стали жаловаться - почта, мол, не работает. А до того они спамом были завалены по самые уши. Поэтому сокращение входящего трафика вполне ожидаемо.
У меня в день по 3-4 тыщи попыток ботовских заходов регистрируется, пропускается где-то под сотню-другую. Дальше amavis контент почикает и пропустит уже не сотню, а с десяток-другой писем.

А вот по исходящему - может активность собственно фирмы выросла?

Просто руки не от туда растут.   

Мой опыт настройки Postfix:

Я вполне осознанно обрезал требование обязательной аутентификации, но оставил в обязательном порядке работу только из локальной сети. К сожалению Postfix не умеет реализовывать два  фильтра, объединяя их по И. Идет последовательный вызов, то есть логика ИЛИ. И если снаружи кто сумеет каким либо образом подобрать пароль, то он получит доступ к почтарю. Мне этого не надо. Поэтому настраиваю postfix только на обслуживание "мой сети" (серые адреса, извне фиг доберешься).
Так вот, на этапе HELO/EHLO валится 99% спамеров. То есть postfix их отрубает даже до начала отправки ими каких либо команд. Напрочь. Редкая птица долетит до контент-фильтра в amavisd. Ну и тот свою лепту не преминет внести.

как-то тема на опрос не похожа.

вот у меня раньше стоял exchange 2010 и траффика было около 300мб в день принятых и 120 отосланных, а сейчас зимбра, и принятых около 5Гб, а отосланных 3.5.
и кому какое дело что юзеров стало не 25 человек а ближе к 1000...

Мне тоже интересно, почему у Cruiser78 почтовые клиенты только в локальной сети.

А у нас работают всего 4-юзера удаленно с телефонами и ноутбуками, тип ящика у них IMAP. Некоторые пользователи проверяют свою почту через браузер.

Тема на опрос не похожа, потому что товарищи скрывают цифры.

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

Зато дешево и практично. Какие есть угрозы (то есть строим модель нарушителя) от ремутного компьютера.
1. Ремутный (разъездной) ноут можно пролюбить в каком либо кабаке. Нарушитель получает доступ к телу ноута. Следовательно - надо сделать так, чтобы к данным, к ключам доступа, которые есть  на этом ноуте он доступа не получил. Как? Криптография. Диск тотально зашифрован.
2. Юзер может на слабоконтролируемом ремутном компе словить какой-нибудь зловред, который шифрует (а точнее - корячит) все файлы, документы, до которых может дотянуться. Если он дотянется до файлов в лавке, то порушит их. А если он их будет крушить не подряд, а выборочно, например, с вероятностью 7%, то никакие архивные копии не спасут гиганта мысли. Секс по поиску порушенного и его восстановлению будет еще тот. Оно мне надо? Отсюда два подхода. Доступ к файловым ресурсам преимущественно через терминальный доступ (попробуй дотянись). Или, если хочется монтировать файловую раздачу на свой комп - ставим линукс.
Комбинируя 1 и 2 получаем типовую настройку - линукс на зашифрованных дисках для работы. Если нужны игры - dualboot c вынью. Остальное добавляется по вкусу.

Нет. Его стойкость определяется решением задачи криптоанализа. Сумеешь расшифровать рабочий диск, то есть подобрать ключ - молодец, возьми с полки пирожок. А не сумеешь...
Так что есть дуалбут или нет его - всё едино.

Есть причина, есть следствие. У меня не только почта в VPN завернута. Но и иные сервисы. Например, Asterisk. Оплачивать звонки в Нигерию? Потому и закрываю всё единым механизмом. А чтобы исключить несанкционированный доступ к ключам VPN - шифруем диск, где они могут лежать. Я предпочитаю метод изоляции. Надежнее ножниц еще ничего не придумали. VPN как раз и обеспечивает нужную мне изоляцию.
А к DLP (если мы понимаем оно и тоже) у меня отношение, пока еще, осторожное. Это как порося стричь - визгу много, а шерсти мало. Настраивать DLP замучаешься, а толку  чуть выше плинтуса. Ожидаемый эффект не адекватен трудозатратам.

1. А в чем особый смысл держать такой файлер на собственных ресурсах. У меня корпоративный WWW и FTP у хостера. И нет проблем.
2. По DLP - баловство это. Здесь я стою на позиции "заставь дурака Богу молиться, он и лоб расшибет". До тех пор, пока юзеры не станут сдавать свои головы в секретную часть - в своей голове они унесут всё что угодно. Самую большую ценность представляет не сам документ, а идея как сделать, концепция, подход. Человек может просто за рюмкой чая сболтануть (по доброте душевной) лишнее, а специалисту достаточно и этого "лишнего", чтобы понять суть секрета и раскрутить его на своих подходах. DLP - это дорогостоящаа имитация безопасности.

Бизнес - он разный. У меня внешних данных немного, а каналы на фирму - тонкие. Забивать эти каналы трафиком от нашего WWW и FTP - нецелесообразно.

Иллюзия. Эспортируем таблицу с номерами в pdf или в jpg и накрываются медным тазом все эти паттерны. Ну а если юзеру разрешено обмениваться с внешним миром этими форматами - ищи ветра в поле. Никогда не найдешь передачу инсайдерской информации в общем таком потоке. DLP - красиво в теории, но на практике реализуемо так же, как и модель мандатного доступа Белла-Лападула. Для того, чтобы DLP хоть как-то заработало необходимо реализовать именно метод ножниц, полностью изолировать свою систему от внешнего мира и оставить общение с ним только через очень определенные контролируемые каналы. Плюс - жесткая политика в части исполняемых функций в прикладе на всех компах системы. Как правило - это не реализуемо. А если этого не реализовать, то будет очередная профанация. Я проходил через это, как раз через нечто подобное DLP.

Название широкой публике ничего не скажет. Это была заказное программное обеспечение нацеленное на анализ действий юзера в одной крупном программном комплексе для очень крупной конторы. Веселуха начиналась тогда, когда разработчик этого комплекса планово или нет вносил изменения в свой комплекс. Все это наше DLP мгновенно раскорячивалось от этих изменений. Соответственно поток событий НСД прямо пёр... Пока не скажешь, что это всё легально и надо пропускать. И в этом потоке можно было запросто и реальное НСД проглядеть, и объявить его легальным действием, разрешить его...
Именно этот опыт работы и настроил меня очень скептически по отношению ко всему семейству DLP.

Разработчиков выбирал не я. Я был тогда вообще очень далёк от этой проблемы. А въехали эти разработчики в контору, где я тогда работал (в Банк России) на волне фальшивых "чеченских" авизовок. Нарисовали эскизный проект системы наблюдения и контроля в которой, якобы, можно было проанализоровав поведенческую модель работы пользователя (вызовы тех или иных функций приклада, вплоть до анализа текстов, названий, пунктов менюшек ) выявить факт "вброса" фальшивого платежного документа юзером в потоке обычного легального ввода.
Для меня это изначально прозвучало, что сие - лженаука. И я, получив задание оформить проект ТЗ этому разработчику абсолютно сознательно переписал, скопипастил, из эскизного проекта это самое выявление факта вброса как требование к системе.  Эту "шутку" более высокие чины просекли (или им подсказал кто, не знаю) и в окончательном варианте из ТЗ данный пункт был убран.  Но на этапе приемки данного поделия потоптались на этом тезисе изрядно. Разработчик выглядел достаточно бледно, но работу таки сдал, сошлись на мнении, что их система есть система _доверенного_ аудита. Ну а потом - несколько лет доработок...

Я всегда прекрасно понимал, что ребята научились встраиваться в адресное пространство прикладной офтопичной задачи и наблюдать все её вызовы, но вот что именно делать с потоком этого наблюдения... В результате система показывала только очень явные отклонения от штатного  поведения (администратор зашел на комп по своей надобности). Но такой административный заход легко фиксировался иными, более штатными, средствами.

Большие конторы очень часто, если не повсеместно, используют для выполнения своих основных функций именно кастомный софт. Который разрабатывают или самостоятельно, в профильном подразделении, или разработку ведет специализирующаяся на этой разработке контора. Так что кастомный софт неизбежен. Как и постоянная "жизнь" его ABI/API.
Ну и плюс казённые амбиции моего руководства. Все мои слова, что сопровождать разработку этой "DLP" должен разработчик типового программного комплекса, под который эта DLP и точилась - игнорировались. Как же, мы - опорный регион по сопровождению "DLP", можно человечка-другого, дополнительно, в отдел нанять. Ну и "мы, опорный регион" звучит гордо. Правда, штатов под опорный регион нам так и не добавили. Обходитесь своими силами. Хотя - когда возникала очередная волна оптимизаций - опорность помогала сохранить людей в отделе.

Но это было всё лет 5 и более назад. Как там сейчас - не знаю.

Еще раз уточню - всё это было предназначено для контроля одной кастомной системы. Большой замкнутой системы.
Был еще форк этой DLP под офисные нужды, но там всё было вообще грустно. Контроль потоков защищаемой информации обеспечить было практически нереально. Как связать открытие документа, содержащего кроме всего прочего, защищаемую информацию, копировние её в клипборд, далее вставка буфера в почтовое сообщение, отправка на соседний комп, далее обработка сообщения соседом (от которого можно получить его же и обратно) и отсылка куда-нибудь еще... В принципе, это легальная схема подготовки документа несколькими сотрудниками. И документ выходящий, при этом может быть как "секретным", так и не содержать никаких секретов. Как вычленить в этой каше утечку конфиденциального абзаца из оригинального документа - не представляю. Так что и в офисной своей части этот форк контролировал запуски ворда с екселями и отлуками. Но контроля потоков информации по Беллу-Лападулу там не было...

Я с этим полностью согласен. Но решение контролировать именно core bisiness - это не моя идея (более того, я был её последовательным противником). Но то решение было принято более из политических соображений. Основы техники в расчет не брались.

Но, тем не менее - реализовать полноценную DLP без реализации контроля потоков в системе никак невозможно. А организовать контроль потоков без реализации полномочного доступа. Но как организовать работоспособную полномочку  не на отдельном компьютере, а на локальной сети, где данные как конфиденциальны так и нет и передаваться могут с использованием самых разных стандартных программ и протоколов, передаваться и преобразовываться при этом - я не представляю.

Например: мы имеем открытый документ, открываем его к любом редакторе, копируем часть теста в буфер обмена, затем вставляем этот буфер обмена в поле ввода почтового клиента и отправляем это дело какому нибудь внутреннему абоненту (а тот может отправить его, или часть, во внешний мир). Это всё легально и система DLP не должна делать на неё стойку. Но вот если оргинальный документ  защищаем, то каким образом полученное сообщение получит статус конфиденциальности? А если оно такого статуса не получит, то оно может быть далее перенаправлено во внешний мир без какой-либо реакции на то DLP.