Мы писали данную статью для максимально широкой аудитории. Мы старались описать все самыми понятными для каждого словами, опуская детали для упрощения понимания материала. Поэтому в статье могут быть неточности. Мы будем признательны, за любое улучшение данной статьи. Материал в данной статье будет интересен в первую очередь системным администраторам и разработчикам системы Odoo. Статья о работе Odoo версии 11.0, SPF версии 1.

Ссылка на описание настройки почты, catchall, SPF, G Suite, Office365, DKIM,... для Odoo от компании Odoo SA.

В этой статье мы расскажем о том, что такое catch-all ящик и как он используется в Odoo CE. Мы расскажем как работает почта в Odoo. Почему почта в Odoo работает именно так вы можете узнать из другой нашей статьи.

Но прежде чем объяснить что такое catch-all, и для чего catchall в Odoo, вначале нужно понять, что такое SMTP релей.

Обычный почтовый ящик - это электронный ящик для отправки писем определенным человеком. Даже если это ящик для отдела\департамента, то все равно, обычно, работой с этим ящиком занимается конкретный человек. Все письма, отправленные через этот ящик в поле Отправитель будут содержать тот же емейл, с которого отправлено это письмо.

Это самая простое, привычное использование электронных ящиков. Но этот способ подразумевает ручную обработку корреспонденции. Но что если мы захотим как-то автоматизировать процесс маршрутизации и обработки писем. Несколько примеров:

• сделать предварительную проверку писем антивирусом перед отправкой и после получения письма, причем для всех сотрудников компании

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

• сделать фильтрацию от спама всей корреспонденции компании

• проверка всей корреспонденции компании на "утечку" документов с грифом "Только для внутреннего использования"
  

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

Итак, SMTP релей это электронный ящик, через который транзитом проходят электронные письма. При этом над каждым проходящим через него письмом производятся какие-либо действия.

 Имеем:

• человек отправляющий письмо или партию писем

• сами электронные письма

• емейл Отправителя, который указан в (каждом)письме в поле Отправитель(например petrenko-vasiliy@your-domain.corp)

• доменное имя, указанное в email-е отправителе(в примере выше это "your-domain.corp")

• защитная SPF запись, указанная в доменном имени, в емейле, в поле Отправитель, в отправляемом письме

• емейл(SMTP релей), с которого отправляется письмо. Это может быть емейл на почтовом сервере любого отправителя (например catchall55-for-my-company@gmail.com или smtp-relay@any-domain). Обратите внимание: домены могут быть разные в емейле Отправителе("your-domain.corp") и в емейле с которого отправляется("gmail.com")!

• почтовый сервер, отправляющий письмо(может быть как ваш почтовый сервер, так и внешний почтовый сервер: gmail, freemail, ukr.net, mail.ru,...)

• почтовый сервер получатель. Именно он проверяет(по крайней мере должен это делать) SPF запись.
  

• емейл, на который приходит письмо

Odoo использует почтовый электронный ящик(и), называемый catchall емейл, для доставки всей(!) электронной корреспонденции(электронных писем) всех сотрудников в обе стороны(отправка и получение), кроме ящиков-функций(например sales@your-domain.corp, hr@your-domain.corp, ...). Это значит, что любое сообщение(в данном контексте сообщение - это электронное письмо) любого пользователя Odoo, которое написано для внешнего адресата будет отправлено через этот почтовый электронный ящик-шлюз(SMTP релей).

Но при этом, внимание(!), адресат получив письмо от пользователя Odoo, в поле Отправитель увидит не catchall-odoo-relay@yor-domain.corp, а "Василий Петренко petrenko-vasiliy@your-domain.corp"! Это происходит из-за того, что Odoo, хотя и отправляет все письма всех пользователей через catchall ящик, но при это подменяет Отправителя. (поле "From:")

Если это понятно, то идем дальше.

В примере выше адресат получил письмо с емейла catchall-odoo-relay@your-domain.corp, а в поле Отправитель видит petrenko-vasiliy@your-domain.corp. Что будет, если адресат нажмет Ответить, напишет ответ, и отправит? На какой емейл поступит это письмо? На "petrenko-vasiliy@your-domain.corp" или "catchall-odoo-relay@yor-domain.corp"?

Мы уже рассказали, что все входящие и исходящие письма доставляются через catchall ящик. Это реализовано так: в каждом электронном письме есть скрытое поле Адрес-для-ответа(поле "Reply-To:"). Для Gmail его можно увидеть, если открыть Еще > Показать оригинал.

В большинстве случаев Odoo автоматически заполняет поле Электронный-адрес-для-ответа = catchall ящику. Поэтому все ответные письма, так же поступят на catchall ящик.

Смотрим дальше.

Стоит заметить, что Odoo загружает письма с catchall ящика через механизм автоматических заданий. Задание, которое это делает называется Mail: Fetchmail Service. Важно понимать, что задания отрабатывают чрез определенные промежутки времени. Для загрузки писем по умолчанию стоит 5 минут. Это значит, что после того как письмо поступило на электронный ящик, оно будет загружено в Odoo минимум через 3 секунды, максимум через 5 минут. Вы можете интерактивно(т.е. без программирования) изменить этот интервал так как Вам необходимо.

