Comments 3
Не хочу показаться занудой или задеть коллегу-айтишника, но масштаб решения здесь явно не соответствует задаче. Силы уходят не на фриланс как способ заработка, а на написание собственного почтового сервера без учёта одного корнер-кейса, другого, третьего — причём вылезут они, конечно, не сразу.
Чем плох вариант поднять по мануалу готовые SMTP и IMAP локально? Не хочется самому , так позовите llm и поставьте задачу поднять и настроить (про Postfix согласен, возьмите Exim, там конфиг более процедурный). Да что там, существуют и готовые сборки, хоть скриптом установки, хоть в докере. Затем, если хочется пописать код, для красоты можно реализовать IMAP IDLE и получать уведомление о новом письме практически мгновенно, не переписывая половину почтовой инфраструктуры.
Потому что иначе получается странная оптимизация: до Telegram сообщение долетает с минимальной задержкой, а дальше за ним всё равно сидит человек. Он должен быстро ответить, уточнить задачу, договориться о цене, получить предоплату, сделать прототип, обработать правки и сдать результат. Скорость всей системы по-прежнему определяется не SMTP-сервером, а человеком за Telegram.
Вот когда LLM начнёт сама вести переговоры, брать предоплату, выполнять заказ, сдавать его и получать оплату, тогда уведомление автору действительно можно будет оставить последним этапом. А там, глядишь, и биржа просто пропишет ваш почтовик вместо mx для своих доменов, с такой-то скоростью!
по корнер-кейсам согласен, лимита на размер письма и таймаута на чтение в текущей версии нет, raw_bytes растёт неограниченно пока не придёт терминатор. это реальная дыра, поправлю.
по imap idle не соглашусь. там нужно хранить логин и пароль пользователя от его почты, это принципиально другой уровень риска и ответственности, чем форвардинг на служебный адрес, где я вообще не вижу и не храню чужие credentials. плюс это отдельное живое соединение на каждого юзера к чужому imap-серверу, с чужими лимитами и обрывами, у меня таких юзеров сотни.
по готовому exim в докере тоже не соглашусь. очередь, ретраи, dkim, spf, конфиги под виртуальные домены, systemd-юниты, логротейт, это тоже зоопарк функциональности со своими корнер-кейсами, просто чужими. для задачи "принять письмо на известный адрес и переслать его конкретному юзеру" это избыточно.
про то что человек всё равно бутылочное горлышко, тут отчасти согласен, это уже вопрос приоритетов а не архитектуры. но даже если финальный ответ фрилансера займёт минуты, скорость самого уведомления имеет смысл сама по себе, кто увидел заказ на минуту раньше конкурента, у того выше шанс успеть откликнуться первым.
Я имел в виду схему почти как у вас сейчас, только почтовую часть принимает готовый MTA (поставленный из пакетов "промышленный" MTA, который отлаживался десятки лет - там точно с очередями и корнер-кейсами сильно разобрались) на вашем же сервере. Данные так же лежат на диске вашего сервера, т.е. утечки нет.
MTA принимает письмо на ваш ящик на вашем домене (и вашем сервере), проверяет адресата, надёжно сохраняет сообщение и лишь после этого отвечает отправителю 250 OK. Затем локальный обработчик получает письмо через pipe, LMTP или IMAP (поддержку IDLE можно приделать для красоты схемы, но никто не мешает опрашивать imap раз в секунду и так, он же ваш, никому вы этим лишнюю нагрузку не создадите) и отправляет уведомление в Telegram. Никаких чужих почтовых аккаунтов, паролей и соединений на каждого пользователя здесь нет. Ну, кроме того, что сообщение через Телегу шло у меня от скрипта иногда и долговато, а у вас всё про скорость.
То есть архитектура остаётся той же, но вместо написанного на коленке SMTP-сервера, пусть и собранного на плечах готовых библиотек, используется промышленное решение с очередью, ретраями, лимитами и десятилетиями исправленных корнер-кейсов. Собственная реализация почти наверняка принесёт ещё немало сюрпризов, а некоторые из них могут проявиться потерянными письмами.
Докер-сборки вроде https://mailcow.email/ тоже вполне закрывают ваши задачи, даже ничего придумывать не нужно. Просто запустили, сходили по tcp за почтой - что ещё нужно?
Пароль к вашему imap-ящику хранится у вас же на сервере в самом imap-сервере, и в скрипте опроса (это если схема с imap). И это, заметьте, пока не полетит в вашу сторону поток спама - exim с ним справится, очередь из exim и imap справится, а ваш наколенный сервер может и не быть рад.
Как я написал свой SMTP‑сервер, чтобы не пропускать сообщения заказчиков с фриланс‑бирж