company_banner

Игра в кошки-мышки: как создавался антиспам в Почте Mail.Ru и при чем здесь Tarantool



    Привет, Хабр! В этой статье я хочу рассказать о системе антиспама в Почте Mail.Ru и опыте работы с Tarantool в рамках этого проекта: в каких задачах мы используем эту СУБД, с какими трудностями и особенностями ее интеграции столкнулись, на какие грабли наступали, как набивали шишки и в итоге познали дзен.

    Сначала краткая история антиспама. Внедрять антиспам Почта начала более десяти лет назад. Первым решением, которое использовалось для фильтрации, стал Антиспам Касперского в паре с RBL (Real-time blackhole list — список реального времени, содержащий IP-адреса, тем или иным образом связанные с рассылкой спама). В результате количество нежелательных писем снизилось, но из-за особенностей работы системы (инертности) такой подход не удовлетворял поставленным требованиям: быстро (в режиме реального времени) подавлять спам-рассылки. Немаловажным условием было быстродействие системы — пользователь должен получать проверенные письма с минимальной задержкой. Интегрированное решение не успевало за спамерами. Спам-рассыльщики очень динамично меняют (видоизменяют) контент и модель своего поведения, когда видят, что их письма не доставляются до адресата, поэтому мириться с инертностью мы не могли. И начали разрабатывать свою собственную систему фильтрации спама.

    Следующим этапом в Почте Mail.Ru появился MRASD — Mail.Ru Anti-Spam Daemon. По сути он представлял собой очень простую систему. Письмо от клиента попадало на почтовый сервер Exim, проходило первичную фильтрацию c помощью RBL, после чего отправлялось в MRASD, где и совершалась вся «магия». Антиспам-демон разбирал сообщения на части: заголовки, тело письма. Дальше над каждой из них проводились простейшие нормализации текста: приведение к одному регистру, схожих по написанию символов к определенному виду (например, русская буква о и английская буква о превращались в один символ) и т. п. После того как нормализация выполнялась, извлекались так называемые сущности, или сигнатуры письма. Анализируя различные части почтовых сообщений, службы фильтрации спама блокируют на основании какого-либо содержания. Например, можно создать сигнатуру на слово «виагра», и все сообщения, которые содержат это слово, будут блокироваться. Другими примерами сущности служат URL’ы, картинки, вложения. Также во время проверки письма формируется его уникальный признак (fingerprint) — c помощью определенного алгоритма высчитывается множество хеш-функций для письма. По каждому хешу и сущности велась статистика (счетчики): сколько раз встречалась, сколько раз на нее жаловались, флаг сущности — SPAM/HAM (ham в терминологии антиспама — антоним термину spam, означающий, что проверяемое письмо не содержит spam-контента). На основе этой статистики принималось решение при фильтрации писем: когда хеш или сущность достигнут определенной частотности, сервер может заблокировать конкретную рассылку.

    Ядро системы было написано на С++, а значимая часть бизнес-логики унесена в интерпретируемый язык Lua. Как я упоминал выше, спамеры — народ динамичный и быстро меняют свое поведение. На каждое изменение нужно уметь сразу же реагировать, именно поэтому для хранения бизнес-логики решили использовать интерпретируемый язык (не нужно каждый раз перекомпилировать систему и раскладывать на серверы). Другим требованием к системе было быстродействие — у Lua хороший показатель по скорости работы, вдобавок ко всему он легко интегрируется в C++.



    На рисунке выше проиллюстрирована упрощенная схема передачи письма: от отправителя оно попадает на сервер, проходит первичные проверки (1), если успешно, то передается на проверку MRASD (2). MRASD возвращает результат проверки на сервер (3), и на его основе письмо либо кладется в папку «Спам», либо отправляется пользователю во входящие.

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

    Эволюция технологического стека


    В начале развития почтовых сервисов поток писем, да и их контент был намного более скудным, нежели чем в настоящий момент, но и выбор инструментов, и вычислительные способности были, мягко говоря, другими. Из описанной выше «родительской» модели MRASD видно, что для функционирования системы требовалось сохранять разного рода статистическую информацию. При этом процент «горячих» (т. е. часто используемых) данных был высок, что, несомненно, накладывало определенные требования на хранилище данных. В итоге для хранения «холодных» (редко обновляемых) данных выбор остановился на MySQL. Оставался вопрос: какое решение выбрать для хранения горячей (выпечки) статистики? Проанализировав доступные варианты (их производительность и функциональные возможности для хранения горячих, но не критически важных данных), выбор остановили на Memcached — на тот момент это было уже достаточно стабильное решение. Но оставалась проблема с хранением горячих важных данных: у Memcached, как у любого кеша, есть свои недостатки, один из которых — отсутствие репликации, а также проблема с прогреванием кеша, когда он падает (очищается). В результате поисков пристанища для наших важных и горячих данных выбор пал на нереляционную key-value БД Kyoto Cabinet.

    Шло время, нагрузки на почту, а как следствие — на антиспам росли. Появлялись новые сервисы, требовалось хранить все больше данных (Hadoop, Hypertable). К слову, в настоящий момент на пике количество обрабатываемых писем в минуту достигает значения в 550 тысяч (если усреднить этот показатель за сутки, то в среднем за минуту проверяется порядка 350 тысяч сообщений), объем анализируемых логов — более 10 Тб в день. Но вернемся в прошлое: несмотря на растущие нагрузки, требование к быстрой работе с данными (загрузка, сохранение) оставалось актуальным. И в какой-то момент Kyoto перестала справляться с необходимыми нам объемами. Кроме того, нам хотелось иметь более функционально богатый инструмент для хранения важных горячих данных. Словом, нужно было начинать крутить головой для поиска достойных альтернатив, которые были бы гибкими и легкими в использовании, производительными и отказоустойчивыми. В то время в нашей компании набирала популярность NoSQL БД Tarantool, которая была разработана в родных стенах и отвечала поставленным нами «хотелкам». К слову сказать, недавно, делая ревизию наших сервисов, я почувствовал себя археологом: наткнулся на одну из самых ранних версий — Tarantool/Silverbox. Попробовать эту базу данных мы решили потому, что заявленные benchmark’и покрывали наши объемы (точных данных о нагрузках на этот период нет), а также хранилище удовлетворяло наши запросы по отказоустойчивости. Немаловажный фактор — проект находился «под боком», и можно было быстро подкидывать свои задачи с помощью JIRA. Мы были в числе новичков, которые решили испытать у себя в проекте Tarantool, и думаю, что успешный опыт первопроходцев тоже нас подтолкнул к такому выбору.

    Тогда началась наша «эра Тарантула». Он активно внедрялся и до сих пор внедряется в архитектуру антиспама. В настоящее время у нас можно найти очереди, реализованные на базе Tarantool, высоконагруженные сервисы по хранению всевозможной статистики: репутации пользователей (user reputation), репутации отправителей по IP (IP reputation), доверительной статистики по пользователю (karma) и т. д. Сейчас ведется работа по интеграции модернизированной системы хранения и работы со статистикой сущностей. Предугадывая вопросы о том, почему мы в нашем проекте зациклились на одном решении и не переходим на другие хранилища, скажу, что это не совсем так. Мы изучаем и анализируем конкурирующие системы, но в настоящий момент Tarantool успешно справляется с отведенными ему задачами и нагрузками в рамках нашего проекта. Внедрение новой (незнакомой, не используемой ранее) системы всегда чревато осложнениями, требует много времени и ресурсов. Tarantool же в нашем (да и не только) проекте хорошо изучен. Программисты и системные администраторы уже на нем собаку съели и знают тонкости работы и настройки системы, чтобы она была максимально эффективна. Плюс также и в том, что команда разработчиков постоянно совершенствует свой продукт и обеспечивает поддержку (да и близко сидит, что тоже очень удобно :)). Так, при внедрении нового решения, основанного на хранении данных в Tarantool, я очень быстро получал от ребят ответы на интересующие меня вопросы и необходимую помощь (об этом я расскажу чуть позже).

    Дальше я проведу краткий обзор нескольких систем, основанных на этой СУБД, и поделюсь теми особенностями, с которыми пришлось столкнуться.

    Краткий экскурс в системы, где используется Tarantool


    Карма — это числовая характеристика, которая отражает степень доверия к пользователю. Задумывалась прежде всего как основа общей системы «кнута и пряника» для пользователя, построенной, не прибегая к сложным зависимым системам. Карма выступает в роли агрегатора данных, полученных от других репутационных систем. Идея системы проста: у каждого пользователя есть своя карма — чем она выше, тем больше мы доверяем пользователю, чем ниже, тем более жестко мы принимаем решения при проверке писем. Так, если отправитель посылает письмо с подозрительным контентом и имеет высокий рейтинг, письмо будет доставлено получателю. Низкая карма учитывается при принятии решения о спамности письма как пессимизирующий фактор. Эта система мне напоминает школьный журнал на экзамене. Отличнику зададут два-три дополнительных вопроса и отпустят на каникулы, а двоечнику придется попотеть, чтобы получить положительную оценку.


    Tarantool, хранящий данные, связанные с кармой, работает на одной машине. Ниже представлен график количества запросов, выполняемых на одном инстансе кармы в минуту.


    RepIP/RepUser


    RepIP и RepUser (reputation IP и reputation user) — высоконагруженный сервис, предназначенный для учета статистики об активности и действиях отправителей (пользователей) с конкретным IP, a также пользователя при работе с почтой за определенный временной интервал. С помощью данной системы мы можем сказать, сколько писем отправил пользователь, сколько из них было прочитано, а сколько помечено как спам. Особенность системы заключается в том, что при анализе поведения мы видим не мгновенную картину (snapshot) активности, а развернутую во временном интервале. Почему это важно? Представьте, что вы переехали в другую страну, где нет средств связи, а ваши друзья остались на родине. И вот спустя несколько лет к вам в хижину протягивают интернет. Вы залезаете в социальную сеть и видите фотографию своего друга — он очень сильно изменился. Как много информации вы можете извлечь из снимка? Думаю, не очень. А теперь представьте, если бы вам показали видео, в котором видно, как ваш друг меняется, женится и т. п., — этакая видеобиография. Думаю, во втором случае вы получите гораздо более полное представление о его жизни. Аналогично и с анализом данных: чем больше информации мы имеем, тем более точно мы можем оценивать поведение пользователя. Можно увидеть закономерность в интенсивности рассылки, понять «привычки» рассыльщиков. На основе такой статистики каждому пользователю и IP-адресу ставится мера доверия к нему, а также устанавливается специальный флаг. Именно этот флаг используется при первичной фильтрации, которая отсеивает до 70% нежелательных сообщений еще к моменту подлета письма на сервер. Данная цифра показывает, насколько значим сервис, поэтому от него и требуется максимальная производительность и отказоустойчивость. И для хранения такой статистики мы также используем Tarantool.



    Статистика хранится на двух серверах по четыре инстанса Tarantool на каждом. Ниже приведен график с количеством выполняемых запросов на RepIP, усредненных за одну минуту.


    При реализации этого сервиса нам пришлось столкнуться с рядом задач, которые были связаны с настройкой Tarantool. От описанных ранее систем данную отличает то, что размер пакета со статистикой, который хранится в RepIP/RepUser, значительно больше: средний размер пакета — 471,97 байта (максимальный размер пакета — 16 Кб). Пакет можно разбить на две логические составляющие: маленькая «базовая» часть пакета (флаги, агрегированная статистика) и объемная статистическая часть (детальная статистика по действиям). Работа с целым пакетом приводит к тому, что возрастает утилизация сети и время загрузки с сохранения записи выше. Ряду систем нужна только базовая часть пакета, но как ее вытащить из тапла (tuple — так именуется запись в Tarantool)? На помощь нам приходят хранимые процедуры. Для этого нужно в файл init.lua дописать необходимую нам функцию и вызвать ее из клиента (начиная с версии 1.6 можно писать хранимые процедуры на С).

    function get_first_five_fields_from_tuple(space, index, key)
        local tuple = box.select(space, index, key)
        --  Если запись не найдена — выходим
        if tuple == nil then 
            return 
        end 
        -- Формируем нужный нам tuple
        local response = {}
        for i = 0, 4 do -- Индексация идет с нуля, а не с 1
            table.insert(response, tuple[i])
        end 
        return response
    end
    

    Проблемы версий до 1.5.20


    Не обошлось и без приключений. После планового рестарта Tarantool клиенты (их было 500+) начинали стучаться на сервер и не могли подключиться (отваливались по тайм-ауту). Надо отметить, что не помогали и прогрессивные тайм-ауты — в случае неудачной попытки подключения время следующей попытки откладывается на некоторую увеличивающуюся величину. Проблема оказалась в том, что Tarantool за один цикл event-loop’а делал accept одному соединению (хотя в него долбились сотни). Проблему можно решить двумя способами: установкой новой версии 1.5.20 и выше или настройкой конфигурационного файла (нужно выключить опцию io_collect_interval, и тогда все будет хорошо). Команда разработчиков пофиксила эту проблему в кратчайшие сроки. В версии 1.6 она отсутствует.

    RepEntity — репутация сущностей


    В настоящий момент ведется интеграция нового компонента по хранению статистики для сущностей (URL, image, attach etc.) — RepEntity. Идея RepEntity похожа на описанную ранее RepIP/RepUser — она также позволяет иметь развернутую информацию о поведении сущностей, на основе которой принимается решение при фильтрации спама. Благодаря статистике RepEntity мы можем отлавливать рассылки спама, ориентируясь на сущности письма. Например, если рассылка включает «плохой» URL (содержащий спам-контент, ссылку на фишинговый сайт и т. п.), мы сможем быстрее заметить и подавить рассылку подобных писем. Почему? Потому что мы видим динамику рассылки этого URL’а и можем детектировать изменение его поведения, в отличие от «плоских» счетчиков.

    Основным отличием (особенностью) RepEntity от системы репутации IP, помимо измененного формата пакета, является существенный рост нагрузки на сервис (увеличивается объем обрабатываемых и хранимых данных и количество запросов). Например, в письме может быть до сотни сущностей (в то время как IP не более десяти), на большую часть из которых нужно загрузить и сохранить полный пакет со статистикой. Отмечу, что за сохранение пакета отвечает специальный агрегатор, который предварительно накапливает статистику. Таким образом, в рамках этой задачи существенно возрастает нагрузка на СУБД, что требует аккуратной работы при проектировании и внедрении системы. Хочу особо обратить внимание, что при внедрении данного компонента используется Tarantool версии 1.5 (это вызвано особенностями проекта), и дальше речь будет идти об этой версии.

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

    • затраты на хранение индекса;
    • затраты на хранение размера хранимых данных в ячейке тапла (1 байт);
    • ограничение на размер тапла — 1 Мб (в версии 1.6).

    Большое количество всевозможных запросов (чтений, вставок, удалений) приводило к тому, что Tarantool начинал тайм-аутить. Как выяснилось в ходе исследования, причина заключалась в том, что при частой вставке и удалении пакетов вызывалась сложная перебалансировка дерева (в качестве всех индексов использовался древовидный ключ — TREE). В этой БД какое-то свое хитрое самобалансирующееся дерево. При этом балансировка происходит не сразу, а при достижении какого-то условия «разбалансированности». Таким образом, когда дерево было «достаточно разбалансировано», запускалась балансировка, которая подтормаживала работу. В логах можно было увидеть сообщения типа Resource temporarily unavailable (errno: 11), которые исчезали через несколько секунд. Но во время этих ошибок клиент не мог получить интересующие его данные. Коллеги из Tarantool подсказали решение: использовать другой тип «деревянного» ключа — AVLTREE, который при каждой вставке/удалении/изменении производит перебалансировку. Да, число перебалансировок возросло, но их общая стоимость оказалась ниже. После того как новая схема была заправлена и был произведен рестарт БД, ошибка больше не проявлялась.

    Другой трудностью, с которой нам пришлось столкнуться, была очистка устаревших записей. К сожалению, в Tarantool (насколько мне известно, в версии 1.6 так же) не получится выставить TTL (time to live) для указанной записи и забыть про ее существование, переложив заботы об ее удалении на хранилище данных. Но при этом есть возможность написать вычищающий процесс самому на Lua на основе box.fiber. С другой стороны, такой подход дает большую свободу действий: можно писать сложные условия удаления (не только по времени). Но, чтобы написать чистящий процесс правильно, тоже нужно знать и учитывать некоторые тонкости. Первый вытесняющий процесс (cleaning fiber), который я написал, люто тормозил систему. Дело в том, что количество данных, которые мы можем удалить, значительно меньше общего числа записей. Для того чтобы уменьшить число записей — кандидатов на удаление, я ввел вторичный индекс по интересующему меня полю. После чего написал файбер, который обходил всех кандидатов (у которых время изменения меньше заданного), проверял дополнительные условия для удаления (например, что флаг записи не выставлен) и, в случае если оба условия выполнялись, удалял запись. Когда я тестировал без нагрузки, все прекрасно работало. С низкой нагрузкой тоже все шло как по маслу. Но как только я приблизился к половинной от ожидаемой нагрузки — возникли проблемы. У меня начали тайм-аутить запросы. Я понял, что где-то дал маху. Стал разбираться и осознал, что мое представление о том, как работает файбер, было неправильным. В моем мире файбер был отдельным потоком, который никаким образом (кроме переключения контекста) не должен был влиять на прием и обработку запросов от клиентов. Но позже я выяснил, что файбер использует тот же event-loop, что и тред по обработке запросов. Таким образом, итерируясь в цикле по большому числу записей, без операции удаления я просто «блокировал» event-loop, и запросы от пользователей не обрабатывались. Почему я упомянул операцию delete? Потому что каждый раз, когда выполнялся delete, происходил yield — операция, которая «разблокирует» event-loop и позволяет обработать следующее событие. Отсюда я сделал вывод, что в случае, если n операций (где n нужно искать эмпирически — я взял 100) выполнялось без yield, необходимо делать форсированный yield (например, wrap.sleep(0)). Также следует учесть, что при удалении записи может происходить перестроение индекса и, итерируясь по записям, можно пропустить часть данных для удаления. Поэтому есть еще один вариант удаления. Можно в цикле делать select небольшого количества элементов (до 1000) и итерироваться по этой 1000 элементов, удаляя ненужные и запоминая последний неудаленный. А после этого на очередной итерации выбрать следующую 1000, начиная с последнего неудаленного.

    local index = 0 -- Номер индекса, по которому будут выбираться ключи
    local start_scan_key = nil -- Первый индекс, с которого будем выбирать 
    local select_range = 1000 -- Количество записей, которое будем выбирать в select_range
    local total_processd = 0 -- Количество обработанных записей (tuple)
    local space = 0 -- Номер спейса 
    local yield_threshold = 100 -- Разрешенное количество запросов, которые не вызывают yield
    local total_records = box.space[space]:len() -- Общее число записей в спейсе
    while total_processed < total_records do
        local no_yield = 0
        local tuples = { box.space[space]:select_range(index, select_range, start_scan_key) }
    for _, tuple in ipairs(tuples) do -- Итерируемся по tuples 
        local key = box.unpack('i', tuple[key_index_in_tuple])
        if delete_condition then 
            box.delete(space, key)  --  delete делает yield
            no_yield = 0
        else
            no_yield = no_yield + 1
            if no_yield > yield_threshold then
                box.fiber.sleep(0)  -- Насильно делаем yield
            end
            start_scan_key = key -- Обновляем последний неудаленный ключ 
        end
        total_processed = total_processed + 1
    done
    

    Также в рамках данной работы была попытка внедрить решение, которое помогло бы безболезненно производить решардинг в будущем, но опыт оказался неудачным, реализованный механизм нес в себе большой overhead, и в итоге от механизма решардинга отказались. Ждем появление решардинга в новой версии Tarantool.

    Best practice:

    Можно добиться еще большей производительности, если отключить xlog’и. Но стоит учесть, что начиная с этого момента Tarantool будет выполнять роль кеша, со всеми вытекающими последствиями (я говорю об отсутствии репликации и прогревании данных после рестарта). Не стоит забывать и о том, что остается возможность делать периодически snapshot и при необходимости восстановить данные из него.

    В случае если несколько Tarantool работают на одной машине, то для увеличения производительности стоит «прибивать» каждый из них к ядрам. Например, если у вас 12 физических ядер, то не стоит поднимать 12 инстансов (нужно помнить о том, что у каждого Tarantool, помимо исполняющего треда, есть еще VAL-тред).

    Чего не хватает:

    • Шардинга.
    • Кластерного подхода с возможностью динамической конфигурации кластера, например в случае добавления узлов или выхода узла из строя, аналогичного для MongoDB(mongos), Redis (redis sentinel).
    • Возможности задания TTL (time to live) для записей.

    Подводя итоги


    Tarantool играет важную роль в системе антиспама, на нем завязано множество ключевых высоконагруженных сервисов. Готовые коннекторы позволяют легко использовать его в разных компонентах, написанных на разных языках. Tarantool хорошо зарекомендовал себя: за время использования БД в проекте не возникало серьезных проблем, связанных с ее работой и стабильностью при решении поставленных задач. Напомню, что есть ряд тонкостей, которые нужно учитывать при настройке БД (особенности для версии 1.5) для ее эффективной работы.

    Немного о планах на будущее:

    • Увеличение числа сервисов в проекте, работающих с Tarantool.
    • Миграция на Tarantool 1.6.
    • Также планируем использовать Sophia, в том числе и для задачи repentity, поскольку количество действительно горячих данных не так велико.

    P.S. Кстати, у нас в офисе 25 августа пройдет уже третий Tarantool meetup, если вы хотите больше узнать о нашей базе данных и лично пообщаться с разработчиками, регистрируйтесь и приходите!

    Mail.Ru Group

    674,00

    Строим Интернет

    Поделиться публикацией
    Комментарии 51
      –1
      Mail.ru и антиспам?? Я не смог прочитать статью, но выговориться хочу — именно из-за ваших «игр» с антиспамом я и ушёл от вас в Gmail. Вы развели какой-то бред с этим — мне приходилось вставлять пробелы и/или пустые строки, чтобы ваша антиспам система меня не забанила за отправку одинаковых сообщений своим друзьям (адреса друг другу я палить не хотел в «Копия»). У меня теперь психологическая непереносимость вашего почтового сервиса из-за всего, что вы там развели. Пользоваться Gmail — одно удовольствие.
        +2
        bcc / Скрытая копия?
          +4
          А давно вы перестали пользоваться нашей почтой? Просто ситуация с добавлением пробелов и переводом строк кажется странной. В статье я упоминал о стадии нормализации, которая делает преобразования с текстом. После этого этапа лишние пробелы и переводы строк уже не существуют. Если возникают проблемы — пишите, разберемся.
          Про добавления друзей в копию — как написал BigD в почте есть возможность отправить скрытую копию.
            0
            Я совсем немного пользуюсь — антиспам до сих пор не работает. Наверно не подключили
            +1
            Подпишусь под каждым словом.

            Ушел по той же причине. Ящик заблокировали за, якобы, рассылку спама. Пример разосланного спама предоставить отказались, как и сообщить, когда это происходило.
            Восстановить доступ к ящику без телефона тоже не дали.
            У меня теперь психологическая непереносимость вашего почтового сервиса из-за всего, что вы там развели. Пользоваться Gmail — одно удовольствие.
              +1
              Тоже хочется больше деталей. Когда ушли? Что сказали в службе поддержки и почему не получилось восстановить доступ?
                +1
                Когда — точно не вспомню, больше года уже.
                В службе поддержки отказались предоставлять какую-либо информацию. Я пытался донести мысль о том, что этот ящик практически не используется для отправки писем, что на него регистрация аккаунтов всяких завязана, что меня подломить не могли — иначе аккаунты уже поуводили бы. В поддержке требовали либо телефон для привязки, либо указать, когда я последний раз логинился туда. А логинился я более трех месяцев как, не помнил точно. Единственное, что я мог указать — некоторые письма во входящих и исходящих, которые я точно помнил (даты, темы, адресатов, содержание).
                Этого оказалось недостаточно. К тому моменту я просто устал бороться, и бросил свои попытки.
                На тот момент я пользовался почтовыми сервисами mail.ru, gmail, outlook.com, yahoo.com. Такого рода сложности возникали только с mail.ru, с разными аккаунтами. После того, как один из аккаунтов был заблокирован второй раз, я и ушел.
                  +1
                  Это все лишь для привязки телефона. Чтобы получить твой номер телефона.
                  У меня недавно так с ВК было. Номер не был привязан изначально. При лайках, сообщениях и прочих действиях требуют капчу или привязать номер. В итоге просто забанили (сказали что ваш 16 значный пароль из спец. символов, который я вводил по памяти на убунте, только из приватного окна попался злоумышленикам) и заставили привязать страницу типа «Пока вы не привяжите свой номер, мы не отдадим вам страницу»
                    0
                    Ок, а что, если нет телефона?
                      0
                      «Пока вы не привяжите свой номер, мы не отдадим вам страницу»

                      Я же написал. Сейчас ВК могут пользоваться нормально только с привязкой телефона. Если нет привязки, то ты ничего не сможешь в нем делать: ни общаться, ни лайкать, ни вступать в группы. На каждый клик выскакивает окно с капчей
                        0
                        Ну вот, значит быть посему. Гмейл у меня пока телефон не вымогает.
              +1
              у gmail удобней почта и антиспам хороший, соглашусь
                0
                У меня общий ящик уже на яндексе, пересылка идет с десятка эмейлов, спам не пересылается. И только лишь с маилру идет спам и попадает в яндексе в папку спам.
                Плюс их подпись «Проверено антивирусом, вирусов нет.» Кажется только надпись. Пробовал прислать другу троян, просто экзешник и все спокойно прошло. Скачай его конечно у него заругался антивирь
                +7
                Антиспам, tarantool… всё это прекрасно.
                Только вот завёл я как-то эксперимента ради ящик с непроизносимым именем вроде skld54wjh3445nsdfe9r87sdjhbs@mail.ru
                Нигде его не публиковал, никому с него не писал, только заходил время от времени в учётку, чтобы какая-то активность была.
                Через две недели после регистрации в ящике появились первые спам-письма. Антиспам их отлавливал, но сам факт! Как такое может быть?
                Впрочем, через какое-то время в ящике стали появляться и неотловленные письма.
                Саппорт обещал разобраться, но ответа второй год жду =)
                  +5
                  Кажется у mail.ru создаются с каждым ящиком разные аккаунты-страницы в мой мир и т.п. сервисах, а ссылки этих аккаунтов выглядят как /bk/vashlogin/ и они просто парсятся спамерами как почтовые ящики. Помню такое было пару лет назад, не знаю, исправили ли это или нет.

                  Основная проблема с почтой mail.ru, что нормальные письма не то что не попадают в папку спам, они вообще до ящика не доходят. Это самое ужасное. Часто наши письма на mail.ru даже со ссылкой на восстановление пароля не доходят вообще на ящик. С другими почтовыми системами такой проблемы нет.

                  Т.е. вы фильтруйте, но пусть вся почта все равно поступает в папку «спам», а не не пропадает где-то в фильтрах.
                    0
                    Я проверял только «мой мир» — там требовалось пройти активацию, чтобы учётка создалась. Но кто знает, какие ещё сервисы есть у мейла?
                    В любом случае, если оно так, то это глупость, граничащая с идиотизмом.
                      +1
                      Маилрушный агент, в основном оттуда все берется.
                      0
                      А с проблемой доставки писем обращались в службу поддержки, и была ли она решена? Если нет, то присылайте номер тикета, мы узнаем подробности и разберемся.
                        +1
                        Как раз по этой причине уже несколько лет пользуюсь почтой mail.ru. Завел почтовый ящик. Настроил из него забор писем и скармливание spamassasin как 100% спам. Уже на следующий день спам фильтр стал обучаться новыми письмами.

                        Забыл о спаме с mail.ru. Отличный сервис по-моему.
                        +2
                        Такое имело место быть: как написал Matyushko существовала проблема с засвечиванием ящиков в других сервисах mail.ru, которой активно пользовались спамеры. На нашей стороне мы провели работу, чтобы улучшить защиту от ботов, которые используют эту информацию.
                        0
                        О да, антиспам, который ваши же письма спамом считает, это просто высший класс )))
                        image
                          +10
                          Это как раз нормально — лишний раз доказывает что антиспам рабочий:)
                            +3
                            Скорее всего вы кликали спам на подобное письмо от «работы». Если перешлете письмо, выясним наверняка.
                              0
                              ну можно :) а куда пересылать? vможет и правда кликнул случайно…
                                0
                                таки ложное срабатывание их антиспама :)
                              +1
                              Я думаю, у всех такой период был.
                              image
                              +3
                              Все красиво расписано, но по-факту без мата вспоминать ваш сервис сложновато.

                              У нас финансовый сервис, около 300к подписчиков по емейл во всем мире. С мейл.ру всегда проблемы, вот вообще всегда — письма даже вида ваш месячный баланс или восстановление пароля иногда пачками уходят в спам. Ваша прекрасная служба поддержки произносит один и тот-же чудесный ответ: улучшайте качество рассылки, даже однократные сигналы от пользователей могут отправить рассылку в спам.

                              С другими почтовыми сервисами проблем вообще нет. После 4 или 5 контакта с вашей ТП просто забили на это дело и попросили пользователей использовать ящики на нормальных сервисах.
                                +1
                                А можете дать нам номер последней заявки, чтобы мы смогли проанализировать ситуацию?
                                Решение о блокировке писем принимается по совокупности факторов, одного нажатия кнопки «Это спам» недостаточно.
                                О факторах, которые могут повлиять на доставляемость писем, мы писали здесь: https://habrahabr.ru/company/mailru/blog/216535/
                                Общую информацию о правилах рассылок можно прочесть тут: https://help.mail.ru/mail-help/rules/info
                                  +1
                                  Как владелец (в недавнем прошлом) менее мощного листа рассылки соглашусь. Получатели на mail.ru испытывали регулярные проблемы с её получением. Правда, надо сказать, поддержка принимала некоторое участие в их устранении.
                                  Но сам факт.
                                  +1
                                  У вас дурацкая система пересылки какая-то. Если пользователь user@mail.ru настроил у себя пересылку писем на user@domain.tld, то пересылаемое письмо отвергается почтовым сервером domain.tld в случае если домен оригинального отправителя имеет SPF "… -all". Вы как бы со своих IP пытаетесь слать почту от моего имени? Плохо! Шлите лучше от себя (MAILFROM=user@mail.ru), а меня указывайте во всяких from и reply-to.
                                    0
                                    Это, походу, не у них, это архитектурно так. У меня та же засада. Как решить — пока не придумал.
                                    Ну, т.е. теоретически да, поменять заголовки там, все такое. Как это реализовать на постфиксе?
                                      0
                                      Как там на постфиксе и я не знаю, но для публичного почтового сервиса это не должно быть проблемой. Вот специально проверил gmail — сделал в настройках user@gmail.com пересылку на user1@domain.tld и послал письмо с user2@yandex.ru на user@gmail.com. В результате в ящике user1@domain.tld имеем письмо:

                                      Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.85.217.173; helo=mail-ua0-f173.google.com; envelope-from=user+caf_=user1=domain.tld@gmail.com; receiver=user1@domain.tld


                                      Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com [209.85.217.173])
                                      by mail.domain.tld (Postfix) with ESMTPS id EC2D91FFC2
                                      for <user1@domain.tld>;


                                      From: <user2@yandex.ru>
                                      Envelope-From: user2@yandex.ru
                                        0
                                        для публичного почтового сервиса это не должно быть проблемой

                                        Согласен целиком и полностью.
                                        А вообще спасибо за камент, ты натолкнул меня на мысль, куда копать.
                                          0
                                          Они включили reject в DMARС, скорее всего из-за этого письма не доходят.
                                      +1
                                      Более 10и лет был ящик на mail.ru, не главный, но всё же.., внезапно: «Мы предполагаем, что ваш почтовый ящик был взломан. С целью защиты ваших данных, мы временно заблокировали доступ к ящику.»
                                      Что мне до ваших предположений? Давайте я сам разберусь что там у меня. А № телефона самому дать спамерам — верх глупости.
                                      Так ящик и умер.
                                        +1
                                        В вк похожая ерунда. Так они еще и антивирус присылают, который какую-то рекламу по умолчанию ставит.
                                        Автору за статью спасибо, но работаете вы в отвратнейшей конторе.
                                        +2

                                        Зря вы тут ругаете автора статьи.
                                        Есть баги — пишите в саппорт…
                                        У меня ящик на mail с 1998 года… и я давно настроил с него редирект всей почты на gmail (как только получил инвайт), но на всех новых регистрациях указываю mail ящик именно из-за рабочего антиспамфильтра.

                                          +1
                                          Чем графики выводятся? Это что-то встроенное в тарантул?
                                            0
                                            graphiteapp.org
                                              0
                                              dk547 прав, это graphite.
                                              0
                                              Как же mail задолбал со своим пиаром тарантула.
                                                +1
                                                Краткий список писем моего ящика «СПАМ» в mail.ru
                                                — METRO Cash & Carry
                                                — Мобиллак, Подарок для любимого клиента – Ваша персональная скидка!
                                                — штук 10 поздравлений с днем варенья от друзей и компаний
                                                и т.д.

                                                Зато Cytoday на греческом и LiveInternet приходит регулярно, хоть я уже раз 20-ть помечал как мусор.
                                                  +1
                                                  Спасибо, было интересно!
                                                  Также планируем использовать Sophia

                                                  может лучше планировать использовать vinyl и мигрировать на 1.7?
                                                    0
                                                    Да, для новых задач имеет смысл ориентироваться на версию 1.7, но переводить уже существующие сервисы начнем, когда 1.7 станет stable.
                                                      0
                                                      Пишу прототип для брокера на форексе взамен джавы. Критично — вывод запросов на исполнение, рефрешей и маркетдаты в одного тарантула с последующей раздачей апдейтов через node.js. Надо в 10 раз быстрей. Пока изворачиваюсь и режу логику, но вам придется реально придумать выкрутасы чтоб залезть к банкирам. Текущей скорости с array-ями не хватит для риск мэнэджмента, а реально надо :) Надо убить KDB, иначе будет стыдно перед потомками
                                                        0
                                                        Пользовался почтой майл 5 лет, но потом ушел на гугл. Постоянно приходил спам, даже на почту которая была создана(новая) и нигде с ней не регистрировался. То игры какие то рекламировали то ещё что нибудь. Вообщем сижу на гугл и проблем не знаю.
                                                          0
                                                          Не смотря на все постоянно мне приходит спам, в том числе и фишинговые письма. Получается все зря?
                                                            0
                                                            Не зря! Можете прислать мне пример писем личным сообщением?
                                                            0
                                                            А магия исчезновения писем исправлена?
                                                            У меня были проблемы с отправкой писем на mail.ru в двух форматах (text/plain и text/html) — Все почтовики нормально видят. Ваш не показывает письма, даже в спам не приходят.

                                                            Писал вам в ТП. Мягко послали на… В соц сетях отписался — менеджер попросила переслать письмо с проблемой по другому адресу.
                                                            Через два месяца мне пришел ответ с вопросом, цитирую:
                                                            «Ваша проблема еще актуальна?»

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

                                                            Криво? Да криво, но как по другому?
                                                              0
                                                              Можете личным сообщением отправить номер заявки, которую создавали и адрес электронной почты с помощью которой вы общались с менеджером?
                                                                0
                                                                Сообщение отправил.

                                                                Небольшая правка моего комментария. За пол года в голове две проблемы сложились в одну.

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

                                                                2. Проблема с отправкой писем в двух форматах (Content-Type: multipart/alternative). Проблема актуальна и если мы сможем ее решить, я буду очень рад.

                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                            Самое читаемое