Важно понимать, что если указан тип протокола IMAP, то Odoo будет загружать письма, которые помечены как непрочитанные. Т.е. если у вас в браузере открыта вкладка веб-интерфейса catchall ящика, на catch-all пришло письмо, вы через веб-интерфейс решили его посмотреть или пометили как "Прочитанное", то это письмо в Odoo не будет загружено.

Итак, письмо загружено в Odoo с catchall ящика, что дальше? Маршрутизация внутри Odoo полностью автоматическая. Основная цель маршрутизации это автоматическое определение Карточки(точнее Ленты карточки), связывание входящего письма с найденной Карточкой и уведомление Подписчиков о поступлении сообщения.

Для автоматического определения "Карточки для связывания" у Odoo есть множество механизмов. Детально, пока что, не будем их рассматривать, но понимать принципы их работы необходимо. Итак:

• Каждое письмо связано с одной(и только одной) определенной Лентой обсуждения(т.е. Лентой определенной Карточки).

• Еще на этапе написания письма внешнему адресату, Odoo вставляет в письмо невидимые маркеры для последующей маршрутизации.

• На этапе написания внешним адресатом ответа на оригинальное письмо, кроме всех остальных маркеров, в тело письма будут вставлены: текст оригинального письма, с ИД оригинального письма, с ящиком отправителя "Василий Петренко <petrenko-vasiliy@your-domain.corp>" и даже ИД карточки Odoo, из которой оно было отправлено.

• При загрузке ответного письма в систему, Odoo распарсит("прочитает") письмо и по оставленным маркерам определит, что это письмо, на самом деле "ответ" на другое письмо, которое привязано к определенной карточке.

• После чего, Odoo привяжет ответное письмо к Ленте обсуждения этой же Карточки.

Итак, ответное письмо загружено в Odoo и автоматически связано с Карточкой, из которой было отправлено оригинальное письмо.

Каким способом пользователь Василий Петренко узнает, что на его письмо пришел ответ? Ответ: через Подписку на Карточку(из которой Василий писал оригинальное письмо).

При написании первого письма под пользователем Василий Петренко из определенной Карточки, как только пользователь нажмет "Отправить письмо", он(пользователь) будет автоматически добавлен в Подписчики данной Карточки.

Далее Василий будет получать все сообщения, которые будут добавлены в данную карточку кем либо: другим пользователем Odoo, внешним адресатом, пользователем Odoo портала или еще кем-то.

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

Важный нюанс: подписываться(и отписываться тоже) на Карточку можно одним кликом, но мало кто знает, что при этом Подписчик подписывается не на все типы сообщений. Посмотреть можно так: Карточка > Лента > Подписчики > В выпадающем меню навести мышку на интересующем нас Подписчике > справа от имени этого подписчика появляется кнопка карандаш(редактировать подписку) > нажимаем на нее и видим примерно следующее

Каждое сообщение имеет 3 типа(Емейл, Комментарий, Системное уведомление) и множество подтипов(Меню > Настройки > Технические > Емейлы > Подтипы).

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

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

 Пользователи Odoo могут получать ответные сообщения:

• в виде уведомлений внутри Odoo в разделе Общение > Входящие, либо
  

• в виде электронных писем на свой личный или корпоративный ящик вида petrenko-vasiliy@your-domain.corp

Если в Odoo для Василия настроено получение ответных писем только внутри Odoo, без пересылки на ящик пользователя, то личный ящик пользователя типа petrenko-vasiliy@your-domain.corp можно вообще не создавать, потому что он вообще не используется! Если в Вашей компании большая текучка, много сотрудников, вы хотите упростить администрирование почтовых серверов, и пр., то лучше не создавать ящик для каждого пользователя Odoo.

Даже если пользователи изъявят желание получать ответные письма на свой смартфон, то каждый их них уже имеет возможность самостоятельно указать свой личный электронный ящик(например kitty-gold999@gmail.com) в настройках пользователя и Odoo на него будет пересылать ответные уведомления. Но к сожалению все письма от сотрудников к внешним адресатам будут в поле Отправитель содержать не солидный адрес типа Vlasova-KM@best-global.corp, а емейлы типа kitty-gold999@ukr.net или mega_pihar-80lv@gmail.com.

Мы рекомендуем указывать для пользователей Odoo виртуальные(не существующие) электронные ящики по шаблону "Фамилия_ИО@your-domain.corp", не создавать эти ящики в почтовых серверах, и выключить пересылку писем каждого пользователя на его емейл. А для получения писем на смартфоне:

либо установить мобильный клиент Odoo

либо держать открытой Odoo в браузере смартфона и обязательно на закладке Общение включить "Разрешить получать системные уведомления".

Таким образом Odoo будет уведомлять пользователей о получении ответного письма через системные уведомления(уведомления операционной системы пользователя). Если пользователь свернет браузер, включит другую вкладку или его смартфон уснет, то он все равно получит уведомление о поступлении для него сообщения в Odoo.

Мы рассмотрели:

• как письма отправляются из Odoo через catchall,

• как Odoo получает письма с ящика catchall

• как Odoo проводит маршрутизацию писем внутри системы

