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