Мы рассылаем информационные бюллетени / массовую рассылку (разумеется, двойная подписка). Мы автоматически удаляем жесткие отказы (почтовый ящик недоступен, пользователь неизвестен, хост неизвестен ...) сразу из наших списков рассылки.
Но создается много недоставленных писем, потому что почтовый ящик пользователя заполнен / пользователь превышает квоту. Таким образом, адрес электронной почты все еще существует, но почтовый ящик заполнен.
Итак, два наиболее распространенных сценария, вероятно,
а) пользователь все еще использует свою учетную запись и в ближайшем будущем удалит некоторые электронные письма, чтобы он больше не превышал квоту и мог снова получать электронные письма.
б) пользователь покинул свою учетную запись (по какой-либо причине), она была заполнена и все. Он больше никогда не будет использоваться ...
Итак, первый сценарий говорит мне НЕ удалять адрес электронной почты из нашего списка рассылки, второй сценарий говорит мне, что я должен удалить его. Конечно, не знаю.
Какая стратегия лучше всего с точки зрения работы над «репутацией моего почтового сервера / IP-адреса»? Должен ли я попытаться отправить его в течение следующих нескольких дней / нескольких недель, и если он все еще не работает, следует ли рассматривать это как b)?
Я предполагаю, что большинство ESP удалит неактивные / полные адреса электронной почты через определенное время, поэтому в любом случае они станут жесткими отскоками? Или ESP будет препятствовать слишком частой отправке писем в полный почтовый ящик?
Ваш почтовый сервер должен повторить попытку, если доставка почты отложена. Используйте менее агрессивную политику повторных попыток, например, через 1, 3, 6, 12 и 24 часа, прежде чем произойдет сбой. Вы также можете повторить попытку через 2 и 4 дня. Если информационные бюллетени чувствительны ко времени, вам может потребоваться еще более короткий период повтора. Вы вряд ли будете наказаны за повторную попытку после временного сбоя, например переполнения почтового ящика. Вас могут наказать за агрессивную политику повторных попыток. Я видел, как серверы повторяют попытку несколько раз в минуту, пока не добьются успеха.
Некоторые организации передают временные сбои на второй сервер, предназначенный для обработки повторных попыток. Если вы это сделаете, не продолжайте передавать его на другие серверы.
Если вы отправляете рассылки чаще, чем раз в месяц, рассмотрите возможность временной приостановки адресов, которые возвращаются с сервера повторных попыток. Определение того, как долго адрес возвращается из-за долгосрочных временных сбоев (показатель успешной доставки). Подумайте о том, чтобы удалить адреса, которые не работали в течение нескольких месяцев.
Вы будете накапливать мертвые адреса, поскольку не все организации будут возвращать мертвые адреса. Подумайте о том, чтобы отправлять сообщения с просьбой к пользователям снова регистрироваться каждый год или около того. Хотя вы можете не захотеть отбрасывать пользователей сразу, вы можете отказаться от них, если они не отвечают в течение двух или более лет.
РЕДАКТИРОВАТЬ: переполнение квоты / переполнение почтового ящика - не единственная причина, по которой сообщения будут отложены. Вам следует повторить все отсрочки по разумному графику, как указано выше. Сервер будет откладывать соединения, если он занят. Серые списки откладывают сообщения от новых серверов, которые не внесены в белый список. Мой сервер также откладывает сообщения с серверов, которые не проходят различные проверки политик: SPF, rDNS (IP-адрес), rDNS (HELO / EHLO, если IP-адрес не совпадает) и т. Д. Мои серые списки ведутся для каждого сетевого блока, но мой список политик выполняется сервером. Мой список политик применялся бы к службам, контролируемым Microsoft, если бы они не были в белом списке. В противном случае мои списки политик перехватывали спам-ботов и рассыльщиков нежелательной почты.
RFC1893 - Коды состояния расширенной почтовой системы:
3.3 Mailbox Status
(...)
X.2.2 Mailbox full
The mailbox is full because the user has exceeded a
per-mailbox administrative quota or physical capacity. The
general semantics implies that the recipient can delete
messages to make more space available. This code should be
used as a persistent transient failure.