• как Odoo уведомляет пользователя о входящем письме через Подписку на Карточку

• как пользователь Odoo может получать уведомления о поступлении ответа на его письмо от внешнего адресата

Вот мы и добрались до середины статьи. Это была вводная информация. Далее пойдет самое интересное.

Все мы когда-то ошибались в написании емейла. Все мы знаем, что письмо не дойдет до адресата и вернется назад. Но для Odoo это проблема более серьезная. Например: если клиент, получит письмо от пользователя Odoo, c catchall ящика. В поле Отправитель он увидит емейл, но он не знает, что этот емейл виртуальный. Чтобы написать ответ, клиент может не нажать "Ответить", а скопировать емейл в буфер > нажать "Новое письмо" > вставить из буфера > написать текст > Отправить. Более серьезная история: сотрудник компании заказал визитки для менеджеров отдела продаж, предварительно попросив каждого написать свой емейл. Менеджеры могли не подозревать о такой маленькой технической детали, что ящики пользователей - на самом деле виртуальные(не существующие).

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

С одной стороны catchall очень желателен для корректной работы odoo, но в большинстве случаев почта в Odoo сможет работать и без него. Но если вы не хотите потерять ни одного письма, то catchall - мастхэв.

Catchall ящик, он же catchall email, он же catch-all, он же wildcard, он же "емейл домена по умолчанию" или "default email". Что такое настоящий электронный catchall ящик(или catchall email) и зачем он в Odoo? Чем SMTP релей отличается от catchall?

Выше по тексту для обозначения электронного ящика Odoo, с которого отправляются и на который приходя письма пользователей Odoo - мы использовали название catchall. С нашей стороны, было бы более корректно, в рассказе выше называть этот ящик не кетолл, а SMTP релей и далее вы поймете почему. Мы использовали название "catchall"

• во первых, потому, что этот SMTP релей должен быть настроен как catchall ящик,

• а во вторых, потому что он по умолчанию имеет имя "catchall" в "Системном параметре" "mail.catchall.alias". Из-за чего его больше знают именно как catchall.

Но что же такое истинный кетчол?

SMTP релей и catchall, это не одно и тоже. Что такое SMTP релей мы уже выяснили. Настало время выяснить что такое catchall. Википедия о кетчоле. Кетчол или в оригинале "catch-all" переводится как "получать все". Другими словами, если кто-то написал письмо и отправил на электронный ящик и этот электронный ящик содержит корректный домен, но некорректное имя(например "this-email-name-is-INCORRECT-!!!@correct-domain"), то такое письмо будет перенаправлено почтовым сервером на эмейл этого домена по умолчанию, т.е. на catchall ящик.

Пример настройки корпоративной почты от Google Suite - создание кетчолл ящика на gmail.

Т.е. кетолл это функция почтового сервера связанная с доменом. И эта функция по умолчанию не включена и сама без вас(без администратора) не включится.

Если вы используете сторонние почтовые серверы, то возможность включения функции "catchall" у вас появится только в связке с корпоративным доменом(например any-name@YOUR-domain.corp). Т.е. включить catchall для обычного публичного емейла - не возможно. Например, если ваши емейлы заканчиваются на @gmail.com, @mail.ru, @ukr.net, @freemail.com - это не catchall ящики и не могут ими быть! Теперь понимаете, почему мы писали, что не совсем корректно было называть ящик для транспорта писем "catchall" ящиком?

Обратите внимание, catchall это функционал "приема" писем, а SMTP релей это функционал "отправки" писем. Одна технология без другой вполне может работать, но только в одну сторону. Эти две технологии обычно работают в паре. Поэтому часто заменяют "catchall" на "SMTP релей", хотя это не одно и тоже.

 Как мы выяснили выше, из-за функции SMTP релей, Odoo отправляет и принимает все письма(кроме функциональных емейлов) через единый емейл(обычно его называют "catchall"). Заказчики часто просят переделать этот функционал: сделать каждому пользователю реальный емейл, завести каждый емейл в настройках Odoo и заставить Odoo отправлять письма с емейла, соответствующего емейлу текущего пользователя. Мы уже писали почему это низко-эффективный подход. Хочется только напомнить одну из основных причин неэффективности данного подхода: слабо-масштабируемая, высоко-затратная архитектура. Если в вашей 1000 человек, то Odoo каждые 5минут(интервал загрузки писем) должна опросить все 1000 емейлов и загрузить с каждого письма. Посчитайте затраты на авторизацию. Odoo работает иначе:

1. всего лишь один единственный емейл типа SMTP релей(или несколько, объединенных в виде кластера для распределения нагрузки)

2. виртуальные емейлы пользователей в вашем домене

3. catchall, перенаправляющий письма с несуществующих, виртуальных емейлов на SMTP релей ящик(и). Откуда Odoo забирает все письма.

Для системы Odoo нужно один раз настроить указанные 3 технологии и забыть о заведении почтовых ящиков. При такой схеме ваши системные администраторы не заметят разницы обслуживания 1000 пользователей или 10000 пользователей(в сфере электронной почты).

