Парсинг почтовых аккаунтов Python, Django. Модульный скрипт

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

В процессе рассылки писем, в результате разработанного модуля, он должен решать задачу:

Какой процент писем идет в папку спам, какой во входящие.

Соответственно, необходимо разработать модуль, который будет наши контрольные

почтовые ящики парсить, искать в письмах определенную метку, далее смотреть в какой папке (спам/входящие) письма с нужными метками попало и делать запись в БД (или промежуточно редис).

То есть мы даем список емайл ящиков, например 100шт, в них будут сливаться письма с

определенными метками, задача просканировать каждый ящик и каждое новое

(непрочитанное) письмо, в папках (входящие/спам)на предмет нахождения

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

В заголовке нужно спарсить строку, которая начинается на X-1 и

заканчивается на 0 до двоеточий, например 'X-12F73B20:' или 'X-14CE20:' и

тд.

В это строке 'X-12F73B20:' или 'X-14CE20:' зашифрован id клиента, который размещен между 1...0 причем все литеральные символы

aBfEC и тд игнорим, они буду генерироваться случайно, то есть например

'X-12F73B20:' = id клиента 2732, 'X-14CE20:'  = id42.

Далее после ':' идет строка в base64 с данными. В ней содержатся несколько данных, которые нужно декодировать и размещать в БД.

Например метку мы отправим в заголовок такую:

X-12F73B20: MTsxLjEuMS4xO2RvbWVuLnJ1O3JlZGlyZWN0LnJ1

В почте это выглядит например как: http://joxi.ru/n2Y1R7ZSZK11o2То есть X-12F73B20: = id клиента 2732, далее декодируя строку

MTsxLjEuMS4xO2RvbWVuLnJ1O3JlZGlyZWN0LnJ1 получим без кавычек

"1;3;1.1.1.1;domen.ru;redirect.ru" — это строка содержит набор 5х

данных, разделенные точкой с запятой ';' которые надо собирать и писать в

БД.

Если взять строку "1;3;1.1.1.1;domen.ru;redirect.ru", то получим:

1 - id_send

3 - id_var

1.1.1.1 - ip

domen.ru - from

redirect.ru - redirect Также нужно вычислить mx, домена контрольного ящика, то есть, если

контрольный почтовый ящик сидит на домене mail.ru, mx запись через dns =

mxs.mail.ru она тоже нужна для бд (есть такой столбец).

Итоговая таблица состоит из столбцов:

id|id_client|id_send|id_var|mx|proxy|from|redirect|folder|time

Если мы отправляем строку X-12F73B20:

MTsxLjEuMS4xO2RvbWVuLnJ1O3JlZGlyZWN0LnJ1 на контрольный ящик mail.ru, и

она попадает в папаку inbox то запись в бд будет:1|2732|1|3|mxs.mail.ru|1.1.1.1|domen.ru|redirect.ru|inbox|1587744771

Далее для вычисления общего процента "спама" и "инбокса" для рассылки по клиенту, мы

запрашиваем SELECT COUNT данные WHERE есть id_client, id_send, folder

(inbox и spam)

выдрав данные с where folder = inbox например равное 50шт, и where folder = spam равное, например 10шт, получаем 83% = inbox и

17% = spam.

Что изменилось:

Ранее было предложение, что на вход скрипта подавать дату и метку, чтобы искать на все тело письма, решили изменить

схему, для большей изоляции модуля от других, сделав его автономным,

также исключили скачивание всего письма для скорости, и экономии трафа,

плюс сейчас нужны только технические заголовки.

Дату исключили - парсим просто не прочтенные письма. То есть для парсинга, исключили какие либо входные

данные в скрипт, скрипт модуля автономно парсит в бесконечном цикле все

новые письма и по правилу просто ищет строку X-1...0: base64 и заливает

найденные данные в БД, с БД уже будут строить данные селекторами по процентам в

какой папке было письмо.

Желательно работать многопоточно и быстро, практически результат был в Real-Time в процессе рассылки. У

нас используется redis, mariadb, поэтому где какие промежуточные итоги

работы, куда писать для скорости - решать вам. Также можно использовать стандартный django cache он у нас через редис также.

(Нужно меть возможность подключаться через прокси)

Работать должно на mail.ru/ya.ru/gmail.com и прочие, так как там везде протокол

один (IMAP), по идее реализовав в одном месте, везде должно

отрабатывать.  ##############Рекомендации от тимлида для совместимости и простой интеграции:

Этот модуль нужно разработать как django app, как вариант фоновая задача с

использованием celery task (http://docs.celeryproject.org/projects/django-celery/en/2.4/introduction.html).Для получения результата от работы модуля - делается некий асинхронный таск который на вход принимает уникальную

id_client и id_рассылки. Рассылка это django model с названием "campaign",

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

app, со следующими полями:

id, emails_total_count, emails_spam_count, emails_inbox_countПосле завершения разработки или в какой то момент, просто поменяем путь импорта и подключим в основной проект.Таск проверяет отправленные письма и в конце результат напишет на бд

(модел). Для потерянных, т.е. для тех писем которые нету не в спам и не

во входящих, ничего делать не нужно, просто нужно написать на логи что

не найден. Для логирования нужно использовать стандартный logging django

(https://docs.djangoproject.com/en/2.2/topics/logging/).Насчет отметки как прочитанное. Думаю этого делать не нужно, скорее можно подумать

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

Важно - новые очищать нельзя, чтобы антиспам фильтра не признали письма как негативные,

только старые и прочтенные.

Возможно celery таск по проверке будет триггерить следующий таск по

чистке по завершений.Нужные аккаунты с прокси должно хранится в db и должны быть подключены к

django admin. Т.е. нужна таблица accounts где хранится логин пароль и

domain (это можно вынести на отдельную таблицу), вторая таблицы proxies

это просто список прокси возможно с логин пароль для авторизаций на

прокси, и нужна таблица где устанавливается связь между accounts и

proxies там настраивается для какого аккаунта нужно использовать какой

прокси. Итого, используемые технологий:

python - 3.8

django - 2.2

celery - 4.4.1

база данных mysql (но так как используется django orm при разработке можете использовать sqlite)

os в основном linux. Также можно использовать стандартный django cache он у нас через редис также.