Полезная информация. Можно использовать при оценке требуемого места. А можно на своих ящиках собрать такую же таблицу. К сожалению, в админке VK WorkSpace не показывает, сколько какой ящик жрёт. Но можно дать команду очистить ящик и она в предупреждении выдаст объем. Но это придется с каждым ящиком такое проворачивать - морочно, да и стрёмно.
Во-вторых, он не поддерживает протокол Exchange для интеграции с Outlook. А это нам как раз и очень надо. Я, правда, не пойму - зачем. Но желание руководителя - закон :)
Сейчас мы как раз на VK WorkSpace. Там, действительно, есть такой лимит на письмо.
А раньше был свой почтовый сервер. Лимиты я не выставлял. Ибо проектная документация, которую нам шлют проектные организации для ознакомления и замечаний, весит весьма немало.
Но растущие аппетиты Mail.ru вынуждают нас снова искать варианты SHMS. Названия не помню, что за сервер (мы пока в поиске), но в рекомендациях к нему написано, что желательно хранилище на SSD NVMe развертывать.
Ну мы прикинули, что на пользователя нужно гигов 25, чтобы не пришлось скоро увеличивать объем массива.
У меня сейчас всякого мусор нужного и не нужного - 12,5 Гб. И это при том, что я периодически чищу ящик. И мне редко приходят объемные вложения. А некоторые получают, например, проекты в 20 томах (PDF) из нескольких десятков страниц каждый.
Но 200 пользователей - это необходимый минимум. Скорее всего, число может увеличиться до 300 еще в этом году.
Так что, нужен массив на 8 Tb. Проблема в том, что по требованиям ПО, это должны быть устройства NVMe.
А зачем такие сложности? Зачем куча ящиков на своём сервере для одного пользователя? Достаточно завести кучу алиасов. Правда, на публичных серверах количество алиасов одного ящика, обычно, ограничено. Но на своем сервере можно иметь туеву хучу разных пользователей и каждому дать столько же алиасов.
На самом деле, хранение было бы не очень дорогое, если бы не последние цены, особенно на SSD M.2 большого объема, - составят половину стоимости всего сервера.
Да даже SSD SATA 8Tb - уже кусаются. А их нужна не парочка.
На многих почтовых серверах релей включен по умолчанию. Чтобы его закрыть, нужно прямо указать, что пересылка разрешается только для отправителей с конкретных доменов, например, только с корпоративного.
Правда, никто не мешает спамерам при этом подделывать в "конверте" поле "MAIL FROM:", поэтому и нужно производить дополнительные проверки, которые, кажется, начинают проводиться еще на стадии "EHLO".
Не знаю, как обстоит дело сейчас, но лет 10-15 назад львиная доля спама шла не с легитимных почтовых сервисов, а с рядовых спам-ботов, в т.ч. с динамических IP или из провайдерских зон с серыми адресами. Как правило, при анализе обратной PTR-записи обнаруживалось, что почтового сервера на этом IP нет. Следовательно, никто не может послать с него ничего хорошего.
И это тоже верно. Но это лечится на пограничном файерволе запретом исходящих соединений на почтовые порты со всех локальных адресов кроме почтового сервера.
Хорошо помогает анализ обратных PTR-записей и SPF-записей. При их включении, обычно, количество спама падает на порядок. А то и на два. Основан на том, что легитимные почтовые сервера и релеи находятся на зарегистрированных доменах. Если письмо пришло не с зарегистрированного домена, либо IP-адрес отправителя не находится в SPF-записи домена-отправителя, то, скорее всего, это рассылка с зараженного домашнего компьютера.
Но это не панацея, т.к. заразить могут и корпоративный комп и даже офисную кофемашину (шутка).
Есть еще DKIM и DMARC. Там легитимность отправителя проверяется через цифровую подпись. Но это мало применяется на self-hosted mail server. Хотя, скорее всего, скоро неподписанные письма будут просто отвергаться повсеместно.
Кстати, одна из опасностей SHMS в том, что если в корпоративной сети завёлся SMTP-бот, то в BL может попасть IP шлюза и вся почта из корпоративной сети ляжет.
Нет, они всё равно ругают ОИТ. И требуют: "Сделай, чтобы всё! Тыжпрограммист!!!"
Это миф!!!
Полезная информация. Можно использовать при оценке требуемого места. А можно на своих ящиках собрать такую же таблицу. К сожалению, в админке VK WorkSpace не показывает, сколько какой ящик жрёт. Но можно дать команду очистить ящик и она в предупреждении выдаст объем. Но это придется с каждым ящиком такое проворачивать - морочно, да и стрёмно.
У нас исходящие редко больше 20 Mb бывают (хотя, бывают и до 50-60). А вот входящие - легко.
Это я слишком кратко написал название протокола:
Exchange Web Services (EWS) - протокол связи почтовых клиентов с сервером Exchange для обмена календарями и карточками данных.
Во-первых, платный.
Во-вторых, он не поддерживает протокол Exchange для интеграции с Outlook. А это нам как раз и очень надо. Я, правда, не пойму - зачем. Но желание руководителя - закон :)
Статья со сравнением уже есть:
https://itforprof.com/infrastruktura/stalwart-mailcow-iredmail-sravnenie/?ysclid=mq4q9hq8jf551713127
Мы склоняемся к Stalwart. Но это не точно.
Ну мы идем к этому. Но пока не можем выбрать между Stalwart, Mailcow и iRedMail. У всех есть как неоспоримые преимущества, так и некоторые недостатки.
Сейчас мы как раз на VK WorkSpace. Там, действительно, есть такой лимит на письмо.
А раньше был свой почтовый сервер. Лимиты я не выставлял. Ибо проектная документация, которую нам шлют проектные организации для ознакомления и замечаний, весит весьма немало.
Но растущие аппетиты Mail.ru вынуждают нас снова искать варианты SHMS. Названия не помню, что за сервер (мы пока в поиске), но в рекомендациях к нему написано, что желательно хранилище на SSD NVMe развертывать.
Там есть в центре пакетов "Synology Mail Server" и "Synology MailЗдгы Server". Второй - платный.
Еще можно посмотреть пакеты сторонних разработчиков. Или поднять контейнер в Докере практически с любым подходящим сервером.
Ну мы прикинули, что на пользователя нужно гигов 25, чтобы не пришлось скоро увеличивать объем массива.
У меня сейчас всякого мусор нужного и не нужного - 12,5 Гб. И это при том, что я периодически чищу ящик. И мне редко приходят объемные вложения. А некоторые получают, например, проекты в 20 томах (PDF) из нескольких десятков страниц каждый.
Но 200 пользователей - это необходимый минимум. Скорее всего, число может увеличиться до 300 еще в этом году.
Так что, нужен массив на 8 Tb. Проблема в том, что по требованиям ПО, это должны быть устройства NVMe.
А зачем такие сложности? Зачем куча ящиков на своём сервере для одного пользователя? Достаточно завести кучу алиасов. Правда, на публичных серверах количество алиасов одного ящика, обычно, ограничено. Но на своем сервере можно иметь туеву хучу разных пользователей и каждому дать столько же алиасов.
На самом деле, хранение было бы не очень дорогое, если бы не последние цены, особенно на SSD M.2 большого объема, - составят половину стоимости всего сервера.
Да даже SSD SATA 8Tb - уже кусаются. А их нужна не парочка.
На многих почтовых серверах релей включен по умолчанию. Чтобы его закрыть, нужно прямо указать, что пересылка разрешается только для отправителей с конкретных доменов, например, только с корпоративного.
Правда, никто не мешает спамерам при этом подделывать в "конверте" поле "MAIL FROM:", поэтому и нужно производить дополнительные проверки, которые, кажется, начинают проводиться еще на стадии "EHLO".
Не знаю, как обстоит дело сейчас, но лет 10-15 назад львиная доля спама шла не с легитимных почтовых сервисов, а с рядовых спам-ботов, в т.ч. с динамических IP или из провайдерских зон с серыми адресами. Как правило, при анализе обратной PTR-записи обнаруживалось, что почтового сервера на этом IP нет. Следовательно, никто не может послать с него ничего хорошего.
Ну или SPF покажет примерно то же самое.
Т.е. сейчас заражение рядовых пользовательских компов спам-ботами, по вашему, уже не производится?
Не сразу ... Только при регулярных длительных платежах :D
Ну так это на 900 меньше :)
На самом деле - эффект заметный. Но не исключает необходимости дополнительных телодвижений по контекстным фильтрам.
И это тоже верно. Но это лечится на пограничном файерволе запретом исходящих соединений на почтовые порты со всех локальных адресов кроме почтового сервера.
Надежных решений нет.
Хорошо помогает анализ обратных PTR-записей и SPF-записей. При их включении, обычно, количество спама падает на порядок. А то и на два. Основан на том, что легитимные почтовые сервера и релеи находятся на зарегистрированных доменах. Если письмо пришло не с зарегистрированного домена, либо IP-адрес отправителя не находится в SPF-записи домена-отправителя, то, скорее всего, это рассылка с зараженного домашнего компьютера.
Но это не панацея, т.к. заразить могут и корпоративный комп и даже офисную кофемашину (шутка).
Есть еще DKIM и DMARC. Там легитимность отправителя проверяется через цифровую подпись. Но это мало применяется на self-hosted mail server. Хотя, скорее всего, скоро неподписанные письма будут просто отвергаться повсеместно.
Кстати, одна из опасностей SHMS в том, что если в корпоративной сети завёлся SMTP-бот, то в BL может попасть IP шлюза и вся почта из корпоративной сети ляжет.