Теоретически, можно заставить Odoo отправлять письма через соответствующие емейлы пользователей, но Фабиан озвучил план на будущее. С каждой новой версией и каждым обновлением Odoo все дальше и дальше удаляется от классической почты. Поэтому, даже если вы все же заставите Odoo работать постаринке, то вероятнее всего при этом закроете для себя совместимость с будущими версиями и со всеми будущими усовершенствованиями, багфиксами и секьюре-фиксами Odoo. А стоит ли плыть против течения, если течение вас несет к райским берегам?

Напомню немного о принципах работы системы Odoo. Odoo ставит во главу угла не емейлы, а Карточки и Подписки на карточки. Каждое письмо должно быть привязано к какой-либо карточке, но привязано должно быть в любом случае. В общем процесс выглядит так:

1. новое письмо поступает на функциональный емейл(sales@your-domain.corp, info@your-domain.corp, hr@your-domain.corp, warehouse@your-domain.corp,...)

2. Odoo загружает это письмо и создает Карточку или привязывает его к существующей карточке(почему и называются "функциональные емейлы")

3. Подписчику(или через Автоподписку) Odoo отправляет уведомление о входящем сообщении для него. Обычно это внутренний пользователь Odoo.

4. Подписчик Odoo получает уведомление и пишет ответное письмо, нажимает Отправить

5. Это письмо уходит через SMTP релей и дальше вся переписка идет через него и привязывается к этой Карточке

 Многие системные администраторы боятся, что если они создадут для своего домена почтовый catchall ящик, то к ним будет сыпаться весь спам интернета, во все ящики, всех пользователей. Это совсем не так.

Во 1ых - catchall указывается для домена. Это значит, что на него могут поступать только те письма, у которых в Адресате, в емейл адресе присутствует этот домен.

Во 2ых - если в вашем домене есть существующий емейл, на который написали письмо, то это письмо поступит на этот емейл, а не на catchall.

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

В 4ых - если вы опубликовали на своем сайте, открытом для всего интернета, корпоративный емейл(например info@your-domain.corp), то это сродни кетчолу. У спамеров есть одна главная проблема: узнать название емейла, чтобы отправить на него спам. Но если вы сами открыли для спамера свой корпоративный емейл, то чем это отличается от catch-all технологии?

Действительно, любой спамер может проверить есть ли у домена catchall ящик (как описано здесь). Если catchall есть, то в отличие от обычных емейлов, его имя не нужно пытаться узнать, чтобы отрапавить на него емейл. Можно просто послать письмо на любой емейл с любым рандомным именем, но корректным названием домена. Маршрутизация почты перенаправит это письмо на catchall ящик. Таким образом, спамеры могут(и будут) легко отправлять спам вам на catchall, даже не зная как называется ваш catchall ящик.

Но защита есть и она простая.

Сам Google, посредством своего GSuite предлагает сделать SMTP relay шлюз для любых почтовых серверов с целью фильтрации от спама и проверки на вирусы всей корреспонденции, проходящей через этот релей.

Так как избавиться от спама на catchall ящике? Вот тут есть решение. В статье объясняется решение, которые мы предлагаем использовать для Odoo в следующем виде:

• на GSuite создаете настоящий catchall ящик для своего домена

• добавляете фильтрацию на поле емейл Получателя

• если в емейле-получателя(например VasilisaQuen-expert@modool.pro) есть секретный суффикс(например "-expert" или "-your-company" или ".modool" или "-odoo-solutions")

• то письмо пересылать на ящик реальный секретный ящик, подвязанный к системе Odoo(например odoo-inbox@your-domain.corp)

• иначе это спам
  

Другими словами, вы устанавливаете корпоративный стандарт: в имя каждого емейла пользователя должен быть добавлен суффикс "-any-pretty-suffix", а в кетчоле настраиваете фильтрацию по этому суффиксу и пересылку на ящик SMTP релей Odoo. Т.е. с catchall на Odoo SMTP релей.

Таким образом, в ситуации если клиент нажмет не Ответить, а напишет новое письмо, и вручную наберет название emeil-a, то это письмо зайдет в Odoo, несмотря на то, что этот емейл не существует, а спам - нет.

Мы узнали:

• что будет если написать письмо на виртуальный емейл с настроенным catchall ящиком

• что настоящий catchall это функция почтового сервера

• что настоящий catchall работает только в связке с(вашим) доменом

• что функцию catch-all нужно включать отдельно

• чем catchall отличается от SMTP релей

• как и зачем используется настоящий catchall ящик в Odoo

• почему уязвим catchall ящик для спама

• как защитить catchall ящик от спама

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

Особенность Odoo в том, что внутри системы нужно явно указывать почтовые алиасы к внутридоменным, виртуальным, функциональным емейлам. Снаружи системы они не видны если вы не публикуете их на своем сайте. Поэтому спамеры их узнать не могут. Когда новый клиент пишет вам на такой функциональный емейл, то создается карточка и это письмо привязывается к ней. От этого момента начинает расти Лента общения. Можно даже сказать "Цепь общения".

Но что Odoo будет делать если на catchall пришло новое письмо адресуемое внутридоменному емейлу, для которого не заведен почтовый алиас? Например письмо адресуемое емейлу "1987432е51209874320984568732@your-domain.corp"? Odoo такое письмо просто не загрузит, по простой причине - она не знает, что с ним делать, к какой карточке привязывать, какому пользователю показывать. А ведь спам заходящий на catchall - именно такой. Поэтому весь спам отсекается системой Odoo при загрузке!

