Должен ли я позволить электронной почте отскочить или отправить ее в черную дыру?

У меня есть много неиспользованных (старых, мертвых) учетных записей на моей машине. Многие из них получают буквально тысячи писем в день, все спам.

Если аккаунт использовался кем-то другим, я позволил почтовому сообщению отскочить, чтобы любой, кто пытается связаться с ним, знал, что что-то не так. Однако я не уверен, что делать с сотнями учетных записей, которые использовались для других целей, таких как одноразовые учетные записи, которые я использовал для веб-сайтов, которые запрашивали мой адрес электронной почты, или адрес, который я использовал для размещения на веб-страницах. ,

Вариант 1.
Переслать всю почту в эти учетные записи /dev/null. Отправитель не получает отказов.

Вариант 2.
Позвольте электронной почте отскочить.

Преимущество отправки электронного письма /dev/nullзаключается в том, что спамер не может использовать меня для создания отказов (спам Backscatter) . то есть: подделать строку «от», чтобы быть кем-то, кто им не нравится, а затем использовать меня, чтобы отправить тонны сообщений об отказе этому человеку.

Преимущество отказов от них заключается в том, что это меньше для меня. Я могу просто удалить элемент из моего файла псевдонимов, и электронная почта отскочит. Кроме того, я продолжаю открывать новые спам-ловушки и добавлять их в свой список «черной дыры», что является пустой тратой времени.

Каковы плюсы и минусы каждого подхода?

До тех пор, пока вы отказываетесь от письма, отказываясь получать его в первую очередь, спаммер не может использовать вас, чтобы раздражать кого-то невинного большим количеством отскоков.

Вы можете либо вернуть ошибку в RCPT TOкоманде, что обычно происходит в случае несуществующего адреса, либо вы можете вернуть успешное выполнение RCPT TOкоманды, но вернуть ошибку в конце DATA.

В обоих случаях конечный результат будет одинаковым. Ваш почтовый сервер не несет ответственности за почту, а отправляющий почтовый сервер теперь отвечает за ее пересылку. В случае спама, это означает, что спамер должен будет генерировать отскоки. (И если это то, что они хотели сделать, они могли бы сделать это, даже не пытаясь доставить вам почту в первую очередь.)

Я не вижу проблем в этом подходе.

Я, однако, вижу проблему в получении почты. Т.е., если ваш почтовый сервер успешно отвечает на протяжении всей транзакции, в том числе и в конце DATA, тогда ваш почтовый сервер несет ответственность за доставку почты. Это проблема, потому что у вас нет правильного выхода.

• Автоматически отбрасывать почту - проблема, потому что, если отправлено какое-либо законное письмо, отправитель никогда не узнает, что оно не было доставлено.
• Отправка сообщений с вашего почтового сервера - это проблема, потому что в этом случае спам возвращается к почтовому ящику невинного человека, а не обратно к спаммеру.

Могут быть случаи, когда распространение адреса электронной почты было настолько ограниченным, что вы знаете, что на этот адрес не может быть отправлено законное письмо. В этих случаях не имеет значения, отклоняете ли вы RCPT TOкоманду или принимаете ли вы почту и молча отбрасываете ее. Но я не могу придумать ситуацию, в которой молча отбрасывать почту лучше, чем отклонять ее во время SMTP-транзакции.

Я собираюсь сделать этот ответ довольно общим, потому что терминология и детали конфигурации будут варьироваться в зависимости от вашего конкретного почтового сервера / программного обеспечения для фильтрации спама.

На самом деле есть 3 подхода для недопустимого получателя:

1. После того, как получатель будет признан недействительным, отправьте сообщение о невозможности доставки отправителю.

2. Закройте SMTP-соединение, пока сообщение еще «в полете». SMTP-сервер отправителя будет отвечать за генерацию сообщения о невозможности доставки.

3. Принять сообщение и молча удалить его. Отправитель не будет знать, было ли получено сообщение.

Существует мало причин использовать подход № 1 больше. В случае атаки Backscatter ваш сервер будет выглядеть как спамер (даже если это невинная жертва), и вы будете тем, кто попадет в черный список. Это также увеличивает нагрузку на ваш сервер и загружает пропускную способность, потому что он должен отправить сообщение об отказе.

Подход № 2 почти всегда лучше, чем подход № 1. Это уменьшает вероятность попадания вашего сервера в черный список или DoSed. Это не исключает возможность обратного рассеяния в отношении невинного стороннего адреса, но, по крайней мере, ваш сервер не является тем, который отправляет сообщения о сбое.

Подход № 3 исключает возможность обратного рассеяния. Это также помогает защититься от атаки Directory Harvest . Однако это также означает, что если внешний отправитель неправильно наберет ваш адрес, он никогда не узнает. Это также может быть проблемой, если кто-то покидает вашу компанию, а клиент пытается связаться с бывшим сотрудником.

Я унаследовал систему электронной почты, которая использовала подход № 3 из-за опасений по поводу DHA. Это вызвало больше проблем, чем оно того стоило. Теперь мы используем подход № 2. (Обратите внимание, что существуют другие способы смягчения DHA.)

Если ваш почтовый сервер настроен правильно, вы должны отклонить письмо неизвестным пользователям во время транзакции SMTP.

Отклонить электронную почту во время транзакции SMTP

Ваш сервер должен быть настроен на отклонение электронной почты неизвестным пользователям на этапе транзакции SMTP. Это возвращает код ошибки 550 SMTP отправляющему серверу. Так как это происходит во время транзакции SMTP, ваш сервер никогда не отправляет отчет о недоставке (он же отказов).

При правильной настройке это предотвращает обратное рассеяние, поскольку отклонение отправляется непосредственно на отправляющий сервер, а другие заголовки электронной почты игнорируются.

Льготы

Преимущества этого подхода состоят в том, что вы очень быстро отклоняете электронную почту в процессе транзакции SMTP. Это может означать:

• Снижение использования ресурсов на вашем сервере, особенно если вся электронная почта отправляется на обработку после ее принятия (антивирусная / av-фильтрация).
• Отправители часто удаляют эти адреса электронной почты из своих списков, чтобы не попасть в черный список.

Учтите, что при нулевой маршрутизации электронной почты отправляющий сервер считает, что сообщение было доставлено успешно. У них нет причин прекращать рассылку этих несуществующих адресов. В результате, когда эти старые адреса накапливаются, вам необходимо все больше серверных ресурсов для обработки электронной почты.

Для этого вам просто нужно удалить пользователей из системы электронной почты. Если вам нужны резервные копии текущей электронной почты, это нормально, вы просто хотите, чтобы ваш сервер отправил 550 user unknownответ.