Redis и Fastmail: хранение фильтров писем

Redis и Fastmail — два мощных инструмента, которые редко упоминаются вместе, но при правильной интеграции способны решить одну из насущных задач современной почтовой инфраструктуры: эффективное хранение и быстрое применение фильтров писем. Fastmail — это защищённый, функциональный почтовый сервис, ориентированный на профессионалов и технофилов, предлагающий гибкие правила сортировки входящей корреспонденции. Redis же — высокопроизводительная in-memory база данных, идеально подходящая для кэширования, хранения временных состояний и быстрого доступа к данным. Объединив их, можно создать систему, где фильтры писем обрабатываются не только на стороне Fastmail, но и в распределённой среде с предварительной обработкой, логикой машинного обучения или внешними API.

Сегодня многие пользователи и команды сталкиваются с перегрузкой почты: тысячи писем, автоматические уведомления, рассылки, CRM-алерты. Хотя Fastmail предлагает продвинутую систему фильтров (на основе условий и действий), она ограничена внутренним движком и интерфейсом. Для сложных сценариев — например, адаптивные фильтры на основе поведения, временные правила, межплатформенные триггеры — требуется внешняя система обработки. Именно здесь Redis проявляет свои сильные стороны: скорость, простота интеграции и поддержка структур данных, таких как хэши, списки и множества.

Зачем соединять Redis и Fastmail: реальные кейсы

Fastmail предоставляет удобный интерфейс для создания фильтров: вы задаёте условия (например, «отправитель содержит @newsletter.com») и действия («переместить в папку Новости»). Однако такие правила статичны. Они не адаптируются под контекст, время суток или поведение пользователя. Представьте, что вы хотите временно отключать фильтры во время отпуска или блокировать рассылки по анализу темы письма с помощью NLP. Встроенные средства Fastmail не справятся.
Redis становится буфером между внешней логикой и почтовым аккаунтом. Вы можете хранить в нём:

• активные/неактивные фильтры;
• статистику по срабатыванию правил;
• временные метки для отложенного применения;
• динамические шаблоны на основе ML-моделей.

Например, компания получает сотни заявок через контактную форму. Каждая генерирует письмо на адрес support@company.fm. С помощью скрипта, который опрашивает IMAP и сверяется с Redis, можно определить, является ли письмо дублем (по хэшу тела), и автоматически помечать его как «спам», даже если отправитель легитимный. Такой уровень контроля невозможен без внешнего хранилища.

Как Fastmail обрабатывает фильтры: архитектура и ограничения

Фильтры в Fastmail создаются через веб-интерфейс или JMAP API. При поступлении нового письма сервер последовательно проверяет все активные правила. Первое совпадающее правило применяется, остальные игнорируются — принцип «первый матч, первый результат». Это упрощает логику, но снижает гибкость.
Каждое правило может содержать до 10 условий и 5 действий. Условия включают:

• отправителя, получателя, тему, тело письма;
• наличие вложений;
• размер письма;
• соответствие спам-рейтингу.

Действия: перемещение в папку, удаление, пересылка, установка флажка и т.д. Ограничения:

• нет циклов или переменных;
• нельзя использовать внешние данные;
• фильтры нельзя программировать на Python или JavaScript;
• максимум 1000 правил на аккаунт.

Такая модель отлично подходит для рутинных задач, но не для адаптивной фильтрации. Например, вы не можете создать правило: «Если сегодня пятница и в письме больше трёх ссылок — отправить в карантин». Для этого нужен внешний процессор.

Роль Redis в системе фильтрации: что хранить и как

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

Что можно хранить в Redis

Такой подход позволяет отделить конфигурацию от исполняемой логики. Например, скрипт каждые 30 секунд проверяет значение `filter:status:vacation_mode`. Если оно равно `»active»`, он временно переопределяет поведение других фильтров: вместо сортировки всё перемещается в папку «Отпуск».

Формат хранения правил

Хотя Redis не хранит фильтры в формате Fastmail напрямую, можно сериализовать их в JSON и использовать как шаблон:
«`json
{
«id»: «filter_news_001»,
«enabled»: true,
«conditions»: [
{«field»: «from», «op»: «contains», «value»: «newsletter»}
],
«actions»: [
{«type»: «move», «folder»: «News»}
],
«ttl»: 86400,
«last_triggered»: 1744783200
}
«`
Этот объект можно хранить по ключу `rule:filter_news_001` и читать при старте обработчика. TTL (время жизни) позволяет автоматически удалять временные правила.

Интеграция через API: шаг за шагом

Чтобы связать Redis и Fastmail, нужен промежуточный сервис — например, Python-скрипт на сервере или в Docker-контейнере. Он будет:

1. Подключаться к Redis;
2. Опрашивать IMAP или JMAP API Fastmail;
3. Принимать решения на основе данных из Redis;
4. Выполнять действия через JMAP (перемещение, удаление и т.д.).

Шаг 1: Настройка JMAP API в Fastmail

Fastmail поддерживает JMAP — современный протокол для работы с почтой. Получите API-токен:

• Зайдите в настройки аккаунта → «Пароли и приложения»;
• Создайте новый токен с правами «Почта (чтение и запись)»;
• Сохраните токен в безопасном месте.