Для того чтобы спам загрузился в Odoo его необходимо отправить не на любой емейл внутри домена, а на емейл, заведенный в Odoo в почтовых Алиасах. Спамер не может узнать названия функциональных емейлов. Таким образом для спамера исчезает упрощение рассылки спама через корпоративный catchall. Более того, спамер может узнать существует ли реальный емейл, но не может узнать существует ли внутренний почтовый алиас Odoo. Поэтому можно сделать заключение, что Odoo защищена от спама больше чем классическая почтовая система.

Поэтому проблема спама на catchall ящике Odoo - отсутствует.

Мы рассмотрели выше, что catchall ящик это шлюз, а Odoo это маршрутизатор. Множество разных пользователей могут отправлять через него свои письма разным внешним адресатам. Образно говоря, для того чтобы множество пользователей могли отправлять через него письма - каждому пользователю дается пароль от этого электронного ящика! При этом Odoo подменяет Отправителя, в заголовке письма на того пользователя, который отправляет это письмо. Поэтом главный признак отправки письма через catchall ящик - это разные ящики в электронном письме: "электронный ящик отправителя"(например petrenko-vasiliy@your-domain.corp) и "электронный ящик сервера отправителя"(например catchall@your-domain.corp). К несчастью, эту же технологию(подмена отправителя) используют и спамеры и спуферы.

SMTP релей может быть либо открытый, либо закрытый(корпоративный).

Закрытый, корпоративный или частный SMTP релей это электронный ящик принадлежащий определенному лицу или группе лиц. Только лица, владеющие паролями доступа к этому электронному ящику могут отправлять и получать с него электронные письма(объяснение в следующем разделе).

Открытый SMTP релей доступен - вообще любому(!) пользователю интернета, причем обычно - без всякой авторизации и регистрации.

Внимание: беременным или впечатлительным системным администраторам мы рекомендуем пропустить этот и 2 следующих раздела или прочесть их после прочтения раздела "Почему системным администраторам не стоит бояться catchall ящиков". Всю информацию в этом разделе вы и так знаете лучше нашего, но ваши квалифицированные исправления и дополнения - только приветствуются.

Как мы писали выше, обычно catchall и SMTP релей настраиваются в паре. Поэтому когда говорят catchall, подразумевают наличие SMTP релей. Для Odoo по ее архитектуре весьма желательно, чтобы обе эти технологии были задействованы. Поэтому далее, упоминая одну технологию мы будем подразумевать вторую.

Человек по своей природе боится того чего не понимает. Это доказанный факт. Понимают ли пользователи, специалисты, экономисты,... технологии предлагаемые системой Odoo, чтобы объективно и безэмоционально судить об их: эффективности или неэффективности, масштабируемости или немасштабируемости, безопасности или небезопасности, низко-затратности или высоко-затратности,...? На сегодняшний день(23.03.2018) практически нет технических статей сравнивающих "классическую технологию заведения каждому сотруднику отдельного емейла" и технологию "Catchall + SMTP релей". Это тоже факт. И он говорит о слабом понимании, освоении, проверке,... данной технологии на практике.

Данная статья, служит для увеличения понимания данных технологий среди специалистов и пользователей. Со своей стороны, мы постарались(и всегда будем стараться) максимально объективно рассказать об технологиях catchall и SMTP релей. Мы ни в коем случае не приподносим их как панацею. В любом случае, в естественном отборе побеждают корпорации, применяющие бОлее: высокоэффективные, низкозатратные, масштабируемые и безопасные технологии. Поэтому время покажет какая технология останется у руля, а какая уйдет в аутсайдеры.

Еще один фактор: "Обжегшийся на молоке, дует на воду". Когда-то в интернете было множество таких открытых и даже бесплатных почтовых шлюзов-ящиков. Один из способов заработка таких веб-сервисов заключался во встраивании в каждое письмо рекламных сообщений. Но, к сожалению, любую технологию можно применять как во благо, так и во вред. И чем сильнее технология, тем сильнее эффект - положительный или отрицательный. История знает примеры, как хакеры подняв подобный открытый, бесплатный веб-сервис использовали его для: анонимизации переписки, встраивания в письма троянов, вредоносного кода, проникновение внутрь корпоративных сетей, атаку на ИТ инфраструктуру конкурентов, создание своих бот-нетов путем заражения компьютеров, кражу коммерческих данных конкурентов и, конечно же, рассылку спама(сейчас все это делается на VPN шлюзах с большим размахом). Звучит ужасно! Но только если не понимать, что это все возможно только для открытых SMTP релей. О корпоративных SMTP релей читайте ниже.

Почему же открытые SMTP релей это потенциальная угроза? Вот что Википедия говорит об открытых SMTP релей. Т.е. основная проблема, это спам.

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

