[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-45ca2c31-a6b3-4682-9ac6-18a3518de573":3},{"id":4,"body":5,"uuid":6,"created_at":7,"updated_at":8,"brand":9,"header":10,"short_body":11,"image":12,"published":13,"published_at":14,"tags":15},30,"\u003Cp>Вашему приложению нужно принимать электронную почту.\u003C\u002Fp>\n\u003Cp>Возможно, вы разрабатываете службу поддержки, обрабатываете счета и документы, отслеживаете ответы клиентов или хотите создать уникальный email-адрес для каждого проекта, тикета или пользователя в своем SaaS.\u003C\u002Fp>\n\u003Cp>Традиционный подход предполагает запуск собственного почтового сервера. Необходимо открыть порт 25, настроить MX-записи, установить Postfix или Exim, обрабатывать MIME-сообщения, проверять отправителей, сохранять вложения и постоянно следить за доступностью инфраструктуры.\u003C\u002Fp>\n\u003Cp>Проблемы начинаются, когда хостинг-провайдер блокирует SMTP-трафик. Или когда команда понимает, что не хочет обслуживать публичный почтовый сервер ради одной функции продукта.\u003C\u002Fp>\n\u003Cp>Практичная альтернатива — отделить \u003Cstrong>прием почты\u003C\u002Fstrong> от \u003Cstrong>обработки данных приложением\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Сервис входящей почты принимает SMTP-соединение.\u003C\u002Fli>\n\u003Cli>Сервис разбирает и сохраняет сообщение.\u003C\u002Fli>\n\u003Cli>Ваше приложение получает письмо через подписанный HTTPS-вебхук.\u003C\u002Fli>\n\u003Cli>Код обрабатывает письмо как обычное API-событие.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Функция входящей почты Fmailer построена именно по этой модели. Вы направляете MX-запись принимающего хоста на Fmailer, создаете маршруты для адресов и получаете разобранные письма через события \u003Ccode>inbound.received\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch2>Почему заблокированные SMTP-порты создают проблему\u003C\u002Fh2>\n\u003Cp>Сначала важно разобраться, для чего используются основные SMTP-порты.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Порт\u003C\u002Fth>\n\u003Cth>Основное назначение\u003C\u002Fth>\n\u003Cth>Используется для приема почты из интернета\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>25\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Передача почты между почтовыми серверами\u003C\u002Ftd>\n\u003Ctd>Да\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>587\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Аутентифицированная отправка сообщений\u003C\u002Ftd>\n\u003Ctd>Нет\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>465\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Отправка сообщений через TLS\u003C\u002Ftd>\n\u003Ctd>Нет\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Порт 25 остается стандартным портом для передачи сообщений между почтовыми серверами.\u003C\u002Fp>\n\u003Cp>Порт 587 предназначен для аутентифицированной отправки писем почтовыми клиентами и приложениями. Порт 465 также используется для отправки сообщений, но через TLS-соединение.\u003C\u002Fp>\n\u003Cp>Поэтому нельзя просто заменить входящий порт 25 на 587 или 465 и ожидать, что сервер станет полноценным публичным MX-получателем.\u003C\u002Fp>\n\u003Cp>Ограничения зависят от конкретного облачного провайдера:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Amazon EC2 по умолчанию ограничивает исходящий трафик через порт 25.\u003C\u002Fli>\n\u003Cli>Google Cloud обычно блокирует внешние соединения через порт 25, но разрешает порты 465 и 587.\u003C\u002Fli>\n\u003Cli>Azure блокирует исходящий порт 25 для многих типов подписок и рекомендует использовать аутентифицированные relay-сервисы.\u003C\u002Fli>\n\u003Cli>DigitalOcean блокирует SMTP-порты 25, 465 и 587 на Droplet-серверах.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Чаще всего ограничения провайдеров относятся именно к исходящему SMTP-трафику. Однако самостоятельный прием почты все равно требует публично доступного SMTP-сервера, корректных правил firewall, постоянного IP-адреса, DNS-настроек, TLS, защиты от злоупотреблений и постоянного мониторинга.\u003C\u002Fp>\n\u003Cp>Для большинства SaaS-продуктов проще полностью убрать SMTP из инфраструктуры приложения, чем добиваться снятия ограничений и обслуживать собственный почтовый сервер.\u003C\u002Fp>\n\u003Ch2>Более практичная архитектура: MX на входе, HTTPS на выходе\u003C\u002Fh2>\n\u003Cp>Сервис входящей почты выступает мостом между почтовой сетью и вашим приложением.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">Почтовый сервер отправителя\n        |\n        | SMTP, порт 25\n        v\nВходящий MX-сервер Fmailer\n        |\n        | Парсинг, проверка и сохранение\n        v\nПодписанный HTTPS-вебхук\n        |\n        v\nВаше приложение\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Вашему серверу достаточно принимать обычный HTTPS-трафик.\u003C\u002Fp>\n\u003Cp>Fmailer берет на себя SMTP-часть системы и передает вашему приложению структурированное JSON-событие.\u003C\u002Fp>\n\u003Cp>В результате вашему приложению не требуется:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>открывать порт 25;\u003C\u002Fli>\n\u003Cli>устанавливать Postfix, Exim или другой MTA;\u003C\u002Fli>\n\u003Cli>самостоятельно разбирать multipart MIME-сообщения;\u003C\u002Fli>\n\u003Cli>управлять очередями SMTP;\u003C\u002Fli>\n\u003Cli>хранить оригинальные письма и вложения;\u003C\u002Fli>\n\u003Cli>отклонять неизвестные адреса на уровне SMTP;\u003C\u002Fli>\n\u003Cli>следить за репутацией IP-адреса почтового сервера;\u003C\u002Fli>\n\u003Cli>устанавливать обновления безопасности для почтового ПО.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Вместо SMTP-сессий вы работаете с обычными HTTP-запросами.\u003C\u002Fp>\n\u003Ch2>Как работает входящая почта Fmailer\u003C\u002Fh2>\n\u003Cp>Входящая почта Fmailer предназначена для программных сценариев, а не для использования в качестве обычного почтового ящика.\u003C\u002Fp>\n\u003Cp>Сервис не предоставляет доступ через IMAP или POP3. Вместо этого каждое принятое письмо разбирается и отправляется вашему приложению через вебхук \u003Ccode>inbound.received\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>Событие содержит:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>идентификатор входящего сообщения (\u003Ccode>inbound_id\u003C\u002Fcode>) и домен-получатель;\u003C\u002Fli>\n\u003Cli>сработавший маршрут и фактического получателя;\u003C\u002Fli>\n\u003Cli>SMTP-отправителя (\u003Ccode>mail_from\u003C\u002Fcode>) и разобранный заголовок \u003Ccode>From\u003C\u002Fcode>;\u003C\u002Fli>\n\u003Cli>адреса из заголовков \u003Ccode>To\u003C\u002Fcode> и \u003Ccode>Cc\u003C\u002Fcode>;\u003C\u002Fli>\n\u003Cli>тему письма;\u003C\u002Fli>\n\u003Cli>текстовую и HTML-версии сообщения;\u003C\u002Fli>\n\u003Cli>выбранные почтовые заголовки (\u003Ccode>Date\u003C\u002Fcode>, \u003Ccode>Reply-To\u003C\u002Fcode>, \u003Ccode>In-Reply-To\u003C\u002Fcode>, \u003Ccode>References\u003C\u002Fcode>, \u003Ccode>Auto-Submitted\u003C\u002Fcode>, \u003Ccode>List-Id\u003C\u002Fcode> и другие);\u003C\u002Fli>\n\u003Cli>результаты проверки DKIM;\u003C\u002Fli>\n\u003Cli>размер сообщения;\u003C\u002Fli>\n\u003Cli>список вложений с метаданными;\u003C\u002Fli>\n\u003Cli>API-ссылки для скачивания вложений и оригинального файла \u003Ccode>.eml\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Входящая почта доступна на платных тарифах: тариф домена должен включать и вебхуки, и входящую почту. На платных тарифах по умолчанию доступно до 25 маршрутов на домен.\u003C\u002Fp>\n\u003Cp>Рассмотрим процесс настройки по шагам.\u003C\u002Fp>\n\u003Ch2>Шаг 1. Выберите хост для приема почты\u003C\u002Fh2>\n\u003Cp>Начните с отдельного поддомена, например:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Для входящей почты обычно удобнее использовать поддомен, а не основной домен компании.\u003C\u002Fp>\n\u003Cp>Предположим, сотрудники уже получают почту на адреса:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">alex@example.com\nsupport@example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Изменение MX-записей для \u003Ccode>example.com\u003C\u002Fcode> может нарушить работу существующего почтового сервиса.\u003C\u002Fp>\n\u003Cp>Отдельный поддомен изолирует техническую почту приложения:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">ticket-123@inbound.example.com\nreply-456@inbound.example.com\nupload@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Принимающим хостом может быть как поддомен подтвержденного домена, так и сам домен. Если домен уже подключен именно для приема почты (например, \u003Ccode>help.example.com\u003C\u002Fcode>), второй уровень вложенности не нужен.\u003C\u002Fp>\n\u003Cp>Есть одно ограничение: если на самом домене уже опубликована чужая MX-запись, Fmailer не даст назначить его принимающим хостом и предложит поддомен — это защита от случайного перехвата уже работающей корпоративной почты.\u003C\u002Fp>\n\u003Ch2>Шаг 2. Добавьте MX-запись\u003C\u002Fh2>\n\u003Cp>Fmailer покажет точную DNS-запись, которую необходимо добавить для принимающего хоста.\u003C\u002Fp>\n\u003Cp>Пример:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">inbound.example.com.  IN  MX  10  mx.fmailer.ru.\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Эта запись сообщает другим почтовым серверам, что сообщения для адресов \u003Ccode>@inbound.example.com\u003C\u002Fcode> необходимо доставлять в Fmailer.\u003C\u002Fp>\n\u003Cp>Прием почты включается при выполнении трех условий:\u003C\u002Fp>\n\u003Col>\n\u003Cli>домен подтвержден обычной проверкой DNS-записей (в первую очередь DKIM);\u003C\u002Fli>\n\u003Cli>MX-запись принимающего хоста опубликована и подтверждена проверкой Fmailer;\u003C\u002Fli>\n\u003Cli>тариф домена включает входящую почту.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Проверка DNS выполняется автоматически; после того как запись подтверждена, прием начинается в течение нескольких минут.\u003C\u002Fp>\n\u003Cp>Для принимающего хоста рекомендуется оставить MX-запись Fmailer единственной.\u003C\u002Fp>\n\u003Cp>При этом вам не требуется направлять на Fmailer почту основного корпоративного домена.\u003C\u002Fp>\n\u003Ch2>Шаг 3. Создайте endpoint для вебхука\u003C\u002Fh2>\n\u003Cp>Создайте HTTPS-endpoint в своем приложении, например:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">POST \u002Fwebhooks\u002Ffmailer\u002Finbound\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Затем добавьте endpoint в панели Fmailer и подпишите его на событие:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">inbound.received\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>События входящей почты подключаются отдельно.\u003C\u002Fp>\n\u003Cp>Простого создания универсального webhook-endpoint недостаточно — необходимо явно выбрать событие \u003Ccode>inbound.received\u003C\u002Fcode> и указать этот endpoint в маршруте (см. следующий шаг). В отличие от событий отправки, входящее письмо не рассылается всем подписанным endpoint'ам: оно уходит ровно на тот, который назван сработавшим маршрутом.\u003C\u002Fp>\n\u003Cp>Fmailer подписывает webhook-запросы с помощью HMAC-SHA256. Перед разбором и обработкой события приложение должно проверить подпись на основе исходного тела HTTP-запроса.\u003C\u002Fp>\n\u003Cp>Каждый запрос содержит заголовки:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">X-Webhook-Event      inbound.received\nX-Webhook-Delivery   идентификатор доставки, он же event_id в теле\nX-Webhook-Timestamp  время подписи, unix-секунды\nX-Webhook-Signature  HMAC-SHA256 в hex\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Шаг 4. Настройте маршруты входящей почты\u003C\u002Fh2>\n\u003Cp>Маршруты определяют, какие email-адреса будут приниматься и на какой webhook-endpoint будут передаваться сообщения.\u003C\u002Fp>\n\u003Cp>Fmailer поддерживает три основных типа маршрутов:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Шаблон\u003C\u002Fth>\n\u003Cth>Тип\u003C\u002Fth>\n\u003Cth>Пример совпадения\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>support\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Точное совпадение\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>support@inbound.example.com\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>ticket-*\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Префикс\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>ticket-91@inbound.example.com\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>*\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Catch-all\u003C\u002Ftd>\n\u003Ctd>Любой адрес без более точного маршрута\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Правила записи шаблона:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>указывается только локальная часть адреса, без \u003Ccode>@\u003C\u002Fcode> и без имени хоста;\u003C\u002Fli>\n\u003Cli>символ \u003Ccode>*\u003C\u002Fcode> допускается один и только в конце;\u003C\u002Fli>\n\u003Cli>префиксный маршрут требует хотя бы один символ на месте звездочки: \u003Ccode>ticket-*\u003C\u002Fcode> совпадает с \u003Ccode>ticket-91\u003C\u002Fcode>, но не с \u003Ccode>ticket-\u003C\u002Fcode>;\u003C\u002Fli>\n\u003Cli>сравнение регистронезависимое;\u003C\u002Fli>\n\u003Cli>маршрут ссылается ровно на один webhook-endpoint того же домена.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Приоритет маршрутизации:\u003C\u002Fp>\n\u003Col>\n\u003Cli>точное совпадение;\u003C\u002Fli>\n\u003Cli>самый длинный подходящий префикс;\u003C\u002Fli>\n\u003Cli>catch-all маршрут.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Если письмо отправлено на адрес, который не соответствует ни одному активному маршруту, Fmailer отклоняет его в рамках той же SMTP-сессии: почта на неизвестный хост отклоняется еще на этапе \u003Ccode>RCPT TO\u003C\u002Fcode>, а известный хост без подходящего маршрута отвечает \u003Ccode>550\u003C\u002Fcode> после передачи данных. В обоих случаях отчет о недоставке формирует сервер отправителя, а сообщение в вашу систему не попадает.\u003C\u002Fp>\n\u003Cp>Сервис не принимает бесконтрольно сообщения для неопределенных адресов.\u003C\u002Fp>\n\u003Cp>Таким способом можно создавать управляемые пространства адресов:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">support@inbound.example.com\ninvoice@inbound.example.com\nticket-<ticket-id>@inbound.example.com\nproject-<project-id>@inbound.example.com\ncustomer-<customer-id>@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Шаг 5. Обработайте входящий webhook\u003C\u002Fh2>\n\u003Cp>Упрощенное событие входящей почты может выглядеть следующим образом:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-json\">{\n  "event_id": "6f1d2c30-0004-4c7a-9b21-0c8e5a3d7f44",\n  "event": "inbound.received",\n  "inbound_id": "0f0b6c1a-4a1e-4a3a-9f7a-2c9d1b5e8a10",\n  "domain": "example.com",\n  "route": "support",\n  "recipient": "support@inbound.example.com",\n  "mail_from": "alex@customer.example",\n  "from": {\n    "email": "alex@customer.example",\n    "name": "Alex"\n  },\n  "to": ["support@inbound.example.com"],\n  "cc": [],\n  "subject": "Проблема с импортом данных",\n  "text": "Импорт останавливается на 72%.",\n  "html": "<p>Импорт останавливается на 72%.<\u002Fp>",\n  "headers": {\n    "Date": "Tue, 12 Aug 2025 10:04:11 +0300",\n    "Reply-To": "alex@customer.example"\n  },\n  "message_id": "<a1b2c3@customer.example>",\n  "auth": {\n    "dkim": "pass",\n    "dkim_aligned": true\n  },\n  "size": 18422,\n  "raw_url": "https:\u002F\u002Fapi.fmailer.ru\u002Fapi\u002Finbound\u002Fmessages\u002F0f0b6c1a-...\u002Fraw\u002F",\n  "attachments": [],\n  "timestamp": "2025-08-12T07:04:12.481Z"\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Поля \u003Ccode>raw_url\u003C\u002Fcode> и \u003Ccode>attachments[].url\u003C\u002Fcode> — это постоянные API-адреса Fmailer, а не временные подписанные ссылки. Так сделано намеренно: тело события сохраняется и повторяется при ретраях в течение суток, а подписанная ссылка на хранилище живет минуты. Запрос к API выполняется с авторизацией вашего аккаунта и уже он возвращает редирект на короткоживущую ссылку для скачивания.\u003C\u002Fp>\n\u003Ch3>Пример webhook-endpoint на Node.js\u003C\u002Fh3>\n\u003Cp>Следующий endpoint на Express проверяет подпись Fmailer и принимает события входящей почты:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-javascript\">const crypto = require("crypto");\nconst express = require("express");\n\nconst app = express();\n\nconst webhookSecret = process.env.FMAILER_WEBHOOK_SECRET;\nconst replayToleranceSeconds = 300;\n\napp.post(\n  "\u002Fwebhooks\u002Ffmailer\u002Finbound",\n  express.raw({ type: "application\u002Fjson" }),\n  async (req, res) => {\n    const signature = req.get("X-Webhook-Signature");\n    const timestamp = req.get("X-Webhook-Timestamp");\n\n    if (\n      !signature ||\n      !timestamp ||\n      !\u002F^[a-f0-9]{64}$\u002Fi.test(signature)\n    ) {\n      return res.sendStatus(400);\n    }\n\n    const timestampNumber = Number(timestamp);\n\n    if (\n      !Number.isFinite(timestampNumber) ||\n      Math.abs(Date.now() \u002F 1000 - timestampNumber) >\n        replayToleranceSeconds\n    ) {\n      return res.sendStatus(400);\n    }\n\n    \u002F\u002F Подпись рассчитывается для строки:\n    \u002F\u002F <timestamp>.<точное исходное тело запроса>\n    const signedPayload = Buffer.concat([\n      Buffer.from(`${timestamp}.`, "utf8"),\n      req.body\n    ]);\n\n    const expectedSignature = crypto\n      .createHmac("sha256", webhookSecret)\n      .update(signedPayload)\n      .digest();\n\n    const providedSignature = Buffer.from(signature, "hex");\n\n    if (\n      providedSignature.length !== expectedSignature.length ||\n      !crypto.timingSafeEqual(\n        providedSignature,\n        expectedSignature\n      )\n    ) {\n      return res.sendStatus(400);\n    }\n\n    let event;\n\n    try {\n      event = JSON.parse(req.body.toString("utf8"));\n    } catch {\n      return res.sendStatus(400);\n    }\n\n    if (event.event !== "inbound.received") {\n      return res.sendStatus(204);\n    }\n\n    \u002F\u002F Добавляем событие в очередь с защитой от дубликатов.\n    \u002F\u002F event.event_id не изменяется при повторной доставке.\n    await enqueueInboundEmail({\n      idempotencyKey: event.event_id,\n      route: event.route,\n      recipient: event.recipient,\n      sender: event.from?.email,\n      subject: event.subject,\n      text: event.text,\n      html: event.html,\n      attachments: event.attachments,\n      senderAuthenticated:\n        event.auth?.dkim === "pass" &&\n        event.auth?.dkim_aligned === true\n    });\n\n    return res.sendStatus(202);\n  }\n);\n\napp.listen(3000);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Подпись необходимо рассчитывать на основе точных исходных байтов HTTP-запроса.\u003C\u002Fp>\n\u003Cp>Если сначала преобразовать body в объект, а затем снова сериализовать его в JSON, пробелы или форматирование могут измениться. В таком случае проверка подписи завершится ошибкой.\u003C\u002Fp>\n\u003Cp>После успешного приема Fmailer ожидает HTTP-ответ со статусом \u003Ccode>2xx\u003C\u002Fcode>. На ответ отводится 10 секунд.\u003C\u002Fp>\n\u003Cp>Поэтому webhook-handler должен быстро:\u003C\u002Fp>\n\u003Col>\n\u003Cli>проверить подпись;\u003C\u002Fli>\n\u003Cli>проверить тип события;\u003C\u002Fli>\n\u003Cli>добавить задачу в очередь;\u003C\u002Fli>\n\u003Cli>вернуть успешный ответ.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Не стоит выполнять скачивание вложений, AI-анализ или длительную обработку до отправки HTTP-ответа.\u003C\u002Fp>\n\u003Cp>При неуспешной доставке Fmailer повторяет webhook-запрос по возрастающему графику: через 1 минуту, 5 минут, 30 минут, 2 часа, 6 часов и 24 часа. Если все попытки исчерпаны, доставка помечается как неуспешная, а само письмо остается доступным через API и панель.\u003C\u002Fp>\n\u003Ch2>Ограничения приема\u003C\u002Fh2>\n\u003Cp>Технические лимиты по умолчанию:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Параметр\u003C\u002Fth>\n\u003Cth>Значение\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Максимальный размер сообщения\u003C\u002Ftd>\n\u003Ctd>30 МБ\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Вложений в сообщении\u003C\u002Ftd>\n\u003Ctd>до 25\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Размер одного вложения\u003C\u002Ftd>\n\u003Ctd>до 25 МБ\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Сохраняемый объем text и html\u003C\u002Ftd>\n\u003Ctd>до 500 000 символов\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Поток на домен\u003C\u002Ftd>\n\u003Ctd>500 сообщений в час\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Сообщение сверх допустимого размера отклоняется на уровне SMTP. При превышении почасового лимита Fmailer отвечает временной ошибкой \u003Ccode>450\u003C\u002Fcode>, и отправляющий сервер повторит доставку позже.\u003C\u002Fp>\n\u003Cp>Принятые письма и вложения хранятся столько, сколько предусматривает срок хранения логов вашего тарифа, после чего удаляются вместе с файлами.\u003C\u002Fp>\n\u003Ch2>Какие продукты можно построить с помощью входящей почты\u003C\u002Fh2>\n\u003Cp>Получение писем в виде структурированных данных открывает значительно больше возможностей, чем обычная контактная форма.\u003C\u002Fp>\n\u003Ch2>1. Система поддержки email-to-ticket\u003C\u002Fh2>\n\u003Cp>Создайте точный маршрут:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">support@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Когда клиент отправляет письмо:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Fmailer принимает и разбирает сообщение.\u003C\u002Fli>\n\u003Cli>Ваш webhook получает данные письма.\u003C\u002Fli>\n\u003Cli>Приложение находит клиента по адресу отправителя.\u003C\u002Fli>\n\u003Cli>Создается новый тикет.\u003C\u002Fli>\n\u003Cli>Вложения прикрепляются к обращению.\u003C\u002Fli>\n\u003Cli>Клиенту отправляется автоматическое подтверждение.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Пользователь получает привычный канал связи, а вся работа с обращением остается внутри вашего SaaS.\u003C\u002Fp>\n\u003Ch2>2. Уникальные адреса для ответов на тикеты\u003C\u002Fh2>\n\u003Cp>Назначьте каждому тикету собственный адрес:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">ticket-8942@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Создайте префиксный маршрут:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">ticket-*\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Webhook может извлечь идентификатор \u003Ccode>8942\u003C\u002Fcode> из адреса получателя и добавить письмо к соответствующему тикету.\u003C\u002Fp>\n\u003Cp>Такой подход надежнее, чем связывание сообщений по теме письма.\u003C\u002Fp>\n\u003Cp>Идентификатор объекта находится непосредственно в адресе доставки.\u003C\u002Fp>\n\u003Cp>Та же схема подходит для адресов:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">thread-<id>@inbound.example.com\nconversation-<id>@inbound.example.com\ncase-<id>@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>3. Ответы на уведомления по email\u003C\u002Fh2>\n\u003Cp>Предположим, ваша система управления проектами отправляет уведомление:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">Мария упомянула вас в проекте Apollo.\nОтветьте на это письмо, чтобы добавить комментарий.\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Укажите в качестве адреса для ответа:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">project-41-thread-987@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Когда пользователь отвечает, webhook определяет проект и обсуждение по адресу получателя.\u003C\u002Fp>\n\u003Cp>Текст письма преобразуется в новый комментарий.\u003C\u002Fp>\n\u003Cp>Перед сохранением приложение может:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>удалить процитированную историю переписки;\u003C\u002Fli>\n\u003Cli>убрать подпись отправителя;\u003C\u002Fli>\n\u003Cli>проверить, состоит ли отправитель в проекте;\u003C\u002Fli>\n\u003Cli>определить автоматический ответ;\u003C\u002Fli>\n\u003Cli>сохранить прикрепленные файлы;\u003C\u002Fli>\n\u003Cli>сохранить оригинальный \u003Ccode>.eml\u003C\u002Fcode> для аудита.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>4. Прием счетов и документов\u003C\u002Fh2>\n\u003Cp>Создайте адрес:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">invoices@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Клиенты или поставщики смогут отправлять счета непосредственно в вашу систему.\u003C\u002Fp>\n\u003Cp>Приложение может:\u003C\u002Fp>\n\u003Col>\n\u003Cli>проверить наличие вложения;\u003C\u002Fli>\n\u003Cli>скачать файл через API Fmailer;\u003C\u002Fli>\n\u003Cli>проверить файл на вредоносное содержимое;\u003C\u002Fli>\n\u003Cli>распознать реквизиты счета;\u003C\u002Fli>\n\u003Cli>сопоставить отправителя с поставщиком;\u003C\u002Fli>\n\u003Cli>создать процесс согласования;\u003C\u002Fli>\n\u003Cli>сохранить оригинальное письмо для аудита.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Входящее событие Fmailer содержит информацию о каждом вложении:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>идентификатор;\u003C\u002Fli>\n\u003Cli>имя файла;\u003C\u002Fli>\n\u003Cli>MIME-тип;\u003C\u002Fli>\n\u003Cli>размер;\u003C\u002Fli>\n\u003Cli>признак inline-вложения;\u003C\u002Fli>\n\u003Cli>Content ID;\u003C\u002Fli>\n\u003Cli>API-адрес для скачивания.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>5. Уникальные адреса для каждого клиента\u003C\u002Fh2>\n\u003Cp>Создавайте персональный адрес для каждого tenant или клиента:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">customer-a83f9@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Такой адрес может стать простым интерфейсом интеграции.\u003C\u002Fp>\n\u003Cp>Вместо полноценной API-интеграции клиент пересылает на него:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>отчеты;\u003C\u002Fli>\n\u003Cli>уведомления;\u003C\u002Fli>\n\u003Cli>чеки;\u003C\u002Fli>\n\u003Cli>документы;\u003C\u002Fli>\n\u003Cli>экспортированные данные;\u003C\u002Fli>\n\u003Cli>системные сообщения.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Ваше приложение определяет владельца сообщения по идентификатору в адресе получателя.\u003C\u002Fp>\n\u003Cp>Сценарий подходит для:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>сервисов управления расходами;\u003C\u002Fli>\n\u003Cli>бухгалтерских платформ;\u003C\u002Fli>\n\u003Cli>compliance-систем;\u003C\u002Fli>\n\u003Cli>логистических приложений;\u003C\u002Fli>\n\u003Cli>сервисов управления недвижимостью;\u003C\u002Fli>\n\u003Cli>рекрутинговых платформ;\u003C\u002Fli>\n\u003Cli>систем обработки документов.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Если идентификаторы клиентов или объектов используются в публичных адресах, лучше применять непрозрачные и непоследовательные значения.\u003C\u002Fp>\n\u003Ch2>6. Сбор лидов в CRM\u003C\u002Fh2>\n\u003Cp>Назначьте отдельный адрес каждому партнеру, кампании или менеджеру:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">partner-acme@inbound.example.com\ncampaign-berlin@inbound.example.com\nrep-42@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Входящие письма могут автоматически создавать лиды и связывать их с нужным источником привлечения.\u003C\u002Fp>\n\u003Cp>Catch-all маршрут позволяет использовать динамические адреса, а точные маршруты — резервировать важные системные имена.\u003C\u002Fp>\n\u003Ch2>7. Обработка автоматических отчетов\u003C\u002Fh2>\n\u003Cp>Многие устаревшие системы умеют отправлять email, но не поддерживают REST API.\u003C\u002Fp>\n\u003Cp>Вместо разработки отдельной интеграции можно выдать такой системе специальный адрес:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">reports-warehouse-7@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Legacy-система отправляет периодический отчет по почте.\u003C\u002Fp>\n\u003Cp>Ваш webhook:\u003C\u002Fp>\n\u003Col>\n\u003Cli>получает сообщение;\u003C\u002Fli>\n\u003Cli>скачивает вложение;\u003C\u002Fli>\n\u003Cli>проверяет его формат;\u003C\u002Fli>\n\u003Cli>импортирует данные;\u003C\u002Fli>\n\u003Cli>сообщает о результате обработки.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>В этом случае email становится адаптером между устаревшей системой и современным приложением.\u003C\u002Fp>\n\u003Ch2>8. AI-обработка входящей почты\u003C\u002Fh2>\n\u003Cp>Поскольку сообщения поступают в виде структурированного JSON, выбранные поля можно передавать в систему классификации, извлечения данных или генерации ответов.\u003C\u002Fp>\n\u003Cp>Примеры:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>классификация обращений в поддержку;\u003C\u002Fli>\n\u003Cli>извлечение номера заказа;\u003C\u002Fli>\n\u003Cli>определение намерения клиента;\u003C\u002Fli>\n\u003Cli>создание краткого резюме длинной переписки;\u003C\u002Fli>\n\u003Cli>маршрутизация сообщения в нужный отдел;\u003C\u002Fli>\n\u003Cli>генерация черновика ответа;\u003C\u002Fli>\n\u003Cli>поиск отсутствующих данных в счете;\u003C\u002Fli>\n\u003Cli>извлечение дат, сумм и реквизитов;\u003C\u002Fli>\n\u003Cli>определение срочности обращения.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Сначала сохраните событие или поставьте его в очередь, а ресурсоемкую обработку выполняйте отдельным worker-процессом.\u003C\u002Fp>\n\u003Cp>Содержимое email и вложений необходимо считать недоверенными данными. Они могут содержать:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>вредоносные файлы;\u003C\u002Fli>\n\u003Cli>скрытый HTML;\u003C\u002Fli>\n\u003Cli>tracking-элементы;\u003C\u002Fli>\n\u003Cli>попытки prompt injection;\u003C\u002Fli>\n\u003Cli>вводящие в заблуждение инструкции;\u003C\u002Fli>\n\u003Cli>поддельные данные отправителя.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Безопасность и надежность\u003C\u002Fh2>\n\u003Cp>Перенос SMTP-инфраструктуры во внешний сервис уменьшает операционную нагрузку, но приложение все равно должно безопасно обрабатывать вебхуки.\u003C\u002Fp>\n\u003Ch2>Проверяйте подпись каждого webhook-запроса\u003C\u002Fh2>\n\u003Cp>Не доверяйте запросу только потому, что он поступил на нестандартный URL.\u003C\u002Fp>\n\u003Cp>Проверяйте:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ccode>X-Webhook-Signature\u003C\u002Fcode>;\u003C\u002Fli>\n\u003Cli>\u003Ccode>X-Webhook-Timestamp\u003C\u002Fcode>;\u003C\u002Fli>\n\u003Cli>точное исходное тело запроса;\u003C\u002Fli>\n\u003Cli>допустимое окно времени для защиты от повторного воспроизведения.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Для сравнения ожидаемой и полученной подписи используйте constant-time функцию.\u003C\u002Fp>\n\u003Ch2>Удаляйте дубликаты по \u003Ccode>event_id\u003C\u002Fcode>\u003C\u002Fh2>\n\u003Cp>Доставка входящих событий работает по модели at least once.\u003C\u002Fp>\n\u003Cp>Если endpoint не ответил вовремя или вернул ошибку, одно и то же событие может быть доставлено повторно.\u003C\u002Fp>\n\u003Cp>Используйте \u003Ccode>event_id\u003C\u002Fcode> в качестве ключа идемпотентности: при повторных попытках он не меняется.\u003C\u002Fp>\n\u003Cp>Так повторная доставка не создаст:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>два тикета;\u003C\u002Fli>\n\u003Cli>два комментария;\u003C\u002Fli>\n\u003Cli>два счета;\u003C\u002Fli>\n\u003Cli>два лида;\u003C\u002Fli>\n\u003Cli>две задачи обработки.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Не доверяйте полю From автоматически\u003C\u002Fh2>\n\u003Cp>Видимый заголовок \u003Ccode>From\u003C\u002Fcode> можно подделать.\u003C\u002Fp>\n\u003Cp>Fmailer сообщает:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>результат проверки DKIM;\u003C\u002Fli>\n\u003Cli>соответствует ли домен DKIM-подписи видимому домену отправителя.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Поле \u003Ccode>auth.dkim\u003C\u002Fcode> принимает пять значений:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Значение\u003C\u002Fth>\n\u003Cth>Что означает\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>pass\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>подпись проверена\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>fail\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>подпись не прошла проверку\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>none\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>подписи нет — обычное состояние для многих отправителей\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>temperror\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>DNS не ответил, проверить не удалось\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>permerror\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>подпись или ключ некорректны\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Значения \u003Ccode>temperror\u003C\u002Fcode> и \u003Ccode>permerror\u003C\u002Fcode> намеренно отделены от \u003Ccode>fail\u003C\u002Fcode>: «письмо подделано» и «мы не смогли проверить» — разные факты, и правило вида «дропаем все, кроме \u003Ccode>pass\u003C\u002Fcode>» должно это учитывать.\u003C\u002Fp>\n\u003Cp>Полей \u003Ccode>spf\u003C\u002Fcode> и \u003Ccode>dmarc\u003C\u002Fcode> в событии нет, и это осознанное решение: SPF в этом контуре не вычисляется, а DMARC-вердикт по одной только DKIM-подписи давал бы ложные отказы для писем, прошедших по SPF.\u003C\u002Fp>\n\u003Cp>Для сценариев, где требуется более высокий уровень доверия, отправителя можно считать технически аутентифицированным только при выполнении условий:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-javascript\">event.auth.dkim === "pass" &&\nevent.auth.dkim_aligned === true\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Однако аутентификация не заменяет авторизацию.\u003C\u002Fp>\n\u003Cp>Даже корректно подтвержденный отправитель не должен автоматически получать доступ ко всем проектам, тикетам или аккаунтам.\u003C\u002Fp>\n\u003Cp>Приложение должно отдельно проверить, имеет ли пользователь право выполнять конкретное действие.\u003C\u002Fp>\n\u003Ch2>Используйте фактически принятый адрес получателя\u003C\u002Fh2>\n\u003Cp>Для определения маршрута и объекта используйте поля \u003Ccode>recipient\u003C\u002Fcode> и \u003Ccode>route\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>Не следует считать все адреса из видимых заголовков \u003Ccode>To\u003C\u002Fcode> и \u003Ccode>Cc\u003C\u002Fcode> фактически принятыми системой.\u003C\u002Fp>\n\u003Cp>В заголовках могут находиться:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>дополнительные получатели;\u003C\u002Fli>\n\u003Cli>адреса других систем;\u003C\u002Fli>\n\u003Cli>группы рассылки;\u003C\u002Fli>\n\u003Cli>поддельные или нерелевантные значения.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Авторизацию и маршрутизацию необходимо строить на основе адреса, который действительно принял Fmailer.\u003C\u002Fp>\n\u003Ch2>Проверяйте вложения\u003C\u002Fh2>\n\u003Cp>Перед обработкой вложения:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>установите собственное ограничение размера;\u003C\u002Fli>\n\u003Cli>разрешайте только необходимые форматы;\u003C\u002Fli>\n\u003Cli>проверяйте сигнатуру файла, а не только MIME-тип;\u003C\u002Fli>\n\u003Cli>сканируйте файлы на вредоносное содержимое;\u003C\u002Fli>\n\u003Cli>генерируйте новые имена файлов при сохранении;\u003C\u002Fli>\n\u003Cli>не храните файлы в публичной директории;\u003C\u002Fli>\n\u003Cli>не отображайте недоверенный HTML без очистки;\u003C\u002Fli>\n\u003Cli>не запускайте макросы и исполняемые файлы.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Ограничения приложения могут быть строже ограничений почтового сервиса.\u003C\u002Fp>\n\u003Ch2>Защищайтесь от email-циклов\u003C\u002Fh2>\n\u003Cp>Осторожно настраивайте автоматические ответы.\u003C\u002Fp>\n\u003Cp>Не создавайте autoresponder, который отправляет сообщения обратно на тот же входящий маршрут.\u003C\u002Fp>\n\u003Cp>Со своей стороны Fmailer ограничивает цикл по числу транзитных заголовков \u003Ccode>Received\u003C\u002Fcode> и по почасовому лимиту домена, но это защита от разрастания, а не замена корректной логики автоответов.\u003C\u002Fp>\n\u003Cp>Для обнаружения автоматических сообщений, bounce-писем и рассылок можно анализировать заголовки, которые передаются в событии:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">Auto-Submitted\nIn-Reply-To\nList-Id\nPrecedence\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Автоответы и списочная почта не отбрасываются сервисом: это ваша почта, и решение принимает ваше приложение.\u003C\u002Fp>\n\u003Ch2>Входящая почта — не обычный почтовый ящик\u003C\u002Fh2>\n\u003Cp>Функция inbound email в Fmailer предназначена для передачи почты программному коду.\u003C\u002Fp>\n\u003Cp>Она не заменяет Gmail, Outlook или общий почтовый ящик отдела поддержки.\u003C\u002Fp>\n\u003Cp>Пользователи не входят в Fmailer, чтобы читать письма через IMAP или POP3.\u003C\u002Fp>\n\u003Cp>Пользовательский интерфейс создает ваше приложение.\u003C\u002Fp>\n\u003Cp>Например:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>helpdesk показывает сообщение в ленте тикета;\u003C\u002Fli>\n\u003Cli>CRM добавляет письмо в историю контакта;\u003C\u002Fli>\n\u003Cli>бухгалтерский сервис отображает письмо рядом со счетом;\u003C\u002Fli>\n\u003Cli>проектная система преобразует письмо в комментарий;\u003C\u002Fli>\n\u003Cli>платформа обработки документов показывает полученный файл в очереди импорта.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Ответные письма можно отправлять отдельно через API, SMTP relay или SDK Fmailer.\u003C\u002Fp>\n\u003Ch2>Почему сервис входящей почты удобнее собственного SMTP-сервера\u003C\u002Fh2>\n\u003Cp>Собственный SMTP-сервер дает полный контроль, но вместе с ним — полную ответственность.\u003C\u002Fp>\n\u003Cp>Необходимо самостоятельно обслуживать:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>доступность SMTP-listener;\u003C\u002Fli>\n\u003Cli>MX-записи;\u003C\u002Fli>\n\u003Cli>reverse DNS;\u003C\u002Fli>\n\u003Cli>TLS-сертификаты;\u003C\u002Fli>\n\u003Cli>настройки протоколов;\u003C\u002Fli>\n\u003Cli>MIME-парсинг;\u003C\u002Fli>\n\u003Cli>большие сообщения;\u003C\u002Fli>\n\u003Cli>проверку адресов;\u003C\u002Fli>\n\u003Cli>очереди доставки;\u003C\u002Fli>\n\u003Cli>временные ошибки;\u003C\u002Fli>\n\u003Cli>повторные попытки;\u003C\u002Fli>\n\u003Cli>защиту от спама и злоупотреблений;\u003C\u002Fli>\n\u003Cli>хранение исходных сообщений;\u003C\u002Fli>\n\u003Cli>хранение вложений;\u003C\u002Fli>\n\u003Cli>обновления безопасности;\u003C\u002Fli>\n\u003Cli>мониторинг;\u003C\u002Fli>\n\u003Cli>реагирование на инциденты.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Для компании, которая специализируется на email-инфраструктуре, такие затраты могут быть оправданы.\u003C\u002Fp>\n\u003Cp>Но если задача SaaS-команды заключается в том, чтобы превратить письмо в тикет, комментарий, счет, лид или загруженный документ, самостоятельная SMTP-инфраструктура обычно становится ненужной сложностью.\u003C\u002Fp>\n\u003Cp>Fmailer оставляет SMTP на внешнем контуре и предоставляет вашему приложению привычный интерфейс: подписанный JSON-вебхук через HTTPS.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Можно ли принимать email, не открывая порт 25?\u003C\u002Fh3>\n\u003Cp>Да.\u003C\u002Fp>\n\u003Cp>Если входящий сервис принимает почту от вашего имени, приложению не требуется открывать порт 25.\u003C\u002Fp>\n\u003Cp>Вы направляете MX-запись принимающего хоста на провайдера, а сообщения получаете через HTTPS-вебхуки.\u003C\u002Fp>\n\u003Cp>SMTP-соединение существует только между сервером отправителя и сервисом входящей почты. До сервера вашего приложения оно не доходит.\u003C\u002Fp>\n\u003Ch3>Можно ли использовать порт 587 вместо порта 25 для входящей почты?\u003C\u002Fh3>\n\u003Cp>Нет, не для стандартной передачи сообщений между почтовыми серверами.\u003C\u002Fp>\n\u003Cp>Порт 587 предназначен для аутентифицированной отправки сообщений клиентами и приложениями.\u003C\u002Fp>\n\u003Cp>Передача почты между MX-серверами выполняется через порт 25.\u003C\u002Fp>\n\u003Ch3>Можно ли использовать порт 465?\u003C\u002Fh3>\n\u003Cp>Порт 465 используется для отправки сообщений через TLS.\u003C\u002Fp>\n\u003Cp>Он не является универсальной заменой порта 25 для публичного MX-сервера.\u003C\u002Fp>\n\u003Ch3>Нужно ли устанавливать Postfix или Exim?\u003C\u002Fh3>\n\u003Cp>Нет.\u003C\u002Fp>\n\u003Cp>Fmailer самостоятельно принимает SMTP-сообщение и разбирает его содержимое.\u003C\u002Fp>\n\u003Cp>Ваше приложение получает HTTPS-запрос со структурированными данными письма.\u003C\u002Fp>\n\u003Ch3>Поддерживаются ли вложения?\u003C\u002Fh3>\n\u003Cp>Да.\u003C\u002Fp>\n\u003Cp>Событие входящей почты содержит метаданные вложений и API-адреса для их скачивания: имя файла, MIME-тип, размер, признак inline и Content ID.\u003C\u002Fp>\n\u003Cp>Также можно получить оригинальный файл сообщения в формате \u003Ccode>.eml\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>Ограничения по умолчанию: до 25 вложений, до 25 МБ каждое, размер всего сообщения до 30 МБ.\u003C\u002Fp>\n\u003Ch3>Можно ли создавать динамические email-адреса?\u003C\u002Fh3>\n\u003Cp>Да.\u003C\u002Fp>\n\u003Cp>Например, префиксный маршрут \u003Ccode>ticket-*\u003C\u002Fcode> может принимать адреса:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">ticket-123@inbound.example.com\nticket-456@inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Catch-all маршрут \u003Ccode>*\u003C\u002Fcode> позволяет принимать любой адрес, который не совпал с более точным правилом.\u003C\u002Fp>\n\u003Ch3>Что произойдет, если webhook временно недоступен?\u003C\u002Fh3>\n\u003Cp>Fmailer повторит доставку через 1 минуту, 5 минут, 30 минут, 2 часа, 6 часов и 24 часа.\u003C\u002Fp>\n\u003Cp>Поскольку одно событие может быть доставлено несколько раз, приложение должно удалять дубликаты по \u003Ccode>event_id\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>Само письмо при этом сохранено и остается доступным через API и панель.\u003C\u002Fp>\n\u003Ch3>Можно ли принимать почту на основном домене компании?\u003C\u002Fh3>\n\u003Cp>Технически да: принимающим хостом может быть и сам домен. Но если на нем уже работает корпоративная почта, менять MX-записи не нужно и не следует — Fmailer откажет в такой настройке, обнаружив чужую MX-запись на домене.\u003C\u002Fp>\n\u003Cp>Практичный вариант — отдельный поддомен:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">inbound.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Это позволяет не трогать MX-записи, которые уже обслуживают корпоративные адреса на \u003Ccode>example.com\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3>На каких тарифах доступна входящая почта?\u003C\u002Fh3>\n\u003Cp>Входящая почта включена в платные тарифы: тариф должен поддерживать и вебхуки, и входящие маршруты. На бесплатном тарифе функция недоступна.\u003C\u002Fp>\n\u003Ch2>Принимайте email без собственной SMTP-инфраструктуры\u003C\u002Fh2>\n\u003Cp>Заблокированные SMTP-порты не должны останавливать разработку продукта.\u003C\u002Fp>\n\u003Cp>Вместо открытия порта 25 и обслуживания собственного почтового сервера передайте прием входящих сообщений Fmailer.\u003C\u002Fp>\n\u003Cp>Ваше приложение будет получать каждое письмо в виде разобранного и подписанного HTTPS-вебхука, который можно обрабатывать через существующую API-инфраструктуру.\u003C\u002Fp>\n\u003Cp>Архитектура остается простой:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-text\">Настроить MX\n    → создать маршрут\n    → подключить webhook\n    → обработать входящее письмо\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Используйте входящую почту, чтобы:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>создавать тикеты службы поддержки;\u003C\u002Fli>\n\u003Cli>принимать ответы на уведомления;\u003C\u002Fli>\n\u003Cli>загружать счета и документы;\u003C\u002Fli>\n\u003Cli>собирать лиды;\u003C\u002Fli>\n\u003Cli>импортировать автоматические отчеты;\u003C\u002Fli>\n\u003Cli>добавлять комментарии по email;\u003C\u002Fli>\n\u003Cli>выдавать уникальный адрес каждому клиенту;\u003C\u002Fli>\n\u003Cli>создавать адреса для отдельных проектов, тикетов и объектов.\u003C\u002Fli>\n\u003C\u002Ful>","45ca2c31-a6b3-4682-9ac6-18a3518de573","2026-08-07T11:19:55.076495+03:00","2026-08-07T11:29:40.310919+03:00","fmailer","Как принимать входящие письма, если SMTP-порты заблокированы","Чтобы принимать email в приложении, необязательно открывать SMTP-порты и самостоятельно обслуживать почтовый сервер. Сервис входящей почты может принять письмо, разобрать его содержимое и передать данные вашему приложению через подписанный HTTPS-вебхук.","https:\u002F\u002Fapi.fmailer.ru\u002Fmedia\u002Fblog\u002Frecord_45ca2c31-a6b3-4682-9ac6-18a3518de573\u002FChatGPT_Image_Aug_7_2026_11_16_06_AM.png",true,"2026-08-07T11:19:26+03:00",[16,17],"приём писем","smtp"]