Пример запроса на получение новых писем:
«`http
POST /jmap/
Authorization: Bearer YOUR_API_TOKEN
Content-Type: application/json
{
«using»: [«urn:ietf:params:jmap:core», «urn:ietf:params:jmap:mail»],
«methodCalls»: [
[«Email/query», {
«accountId»: «u12345»,
«filter»: { «isUnread»: true }
}, «single.Email/query»]
]
}
«`

Шаг 2: Подключение к Redis

Установите клиент Redis (например, `redis-py`) и подключитесь:
«`python
import redis
r = redis.Redis(host=’localhost’, port=6379, db=0)
vacation_mode = r.get(‘filter:status:vacation_mode’)
if vacation_mode == b’active’:
# Применить режим отпуска
«`

Шаг 3: Логика обработки

Алгоритм:

• Получить новые письма через JMAP;
• Для каждого письма вычислить хэш тела и заголовков;
• Проверить наличие хэша в Redis (антидубль);
• Сравнить отправителя с blacklist в Redis;
• При соответствии — вызвать JMAP-действие (например, moveEmail).

Пример действия:
«`python
# Переместить письмо в папку Spam
r.execute_command(«JSON.SET», «rule:new_filter», «.», json.dumps(rule_data))
«`

Шаг 4: Автоматизация и мониторинг

Запускайте скрипт через cron или systemd каждые 30–60 секунд. Для отказоустойчивости:

• Логируйте все операции;
• Используйте lock-ключи в Redis, чтобы избежать параллельного запуска;
• Настройте алерты при ошибках авторизации.

Практические сценарии использования

Сценарий 1: Динамический черный список

Команда маркетинга хочет блокировать письма от определённых доменов, но список меняется ежедневно. Решение:

• Администратор добавляет домен в Redis через веб-интерфейс;
• Скрипт каждые 5 минут обновляет локальный кеш;
• При получении письма проверяется домен отправителя.

Сценарий 2: Фильтрация по поведению

Если пользователь в течение недели ни разу не открывал письма от «weekly.report@data.com», система автоматически добавляет их в правило «Переместить в Архив». Redis хранит счётчик просмотров и дату последнего открытия.

Сценарий 3: Временные правила

Проект длится 2 недели. Все письма с темой «[ProjectX]» должны попадать в отдельную папку. Правило создаётся в Redis с TTL=1209600 (14 дней). После истечения — автоматически удаляется.

Сценарий 4: Интеграция с ML

Модель классифицирует письма на «срочные», «информационные», «рассылки». Результаты кэшируются в Redis. Скрипт применяет соответствующие действия через JMAP: выделение цветом, уведомления.

Ошибки и как их избежать

Ошибка 1: Избыточная нагрузка на API Fastmail

Частые опросы JMAP могут привести к временной блокировке. Решение — соблюдайте rate limit (Fastmail допускает ~60 запросов в минуту). Используйте long polling или вебхуки, если доступны.

Ошибка 2: Потеря данных при сбое Redis

По умолчанию Redis хранит данные в памяти. При перезагрузке всё исчезает. Активируйте сохранение на диск:

• RDB (снимки через заданные интервалы);
• AOF (журнал всех операций).

Ошибка 3: Конфликты между локальными и серверными фильтрами

Если и Fastmail, и ваш скрипт перемещают одни и те же письма, возможна путаница. Решение — отключите дублирующие правила в интерфейсе Fastmail. Оставьте только те, что не затрагиваются внешней системой.

Ошибка 4: Отсутствие резервного копирования правил

Правила в Redis — это код. Храните их также в Git или другом VCS. Используйте скрипты экспорта/импорта.

Экспертное мнение

Сочетание Redis и Fastmail — не стандартное решение, но оно оправдано в средах, где требуется высокая степень контроля над почтовыми потоками. Ключевой принцип: Fastmail остаётся источником истины для хранения писем, а Redis — источником истины для логики фильтрации.
Главное преимущество — декомпозиция. Вы можете менять правила без перезагрузки системы, масштабировать обработку на несколько узлов, внедрять A/B-тестирование фильтров. Например, 10% писем обрабатываются по новому алгоритму, результаты сравниваются в Redis.
Не стоит использовать эту архитектуру для простых случаев. Если вам достаточно 10–20 статичных правил — хватит встроенных средств Fastmail. Но при росте объёма, сложности или необходимости интеграции с CRM, ERP, аналитикой — внешнее хранилище становится необходимостью.
Рекомендации:

• Используйте Redis как state-менеджер, а не как основное хранилище писем;
• Синхронизируйте состояние между Redis и Fastmail при старте;
• Ограничьте размер хранимых данных — только метаданные и флаги;
• Шифруйте чувствительные данные (например, API-токены) при хранении в Redis.

Вопросы и ответы

Заключение

Интеграция Redis и Fastmail открывает новые возможности для управления почтовыми фильтрами за пределами стандартного функционала. Хотя Fastmail предлагает надёжную и простую систему правил, её статичность становится узким местом при усложнении рабочих процессов. Redis компенсирует это, обеспечивая динамическое управление, хранение состояний и возможность интеграции с внешними системами.

• Redis идеален для хранения динамических правил, статусов и метаданных фильтрации.
• Интеграция осуществляется через JMAP API и фоновые скрипты.
• Решение оправдано при наличии сложных, изменяемых или временных сценариев.
• Обязательно предусмотрите резервное копирование, безопасность и отказоустойчивость.
• Тестируйте на staging-среде перед внедрением в production.