Небольшое отступление. Вообще, понятие спама очень размытое. Например пользователь авторизуется на каком-то форуме, осознано подписывается на множество интересующих его рассылок, и с электронного ящика этого форума пользователь начинает получать массу писем. Это спам или нет? Очевидно, нет. Большой поток однообразных писем с одного емейла еще не говорит, что это спам. Потом пользователь может потерять интерес к этому форуму, но вместо того чтобы "Отписаться" он нажимает кнопку "в Спам". Другими словами этот пользователь говорит почтовому серверу: "Классифицируй как Спам все письма, отправленные мне от этого адресата". На некоторых сайтах действительно сложная процедура "Отписаться". Иногда чтобы Отписаться - нужно обязательно войти на оригинальный сайт, авторизоваться с вводом пароля(который нужно помнить), ввести капчу, согласиться что этот шаг пользователь делает в здравом рассудке и без давления на него кого бы то ни было... А на некоторых сайтах функционал Отписки, вообще отсутствует. Так что, всегда проще нажать "Это спам рассылка". Поэтому, если какой-то пользователь пометил какого-то отправителя как спамера, это еще не значит, что отправитель спамер. А вот если >50% получателей этого рассыльщика назовут его спамером, то почтовому серверу стоит задуматься, что делать с остальными письмами от этого адресата. И всеми будущими письмами, отправленными с этого емейла.

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

Вывод: достаточно сложно определить спам это или нет. Поэтому нельзя блокировать всех направо и налево, не убедившись действительно ли это спам рассылка.

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

Вывод: не корректно блокировать почтовые серверы и\или емейлы отправителя. Да и вообще будет смешно если Google заблокирует свои же собственные серверы gmail за то что кто-то запустил спам рассылку с gmail ящика.

Итак, почему открытый smtp релей - это находка для спамера? Получив пароль от такого ящика-шлюза, спамер может проводить массовую спамерскую рассылку, а в поле отправитель писать что угодно: "god@bless.you", "president@gov.internet", "bank@of.banks". А главное, спамер может для каждой интернет рассылки генерировать случайный емейл типа "spam-58234098123@only-fresh.spam". А что еще важнее, спамер может для каждого электронного письма в массовой многотысячной(многомиллионной) рассылке генерировать случайный или созданный по правилам электронный ящик.

Это дает спамеру то, что адресат, получив такое спамерское письмо, не может заблокировать спамера по емейлу-отправителя, добавив его емейл в черный список! Единственная возможность заблокировать спамера, это заблокировать catchall ящик, с которого идет поток спама. Что многие и делают. Более того, некоторые почтовые сервисы - сразу автоматически считают спамом письмо, если письмо физически отправлено с одного ящика(например my-catchall-email@some.domain), а в "Отправитель" стоит другой ящик(например "Vlasova-KM@best-global.corp"). Хотя это не корректное поведение(почему описано далее). Погружаемся дальше...

Допустим открытый ящик-шлюз дискредитирован и все письма отправленные с это электронного ящика автоматически перемещаются в папку спам сервером-получателем. Если этот ящик не принадлежит спамеру, то его такие санкции все равно не коснутся, и он продолжит свои злодеяния на другом ящике-шлюзе. Крайний всегда оказывается администратор, создавший(или позволивший создать) catchall ящик для спамера. Для веб-сервиса предоставляющий интернет пользователям данную услугу - эта блокировка грозит остановкой предоставления всей услуги, т.к. с этого catchall ящика проводят свои рассылки и другие клиенты. Чтобы обойти блокировку, ящик-шлюз можно программно создавать со случайным именем для каждого пользователя. Можно даже программно создавать stmp релей для каждой рассылки, для каждого письма. Это решает проблему помещения электронного ящика-шлюза в черный список. Но спамеры продолжат свою деятельность.

Ответом на это большими почтовыми серверами стал полный отказ в получении писем с ip адреса почтового сервера, с которого идет поток спама. Для владельцев бизнеса на открытых STMP релей - это новая головная боль, а в это время спамеры продолжают потягивать смузи на жарких пляжах, наблюдая на это все со стороны и фиксируя прибыль. Владельцы открытых STMP релей предпринимают новый ход: динамические ip адреса для своих почтовых серверов, содержащие catchall ящики. Это обходит проблему блокировки почтового сервера по ip адресу.

Ответом на это может стать блокировка всей подсети, содержащей почтовый сервер, с ip адреса которого идет поток спамерских писем. А вот это уже очень серьезно! Дело в том, что услугу "открытого stmp релей" обычно предоставляли провайдеры, у которых эта услуга была только маленькой частью в большом перечне услуг. Блокировка всей подсети провайдера - это остановка всех его серверов и услуг. Все сайты, которые у него хостятся - становятся недоступны. Понесут убытки сотни, тысячи бизнесов из-за рук одного спамера с многомиллионной рассылкой.

Так что википедия правильно говорит, что "открытого stmp релей" = "потенциальный спам рассыльщик". Поэтому сейчас если и можно встретить услугу "открытого stmp релей", то только при предоставлении скана паспорта, или оплаты кредитной картой, или подтверждения через смс... ну вы поняли.

