У меня на машине много неиспользуемых (старых, мертвых) учетных записей. Многие из них получают буквально тысячи писем в день, спам.
Если учетная запись использовалась человеком, я позволяю электронной почте отказываться, чтобы любой, кто пытается связаться с ним, знал, что что-то не так. Однако я не уверен, что делать с сотнями учетных записей, которые использовались для других целей, например, с одноразовыми учетными записями, которые я использовал для веб-сайтов, которые запрашивали мой адрес электронной почты или адреса, которые я использовал для перечисления на веб-страницах. .
Опция 1:
Пересылать всю почту на эти учетные записи на /dev/null. Отправитель не получает отказ.
Вариант 2:
Пусть письмо отскочит.
Преимущество отправки электронного письма на адрес /dev/null в том, что спамер не может использовать меня для создания сообщений о недоставке (Обратный спам). то есть: создать строку "от", чтобы быть кем-то, кто им не нравится, а затем использовать меня, чтобы отправлять тонны сообщений о недоставке этому человеку.
Преимущество подпрыгивания их в том, что для меня это меньше обслуживания. Я могу просто удалить элемент из файла псевдонимов, и письмо будет возвращено. Кроме того, я продолжаю обнаруживать новые ловушки для спама и добавлять их в свой список «черной дыры спама», что является пустой тратой времени.
Каковы плюсы и минусы каждого подхода?
Пока вы отклоняете почту, отказываясь ее получать, спамер не сможет использовать вас, чтобы рассердить кого-то невиновным множеством отказов.
Вы можете либо вернуть ошибку на RCPT TO команда, что обычно происходит в случае несуществующего адреса, или вы можете вернуть успех на RCPT TO команда, но возвращает ошибку в конце DATA.
В обоих случаях конечный результат будет одинаковым. Ваш почтовый сервер не несет ответственности за почту, а отправляющий почтовый сервер теперь отвечает за ее доставку. В случае спама это означает, что спамеру придется генерировать отказы. (И если бы они этого хотели, они могли бы сделать это, даже не пытаясь доставить вам почту.)
Я не вижу в таком подходе проблем.
Однако я вижу проблему в приеме почты. Т.е. если ваш почтовый сервер отвечает успешно на всем протяжении транзакции, в том числе в конце DATA, то доставка почты становится ответственностью вашего почтового сервера. Это проблема, потому что у вас нет правильного выхода.
Могут быть случаи, когда распространение адреса электронной почты изначально было настолько ограниченным, что вы знали, что на этот адрес не могло быть отправлено никаких законных писем. В этих случаях не имеет значения, отклоните ли вы RCPT TO или если вы принимаете почту и молча отбрасываете ее. Но я не могу придумать ситуацию, в которой тихое удаление почты лучше, чем отклонение ее во время транзакции SMTP.
Я собираюсь сделать этот ответ довольно общим, потому что терминология и детали конфигурации будут зависеть от вашего конкретного почтового сервера / программного обеспечения для фильтрации спама.
На самом деле существует 3 подхода к неверному получателю:
После того, как получатель определен как недействительный, отправьте отправителю сообщение о невозможности доставки.
Закройте SMTP-соединение, пока сообщение еще находится «в полете». SMTP-сервер отправителя будет отвечать за создание сообщения о невозможности доставки.
Примите сообщение и удалите его без уведомления. Отправитель не будет знать, было ли получено сообщение.
Больше нет причин использовать подход №1. В случае атаки Backscatter ваш сервер будет выглядеть как спамер (даже если это невинная жертва), и вы попадете в черный список. Это также увеличивает нагрузку на ваш сервер и увеличивает пропускную способность, потому что он должен отправлять сообщение о недоставке.
Подход №2 в целом лучше, чем подход №1. Это снижает вероятность попадания вашего сервера в черный список или DoSed. Это не исключает возможности обратного рассеяния на невиновный сторонний адрес, но, по крайней мере, ваш сервер не является тем, кто отправляет сообщения о недоставке.
Подход № 3 исключает возможность обратного рассеяния. Это также помогает защититься от Атака сбора урожая каталога. Однако это также означает, что, если внешний отправитель неправильно введет ваш адрес, он никогда не узнает. Также может возникнуть проблема, если кто-то уйдет из вашей компании, а клиент попытается связаться с бывшим сотрудником.
Я унаследовал систему электронной почты, которая использовала подход №3 из-за опасений по поводу DHA. Это доставило больше хлопот, чем того стоило. Теперь мы используем подход №2. (Обратите внимание, есть и другие способы уменьшить воздействие ДГК.)
Если ваш почтовый сервер настроен правильно, вы должны отклонять электронную почту неизвестным пользователям во время транзакции SMTP.
Отклонить электронную почту во время транзакции SMTP
Ваш сервер должен быть настроен на отклонение электронной почты неизвестным пользователям на этапе транзакции SMTP. В этом случае отправляющему серверу будет возвращен код ошибки SMTP 550. Поскольку это происходит во время SMTP-транзакции, ваш сервер никогда не отправляет отчет о недоставке (он же bounce).
При правильной настройке это предотвращает обратное рассеяние, поскольку отклонение отправляется непосредственно на сервер-отправитель, а другие заголовки электронной почты игнорируются.
Преимущества
Преимущества этого подхода в том, что вы очень скоро отказываетесь от электронной почты в процессе транзакции SMTP. Это могло означать:
Учтите, что если вы обнуляете маршрут электронной почты, отправляющий сервер считает, что сообщение было доставлено успешно. У них нет причин прекращать посылку по этим несуществующим адресам. В результате, по мере того, как эти старые адреса накапливаются, вам требуется все больше и больше ресурсов сервера для обработки электронной почты.
Чтобы реализовать это, вам просто нужно удалить пользователей из почтовой системы. Если вам нужны резервные копии текущей электронной почты, это нормально, вы просто хотите, чтобы ваш сервер отправлял 550 user unknown ответ.