Каким образом могло произойти раскрытие моего адреса электронной почты?

На сервере с postfix и dovecot, который настроен и работает, несколько лет назад был создан служебный ящик cws-c.ms.sql.server@domain.name для оповещений MS SQL, но мониторинг так и не запустили и ящик не использовался. Недавно в нём обнаружил три письма за последний месяц — все спам. Адрес нигде не публиковался и не выходил за пределы двух серверов, его не подберёшь перебором. Как спамеры могли узнать этот адрес и какие меры защиты от этого принять?
  • 18 февраля 2026 г. 20:01
Ответы на вопрос 2
Коротко — причин немного, но самая вероятная: адрес каким‑то образом попал в “поле зрения” автоматов‑сборщиков (harvesters) или в чужую базу (утечка конфигов/бекапов, сторонний сервис, перебор по шаблонам), и спамеры начали посылать массовые рассылки по наборам локальных частей. Ниже — подробности возможных путей утечки и практические меры защиты.

Возможные пути, как адрес узнали

- Directory harvesting / перебор. Боты массово посылают письма по обычным и автоматически сгенерированным локальным частям (admin, postmaster, hostname‑based, имя_сервиса@...). Если сервер или домен «принимает» много адресов (особенно при включённом catch‑all), то при угадывании одного — письмо доходит. Даже редкие нестандартные имена иногда угадывают, если бот перебирает много комбинаций.

- Утечка конфигураций/бекапов/репозиториев. Конфиг postfix/dovecot, скрипты, лог‑файлы, дампы баз или бэкапы могли попасть в публичный репозиторий, общедоступный облачный бакет (S3, Drive) или были отправлены кому‑то. Тогда адрес «всплыл» в чужой базе.

- Утечка/продажа списков и breaches. Ваш адрес мог попасть в какую‑то чужую базу (например, скомпрометированное ПО, служебные уведомления, тесты) и затем быть продан/распространён.

- От внешних сервисов/администраторов. Кто‑то мог использовать этот адрес при настройке мониторинга, облачного сервиса, тестировании и т.п., и там он оказался в списках рассылки.

- Открытые SMTP‑функции (VRFY/EXPN) или неправильно настроенный виртуальный домен. Если сервер давал возможность проверить существование почтового ящика или был настроен как catch‑all, спамеры могли это узнать через простые SMTP‑пробы.

- Бесконтрольные перенаправления/алиасы. Возможно, адрес где‑то указан как алиас или в map’ах виртуальных почтовых ящиков, и сторонний механизм его «выловил».

Что делать прямо сейчас (пошагово)

1) Проанализируйте логи, чтобы понять источник
- Поиск по адресу:
  zgrep -i "cws-c.ms.sql.server@domain.name" /var/log/mail* 
  или
  grep -F "cws-c.ms.sql.server@domain.name" /var/log/mail.log
- Посмотрите поля Received в заголовках писем — откуда пришло, через какие хосты.
- Определите IP отправителей, HELO/EHLO, PTR, ASN — WHOIS/rdns помогут понять, это бот/маршрутизатор/мэйл‑хост.

2) Если адрес не нужен — удалите или деактивируйте
- Удалите ящик и/или отключите алиасы на postfix/dovecot.
- Альтернатива: сделать для этого адреса схему reject с коротким SMTP‑ответом (550) — тогда боты увидят, что адрес не принимается.

3) Не держать catch‑all
- Если у вас включён catch‑all (приём всех локальных частей), отключите его: принимать только те адреса, которые явно объявлены в virtual_mailbox_maps/aliases.

4) Отвергать неизвестных получателей
- В Postfix включите reject_unlisted_recipient в smtpd_recipient_restrictions (или соответствующую настройку для виртуальных почтовых доменов), чтобы сервер сразу возвращал 5xx на несуществующие адреса.
- Пример:
  smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_unlisted_recipient,
    ... (и ваши антиспам проверки)

5) Применить антиспам фильтры
- Используйте rspamd или spamassassin, greylisting (postgrey), RBL/DNSBL (spamhaus, etc.), фильтрацию по DKIM/SPF/DMARC для домена.
- Настройте Sieve (Dovecot) — автоматически класть в спам или удалять сообщения на неиспользуемые ящики.

6) Блокируйте или лимитируйте злых отправителей
- На уровне firewall или Postfix заблокируйте плотные источники спама (если видно повторяющиеся IP).
- Добавьте rate‑limits, TXT‑проверки, проверку HELO/RDNS.

7) Проверьте на утечки и публичность
- Проверьте наличие адреса в публичных репозиториях:
  - grep в репозиториях/бекапах,
  - поиски по GitHub/GitLab,
  - проверьте доступность S3/Drive и других хранилищ.
- Проверьте «haveibeenpwned» и т.п. — мог появиться в утечках.

8) Логика для служебных адресов
- Для служебных оповещений лучше:
  - использовать уникальные адреса и/или «плюс‑адресацию» (alert+sql@domain),
  - фильтровать входящие и принимать почту только от доверенных отправителей (если возможно),
  - или вовсе не делать почтовый ящик публично доступным — иметь локальную очередь и шлюз к внешним мейлерам.

Дополнительные рекомендации
- Если ящик действительно не используется — лучше удалить или настроить на нем reject с кодом 5xx (чтобы прекратить дальнейший интерес).
- Если хотите отслеживать, откуда «просочился» — сохраняйте все заголовки писем, проверьте содержание (возможно, это тестовая рассылка от конкретного сервиса).
- Настройте мониторинг почтовой активности (уведомления при появлении писем на «спящих» адресах).

Заключение
Самое простое и быстрое — посмотреть логи (определить отправителей), затем либо удалить/отключить неиспользуемый ящик, либо настроить отклонение несуществующих получателей и антиспам. Вероятнее всего это не “целевое” раскрытие (не кто‑то вручную узнал адрес), а либо автоматический перебор/harvest, либо адрес попал в какую‑то базу/бэкап. Если нужно, могу помочь командам для анализа логов, примерами конфигурации postfix/dovecot для отключения catch‑all и настройки reject_unlisted_recipient, а также подсказать, как написать Sieve‑правило для автоматического удаления писем на этот ящик.
Я как-то приобрел VPS. Пока что-то налаживал прошел час. Потом в файловой системе зашел в папку почты и обнаружил около 30 спам-писем. Я так понял, что при создании VPS для какого-то домена хостер генерит email по умолчанию и такие адреса сканируют в непрерывном режиме спамеры. Вот и прилетело.
Похожие вопросы