Но проблема спама не только в "открытых" ящиках-шлюзах. Можно рассылать спам с бесплатных почтовых веб сервисов, если в них не стоят ограничители на количество отправляемых сообщений в единицу времени. Если заморочиться, то можно легко купить VPS сервер за 5 долларов биткоинами и самостоятельно на нем поднять почтовый сервер с динамическими емейлами и слать спам с них до тех пор пока ip не заблокируют. При этом вообще не используя технологию stmp релей! Потом купить новый VPS сервер или купить новый ip адрес, или новую подсеть за те же биткоины или эфириум... А технологии оркестрации виртуальных серверов и API провайдера позволяют это делать в один клик.

Что же делать читаем далее.

 Как мы писали выше, корпоративный smtp релей не допускает спам рассылок, кроме осознанных маркетинговых рекламно-акционно-скидочно-бонусных рассылок, и корпоративных поздравлялок клиентов на праздники. В любом случае, в отличие от спамера, человека запустившего корпоративную массовую рассылку всегда могут легко найти(даже если он(а) уже не работает в компании) органы правопорядка. Но как почтовому серверу отличить корпоративный catchall от открытого stmp релей? Если по старинке, то есть базы данных открытых SMTP релей. А если шагать в ногу со временем, то по проверке SPF записи домена!

Шаблон любого емейл-а это имя_почтового_ящика@доменое_имя. Можно проверить доменное имя в названии емейла, с которого было отправлено письмо и доменное имя в названии емейла отправителя. Это будет:

1. или несуществующее доменное имя(т.е. отсутствует в базе DNS), а так же доменное имя в "серых" интернет сетях

2. или доменное имя вэб-сервиса электронной почты(gmail.com, freemail.com, mail.ru,...)

3. или доменное имя принадлежащее определенному человеку, организации

Если несуществующее доменное имя, то такие письма можно сразу смело классифицировать как спам со всеми вытекающими.

Для остальных случаев есть проверка SPF

 Спамеры для обхода спам фильтров могут в качестве емейла отправителя указать что угодно. В том числе емейл действительно существующей электронный ящик, реальной организации, пользующейся уважением и доверием. При получении электронного письма(например от Google: admin@google.com), как проверить не поддельное ли оно? Для этого создана технология Sender Policy Framework.

Пример:

• Попытка отправки электронного письма
  

• Отправитель i_am_not_a_spamer@google.com

• Электронный ящик-отправитель может быть любой! Например: smtp_relay@mail.ru

• ip-адрес и маска подсети почтового сервера-отправителя данного письма. Например 217.69.139.112

Работает Sender Policy Framework так:

• при получении письма почтовый сервер-получатель, берет из емейла доменное имя Отправителя <google.com>

• формирует DNS запрос в базу данных регистрации доментов. Внимание: редактировать данные DNS записи, могут только владельцы соответствующего домена! В данном примере это владелец домена <google.com>.

• Почтовый сервер-получатель в базе DNS - запрашивает SPF запись для домена google.com. Т.е. спрашивает у владельца домена google.com: "Какие почтовые серверы имею право отправлять письма от имени домена google.com? Т.е. письма вида: ANY-email-or-any-text-or-somthing@google.com или mr-president@google.com?"

• Получаем строку вида: "v=spf1 include:_spf.google.com ~all"

• Запрашивает SPF для домена _spf.google.com

• Получаем строку вида: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

• Запрашивает SPF для домена _netblocks.google.com

• Получает строку вида: "v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all". Вот мы и добрались до разрешенных ip-адресов и разрешенных подсетей.
  

• Сверяет разрешенные IP-адреса(или маски подсетей, как в нашем случае)почтовых серверов-отправителей полученные из SPF с IP-адресом почтового сервера, который пытается сейчас отправить письмо(в нашем примере это 217.69.139.112). Если ip-адреса совпадают, то принимаем письмо. Если не совпадают, то проверяем все остальные поддомены: _netblocks2.google.com и _netblocks3.google.com
  

• Если не один ip-адрес не совпал, то почтовый сервер-получатель должен выполнить одно из SPF правил: +all(принимать все) или -all(не принимать) или ~all(мягко отклонить). В нашем случае это правило "~all" - мягко отклонить.
  

Стоит заметить, что еще не каждый почтовый сервер настроен на проверку SPF записей. Кроме того SPF очень сильно увеличивает количество запросов к DNS серверам для получения SPF записей. Количество DNS запросов для одного домена ограничено 10-ю запросами, поэтому будьте внимательны с составлением "include" для своей SPF записи. 

По этой ссылке вы можете получить SPF запись для любого, интересующего Вас, домена. Вбиваете интересующий вас домен и узнаете защищен ли этот домен. Этим же инструментом пользуются спамеры, чтобы узнать можно ли использовать данный домен для своей спамерсой рассылки или нет.

Так же вы можете узнать SPF запись командой: "nslookup -type=txt any-domain-name"

Про формат SPF записи и ее расшифровку можете почитать тут и тут.

Иногда в SPF запись включают ссылку на записи "a" типа данного домена. Другими словами, разрешают отправку писем со всех почтовых серверов(т.е. их ip адреса), которые указаны в записях типа A этого домена. Обычно записи A-типа это ip-адреса сервера сайта или балансира или прокси. Мы не рекомендуем ставить почтовый сервер(почтовую программу) на один сервер с сайтом. Должно быть: один сервер - одна задача. Поэтому если в вашей SPF записи есть инструкция " a ", то перепроверьте осознанно ли была она туда записана или она попала в SPF запись путем "слепого" копирования из примеров.

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

Оказалось, это был просто розыгрыш. Это было обычное письмо, но с подделанным отправителем.

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

Обратите внимание, для спамеров, спуферов, фишеров, социальных инженеров,... чтобы использовать ваш корпоративный емейл в своих злых целях, не важно настроен или нет для вашей компании catchall и\или SMTP релей. Другими словами, catch-all и корпоративный SMTP релей не ослабляют корпоративную безопасность(в данном контексте). Корпоративную защиту ослабляет отсутствие настроенных SPF правил на корпоративном домене или их неверная настройка!

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

Что значит "защитит Ваш домен"? Если спамеру удастся отправить массовую рассылку с емейлом в поле Отправитель <any-text@your-domain.corp>, то многие почтовые серверы со временем пометят эти письма как спам рассылку и включат ваш домен <your-domain.corp> в черный список. Таким образом спамер имеет возможность:

1. "подставить" любой бизнес с незащищенным доменом,

2. повысить репутацию(=успешность) своей рассылки, воспользовавшись репутацией чужой компании(Вашего домена)

3. "оставаться в тени" незамеченным, и продолжать свою деятельность

Для этого спамеру нужно пройти SPF проверку. Как он может это сделать?

Вначале рассмотрим пример корректных настроек. Если:

1. в настройках домена, заданы SPF правила,

2. и в SPF не стоит правило "+all"(принимать почту с любых серверов),

3. и на этих почтовых серверах нет открытых SMTP релей ящиков,

4. и в SPF явно заданы IP адреса только ваших почтовых серверов или тех, которые вы контролируете,

   те почтовые серверы, которым разрешено отправлять электронную почту от имени этого домена,

5. и спамер не может создать ящик на этих почтовых серверах или не может отправлять массово письма(например если задан лимит количества писем в единицу времени)

то у спамера нет возможности отправить спамерскую рассылку от имени этого домена. Его письма никогда не пройдут SPF проверку. Вообще-то отправить он может, но ему сервера-получатели не поверят и либо не примут письма, либо поместят в спам. По правилам, почтовые сервера-получатели должны выполнить то, что написано в SPF записи домена. Если написано, "жестко отказать" значит, так они и будут делать, если написано "принять с чужих почтовых серверов", значит письма будут загружены.

Важно упомянуть тот факт, что принимающим почтовым серверам не всегда выгодно открыто отвечать, что по каким-либо причинам - почтовое сообщение не будет принято. Системные администраторы настраивают "тихое"(тайное) удаление писем, для того чтобы путем брут-форс перебора - спамеры не могли вычислить какие на почтовом сервере есть почтовые ящики и собрать базу емейлов для продажи или для спам рассылки. Хотя есть механизмы как это обойти. С другой стороны, это создает проблему для остальных: если письмо по каким-либо причинам будет тайно удалено сервером-получателем, то отправитель не узнает об этом. Но вернемся к SPF.

В случае сторонних веб сервисов, таких как mail.ru, gmail, ... SPF не во всех случаях будут срабатывать. Если ваша корпоративная почта располагается на публичных почтовых серверах, то в SPF записи вы должны дать разрешение отправлять почту с почтовых серверов этого публичного почтового сервиса. Но т.к. этот сервис публичный, то спамер(или спуфер) так же может создать почтовый ящик на этом же почтовом сервисе и отправлять письма от имени вашего домена. Причем т.к. отправка фальшивых писем будет идти с того же почтового сервера, то SPF защита срабатывать не будет.

Но к счастью, для спамера не так все просто. Во многих публичных почтовых серверах всегда заданы лимиты на отправку почтовых писем. Иначе публичный почтовый сервис рискует оказаться забаненным по ip. Да и вообще не солидно иметь компанию и не завести корпоративные емейлы, а использовать бесплатные ящики вида @gmail.com, @mail.ru, @freemail.com.ua,... Так что мы рекомендуем взглянуть на Google Suite хотя бы из соображений корпоративной безопасности.

Итак, если у вас свои собственные почтовые серверы, которыми пользуются только ваши пользователи, то SPF должно быть достаточно(хотя DKIM и DMARK не помешает).

Если же вы используете публичные почтовые серверы, то вам необходимо купить у них корпоративную почту, подразумевающую привязку ваших емейлов к вашему доменному имени. Настройка SPF, DKIM и DMARK - обязательна.

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

Важно заметить, что на сегодняшний день не все почтовые серверы проверяют SPF, DKIM и DMARK. Поэтому возможности для спама и спуфинга еще есть.

О том как настраивать SPF, DKIM и DMARK есть отличная статья.

Мы выяснили:

1. почему SPF настраивать нужно обязательно

2. если почтовые серверы не ваши, то DKIM и DMARK маст-хэв

3. почему открытые STMP релей = спамер

4. чем опасен спам для корпоративного домена и корпоративной сети

5. почему закрытый(корпоративный) SMTP релей - это нормально, если маркетолог запускает массовую рассылку с согласования руководства и системного администратора

6. что такое спуфинг, фишинг и чем они опасены

7. как защитить корпоративный домен