Настройка отправки писем без их попадания в спам.
Вариант с отправкой писем через сторонние SMTP-серверы (Mandrill, Mailgun, Яндекс) и через личные адреса почтовых сервисов рассматривать не буду (там все очень просто, если следовать предоставляемым инструкциям по установке) - рассмотрю лишь вариант, что у нас есть свой сервер, на котором установлен соответственно почтовый сервер, например exim (как у большинства хостеров).
Нам потребуется доступ к редактированию DNS-записей и минимальное владение консолью для настройки DKIM (если есть ISPmanager - и этот пункт становится неактуальным). Всего потребуется настроить (добавить) 4 новые записи в DNS-записи вашего домена: PTR , SPF , DKIM и DMARC .
Настройка этой подписи, пожалуй, самая сложная - как последствие, у 90% сайтов ее нет, но крайне рекомендуется. Очень просто настроить ее в ISPmanager: включаете поддержку DKIM на вкладке возможностей, в редактировании почтового домена ставите галочку DKIM и забираете уже готовую запись в свойствах домена (NS). Если ISPmanager нет, советую воспользоваться этой, достаточно простой статьей: .
Настройка сборщика возвратной почты.
В XenForo есть совершенно потрясающий механизм, который практически никем не используется - сборщик возвратной почты (bounce email). Думаю каждый встречался с ситуацией, что после совершения массовой рассылки на почтовый ящик приходит большое число писем следующего вида:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
***@rambler.ru
SMTP error from remote mail server after RCPT TO:<***@rambler.ru>:
host imx1.rambler.ru : 540 5.7.1 <***@rambler.ru>:
Recipient address rejected: Your emails has been returned because the intented recipient"s email account has been suspended. The account must be re-activated to receive incoming messages.
Эти письма являются сигналом того, что у ваших пользователей устарели их адреса электронной почты (ящики заблокированы, удалены, переполнены), а значит новые письма они от вас не получат и в случае необходимости аккаунт на форуме также восстановить не смогут. Многие пользователи о том, что у них используется устаревший адрес электронной почты даже не знают, а почтовые сервисы, видя большое число отправок писем на несуществующие адреса, могут банально внести ваш домен в спам-лист .
С этим нужно бороться, потому что даже на моем форуме, где эта система работает уже не первую рассылку, "возвращенных" писем очень много, в сравнении с числом пользователей:
В принципе, это вся настройка. Форум автоматически с определенными интервалами будет заходить на указанный вами служебный почтовый ящик, скачивать копии возвращенных писем, которые на него поступили и удалять их оттуда. В разделе Инструменты - Журнал отказов в доставке писем вы эту статистику сможете просмотреть. Особо подчеркиваю, что ни для каких других целей этот ящик использовать нельзя, а то рискуете получить несколько достаточно забавных багов в логах админки.
Согласно заданным вами условиям, при возврате, к примеру, 3 писем с одного адреса, пользователь будет отправляться на автоматическую реактивацию - ему будет предложено указать актуальный адрес электронной почты и заново активировать аккаунт. Какое либо ваше участие при этом не требуется - пользователи будут сами указывать свои актуальные адреса электронной почты, а следовательно проблема уйдет со временем. А при рассылках, пользователей с некорректным адресом электронной почты можно будет исключить из нее - тем самым избежав возможного попадания в спам листы.
Текста написано много, но на самом деле настройка всего - и сервера и сборщика почты, занимает считанные минуты, если точно следовать инструкциям. Настроите один раз и забудьте о том, что письма вашего форума куда-то не дошли или что ваш домен внесли в спам-листы за неактуальность базы.
Для некоторого упрощения части задач, описанных выше, можно использовать либо - что вам больше нравится. Я использую первый - но выбор полностью за вами. Добавление ваших доменов туда даст удобные, неограниченные по размеру почтовые ящики с уже встроенными спам-фильтрами + некоторое упрощение настройки сервера (часть записей будет предоставлена автоматически (за исключением DKIM, которую для отправки почты со своего сервера надо генерировать вручную так или иначе)).
Когда вы, находясь вне дома, отправляете сообщение электронной почты с помощью домашней почтовой учетной записи, это сообщение может вернуться с ошибкой 550, 553 или ошибкой ретрансляции. То же самое может произойти, когда вы, находясь вне офиса, пытаетесь отправить сообщение электронной почты с помощью рабочей почтовой учетной записи.
Ретрансляция происходит, когда почтовое сообщение отправлено на адрес электронной почты, домен которого (имя после символа @, например adatum.com) не обрабатывается протоколом SMTP или сервером исходящей почты, получающим от отправителя запрос на доставку сообщения. SMTP-серверу необходимо подключиться к другому SMTP-серверу, чтобы ретранслировать сообщение.
Если при отправке почтового сообщения возникает ошибка ретрансляции, ваш SMTP-сервер (исходящей почты) может вернуть ваше сообщение вместе с сообщением об ошибке, например, такого вида:
"Не удается отправить сообщение, поскольку сервер отказался принять адрес одного из получателей. В письме был указан адрес: <адрес эл. почты>. Тема: <тест>, учетная запись: <тест>, сервер:
Точный текст сообщения об ошибке будет зависеть от вашего поставщика интернет-услуг. Некоторые поставщики не возвращают сообщение об ошибке, когда определяют исходящие сообщения как нежелательную рекламу. В этих случаях все выглядит так, как будто ваше сообщение отправляется в обычном режиме (в Outlook остается в папке Исходящие и появляется в папке Отправленные ), но получателю оно не доставляется.
Ваше сообщение отклонено, поскольку SMTP-сервер (исходящей почты) не распознал вас как полномочного пользователя.
SMTP - это протокол (стандарты, используемые компьютерами для взаимодействия), который используется на большинстве серверов электронной почты для отправки сообщений в Интернете. Если вы используете почтовую программу (например, Outlook), которая позволяет хранить сообщения на компьютере, вам необходим доступ к SMTP-серверу для отправки сообщений.
Примечание: Веб-системы электронной почты (например, Windows Live Mail или Yahoo! Mail) работают иначе и не рассматриваются в этой статье.
Рекламные сообщения, распространяемые без запроса, называют нежелательной почтой или спамом. Объем нежелательной почты продолжает расти, потому что ее отправка практически ничего не стоит тем, кто ее рассылает. Фактически отправителю даже не обязательно отправлять нежелательную почту через SMTP-сервер (исходящей почты) своего поставщика интернет-услуг.
При создании базовой структуры Интернета никто не предвидел, к каким последствиям приведет возможность отправлять миллионы нежелательных сообщений за ничтожно малую плату. Благодаря способности SMTP-серверов к ретрансляции отправители нежелательной почты маскируют ее подлинный источник, передавая ее через сторонние серверы, на которых разрешены такие открытые ретрансляции. В результате нежелательная почта как бы приходит с сайта, который ретранслирует сообщение и скрывает личность настоящего отправителя.
До недавнего времени большинство почтовых SMTP-серверов работали на основе доверительной открытой системы. В такой системе кто угодно откуда угодно может передать почтовое сообщение SMTP-серверу, а сервер должен принять его и переслать получателю или другому почтовому серверу, на котором находится почтовый ящик получателя. При такой открытой ретрансляции нет ограничений, запрещающих кому-либо отправлять почту через SMTP-сервер.
По мере увеличения объемов нежелательной почты администраторы сети (люди, отвечающие за управление серверами поставщика интернет-услуг) начали вводить ограничения на своих почтовых SMTP-серверах. Эти ограничения не позволяют использовать почтовый сервер всем подряд. Представьте, что в вестибюле вашей организации есть телефон, доступный для всех, в том числе для тех, кто не является сотрудником организации. Теперь телефоном разрешено пользоваться только сотрудникам.
На сегодняшний день используются ограничения нескольких типов.
Требуется проверка подлинности SMTP. Так же как вы используете имя пользователя и пароль для доступа к POP3-серверу (входящей почты) и своим почтовым сообщениям, вам требуется ввести имя пользователя и пароль для отправки почтовых сообщений через SMTP-сервер. Обычно это те же имя пользователя и пароль, что и для POP3-сервера, но могут быть и уникальные.
Требуется сначала подключиться к POP3-серверу (входящей почты) поставщика интернет-услуг. Чтобы получить свои новые почтовые сообщения, вы обычно подключаетесь к POP3-серверу (входящей почты). Для доступа к почтовому ящику вам нужно ввести имя пользователя и пароль. Администратор сети может настроить сервер таким образом, что если вы сначала подключаетесь к POP3-серверу входящей почты и проходите проверку подлинности, он будет утверждать все запросы на отправку почтовых сообщений через SMTP-сервер исходящей почты, на котором в ином случае эта возможность будет ограничена.
Требуется подключение из авторизованного расположения в сети. Если вы из дома подключаетесь к поставщику интернет-услуг по телефонной линии, с помощью кабеля или через DSL-модем, подключение идет напрямую к сети поставщика. Вы заслуживаете доверия, поскольку у вас есть учетная запись с именем пользователя и паролем, которые предоставил поставщик интернет-услуг. Вам как клиенту разрешается использовать SMTP-сервер для отправки почтовых сообщений.
Требуется подключение с определенного IP-адреса или диапазона IP-адресов. Ваш поставщик интернет-услуг может разрешить доступ к SMTP-серверу людям, не подключенным к сети напрямую. Например, это может быть удаленный пользователь в офисе. Основная проблема состоит в том, что во многих местах используются динамические IP-адреса. При этом вы не можете быть уверены в том, что при каждом подключении у вас один и тот же IP-адрес. У некоторых организаций может быть зарезервирован блок или диапазон IP-адресов. Поставщик интернет-услуг может считать тех, кто подключается с этих IP-адресов, проверенными пользователями. Он может предоставить дополнительные сведения.
Возможных сценариев ретрансляции очень много. Ниже приведены самые распространенные ситуации. Возможно, одна из них похожа на вашу.
Ситуация |
Это ретрансляция? |
Вы дома, и у вас есть учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com , с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com . |
|
То же, что и в первой ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com . |
Да, но она не блокируется. Вы подключаетесь напрямую к поставщику интернет-услуг и тем самым получаете полномочия для отправки почты через его SMTP-сервер (исходящей почты) на любые адреса, независимо от расположения почтового ящика получателя. |
Вы на работе. Ваш рабочий почтовый адрес оканчивается на @thephone-company.com , и у вас есть домашняя учетная запись поставщика интернет-услуг, адрес которой оканчивается на @proseware.com и с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение человеку, почтовый адрес которого тоже оканчивается на @proseware.com . |
Нет. Ваша почта обрабатывается обычным способом. |
Вы остановились в гостинице или воспользовались в аэропорту интернет-терминалом, предоставляющим доступ в Интернет. У вас есть домашняя учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com , с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com . |
Нет. Ваша почта обрабатывается обычным способом. |
То же, что и в предыдущей ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com . |
Да, и это сообщение может быть заблокировано как ретранслируемая почта. Вы пытаетесь использовать домашний SMTP-сервер (исходящей почты) своего поставщика интернет-услуг, хотя не подключены к его сети. SMTP-сервер не может удостоверить вас как полномочного подписчика поставщика интернет-услуг. Кроме того, вы просите SMTP-сервер принять сообщение и подключиться к другому SMTP-серверу, чтобы доставить его в почтовый ящик получателя. |
Если ваша ситуация рассматривается как ретрансляция, вы должны отправить сообщение через сервер, к которому сейчас подключаетесь. То есть, если вы на работе или вне дома и не используете своего поставщика интернет-услуг для подключения к Интернету, но хотите отправить сообщение из своей домашней учетной записи, предоставленной этим поставщиком, вам нужно изменить параметры почтовой учетной записи, указав тот SMTP-сервер, который вы используете там, где находитесь (например, рабочий SMTP-сервер). Пошаговые инструкции см. в статье .
Если это не работает или вы предпочитаете использовать домашнюю учетную запись, вам нужно связаться со своим поставщиком интернет-услуг и спросить, доступны ли вам описанные ранее параметры. Что касается первых двух ограничений (требуется проверка подлинности SMTP и требуется сначала подключение к POP3-серверу входящей почты поставщика интернет-услуг), вы можете внести изменения в Параметры учетной записи в Outlook. Инструкции см. в статье Изменение параметров учетной записи электронной почты .
Вы изменили параметры SMTP в Outlook или нашли параметр, который разрешит вам отправлять почтовые сообщения. Но вы по-прежнему не можете отправить почту и получаете сообщение об ошибке.
Возможно, вы все сделали правильно, но администраторы сети используют еще какую-то функцию системы безопасности для предотвращения спуфинга удостоверений. Спуфинг удостоверений - это просто способ отправки почтового сообщения, при котором вы скрываете, кто вы.
В Outlook, как и в большинстве почтовых программ, можно указать "отображаемое имя" и обратный почтовый адрес, который появляется при ответе на ваше сообщение. В нежелательной почте эти поля почти всегда содержат ложную информацию. Вы правда верите, что сообщения о том, как быстро разбогатеть, пришли от супермодели или мирового лидера?
Чтобы предотвратить спуфинг удостоверений, некоторые поставщики интернет-услуг ограничивают возможность вставки ложной информации в поле адреса в ответах. Например, если доменное имя вашего поставщика интернет-услуг оканчивается на proseware.com, поставщик может запретить вам указывать обратный адрес [email protected] . Это ограничение используется не так широко, как описанные ранее, но может применяться ко всем пользователям независимо от их местонахождения и способа подключения. В этом случае альтернативы нет. Если администратор сервера использует этот способ, вы должны указывать в обратном адресе домен, соответствующий вашему текущему подключению.
Примеры писем:
550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc
550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain"s 550-5.7.1 DMARC policy. Please contact administrator of mail.ru domain if this 550-5.7.1 was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC
550 5.7.1 Email rejected per DMARC policy for ...
Проблема с доставкой сообщений связана с применением новой политики DMARC , связанной с ужесточением правил прохождения спам фильтров.
DMARC — это протокол защиты от спама и от несанкционированной рассылки почты от имени домена, основанный на существующих механизмах DKIM и SPF . Официальный сайт: dmarc.org .
Если вы получаете подобные приведённым выше сообщения, скорее всего, почта с сайта у вас отправляется от имени почтового ящика на базе @mail.ru , @bk.ru , @list.ru или @inbox.ru . Mail.Ru не принимает сообщения, отправленные через phpmail, если в почтовых заголовках числится ящик, принадлежащий mail.ru. Такие сообщения, согласно внедрённой Mail.Ru политике DMARC , отклоняются.
Решить проблему можно двумя способами:
Обычно e-mail, от имени которого рассылаются почтовые сообщения, прописывается в административной части CMS. Также его можно изменить напрямую в скрипте, рассылающем сообщения (поле «From»).
Необходимо, чтобы сообщения рассылались с ящика на базе вашего доменного имени, например «[email protected]» , где domain.ru — ваш домен. .
Также, почтовый ящик необходимо изменить в файле php.ini :
Изменение ящика в php.ini
найдите строку вида:
sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"
В данной строке вместо «[email protected]»
укажите почтовый ящик, не относящийся к доменам @mail.ru
, @bk.ru
, @list.ru
и @inbox.ru
.
Желательно указать почтовый ящик на вашем домене, например, «[email protected]»
, где domain.ru
— ваш домен.
Кроме этого, прописанный в php.ini почтовый ящик должен существовать. Если вы пользуетесь почтой на хостинге, создайте почтовый ящик на домене по и пропишите его в файле php.ini .
Вы можете рассылать сообщения от имени вашего почтового ящика на базе Mail.Ru, настроив SMTP-авторизацию. В этом случае все сообщения через ваш сайт будут отправлять напрямую с серверов Mail.Ru.
Борьба со спамом - это головная боль всех ответственных администраторов почты. Чего только они не изобретают, чтобы любимым пользователям лучше жилось. Однако, как показала практика общения со многими системными администраторами, почему-то далеко не все представляют как правильно фильтровать спам.
Чаще всего встречается подход «добавим кучу RBL (DNSBL) и будем радоваться жизни». Подход не верный чуть более, чем полностью. Второй по популярности - контент-фильтры, зачастую купленные за бешеные деньги. Такой подход тоже в большинстве случаев совершенно неоправдан.
А ведь всё так просто, для спокойной жизни достаточно всего лишь пристально присматриваться к трём заголовкам входящей SMTP сессии. Порывшись на Хабре и в закоулках интернета так и не нашёл исчерпывающей статьи на тему правильной настройки SMTP сервера с точки зрения противодействия спаму. Поэтому решил расписать всё, что знаю на эту тему сам и чем успешно пользуюсь.
Кстати: эта статья конечно ориентирована в первую очередь на администраторов, желающих сделать качественный фильтр спама. Однако с другой стороны она содержит очень важные сведения для тех, кому приходится просто работать с почтой, но кто плохо разбирается во всех тонкостях процесса электронной пересылки корреспонденции.
Итак, если вы хотите обезопасить своих пользователей от спама или наоборот, хотите чтобы кто-то случайно не обезопасил пользователей от ваших писем - добро пожаловать под кат.
Небольшая замечание: статья написана с прицелом на настройку почтового сервера Postfix
, но в целом носит скорей теоретический характер. Описанные опции Postfix нужно указывать в соответствующих *_restriction
параметрах конфигурационного файла, за подробностями обращайтесь к любому руководству по настройке Postfix.
Немного отвлечёмся: представьте, что к вам придёт лицо крайне отталкивающей наружности и вручит плотно запечатанную посылку с обратным адресом «Трям из Тилимилитрямдии». Рискнёте принять и открыть? Вряд ли. Так вот, электронную почту можно тоже легко проверять и отсеивать исходя только из адресной информации, причём простор для возможных действий тут гораздо шире.
Как вам должно быть известно, почта в интеренете передаётся между почтовыми серверами по протоколу SMTP. Любое общение по этому протоколу начинается с трёх обязательных заголовков: HELO , MAIL FROM и RCPT TO . То есть перед тем, как начать передавать какие-либо данные, сервер сначала представляется (HELO), потом сообщает обратный адрес отправителя (MAIL FROM) и затем - адрес получателя (RCPT TO). Эти три заголовка и есть подпись на электронном конверте, и практически весь спам можно отсеять только исходя из их анализа. Большинство попыток передать что-то моему серверу не доходят дальше MAIL FROM, то есть письма отсеиваются ещё до фактического принятия, что значительно снижает нагрузку. То есть вместо того, чтобы открыть посылку от Тряма и обнаружить там споры сибирской язвы, я сразу посылаю почтальона куда подальше.
Итак, что же надо делать, чтобы не принимать письма, заведомо являющиеся спамом? Пойдём по порядку.
MX записи содержат адреса серверов, на которые должны доставляться письма для указанного домена. Однако в целях борьбы со спамом появилась технология, позволяющая указывать в DNS также адреса серверов, с которых могут приходить письма от указанного домена. Имя ей - Sender Policy Framework .
Подробно вдаваться во все тонкости технологии я не буду, скажу лишь, что TXT запись
V=spf1 +mx -all
Всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах. Я рекомендую жёстко запрещать отправку писем из вашего домена со всех хостов, кроме ваших MX серверов. Вкупе с проверкой SPF на вашем сервере подобная настройка сразу срежет все письма, посылаемые со сторонних хостов от имени пользователей вашего домена на адреса пользователей вашего же домена. А такого спама чуть ли не половина, поскольку обычно SMTP серверы очень плохо защищены от писем из своего же собственного домена, и спамеры этим активно пользуются. SPF раз и навсегда избавит вас от писем Васе Пупкину, написанных судя по конверту Васей же Пупкиным, но пришедших с сервера в каком-нибудь Никарагуа.
Как настроить SPF в Postfix вам расскажет гугл, информации навалом и ошибиться нельзя, так что не будем тратить время на технический подробности.
Есть ещё пару крайне важных замечаний по поводу DNS. Скорее всего вы знаете, что основные записи DNS, так называемые A записи, преобразуют имя в IP адрес. Кроме них есть ещё CNAME записи, которые назначают псевдоним уже существующему имени. Именно эти два типа записей составляют основу всей системы доменных имён.
Но мало кто из пользователей знает, что есть так же обратные записи, которые преобразуют IP в доменное имя. Они носят название PTR. Так вот, есть два неписаных (строго говоря) правила, которым всё же все следуют:
Если вы не соблюдёте одно из этих требований - приготовьтесь к тому, что минимум четверть почты с вашего домена будет распознаваться как спам. Обусловлено это простым тезисом: благонадёжный отправитель всегда всё настраивает соблюдая правила, соответственно если правила не соблюдены - то отправителю доверять не следует, а значит и принимать от него почту - тоже.
Ну а чтобы включить проверку PTR у себя, используйте опцию
Reject_unknown_client_hostname
Она требует, чтобы IP, с которого совершается соединение, резолвился в имя через PTR, а это имя резолвилось в свою очередь обратно в искомый IP.
Есть и менее жёсткое ограничение, задаваемое опцией
Reject_unknown_reverse_client_hostname
В этом случае сервер будет проверять только наличие PTR записи, но не будет требовать существования соответствующей записи A.
Reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
Первая запрещает приём писем от хостов, передающих приветствие с некорректным синтаксисом, вторая - от хостов, передающих не FQDN в HELO запросе.
Однако не FQDN передают только самые глупые спамеры (и продукты MS, но им, как известно, законы не писаны), в конце концов представиться gmail.com не составляет труда. Поэтому надо ещё немного присмотреться к HELO. Для этого служат опция
Reject_unknown_helo_hostname
Которая запрещает приём писем от серверов, представляющихся адресом, для которого не существует A или MX записи.
Однако если в адресе отправителя указан домен, который вовсе не существует, то письмо совершенно очевидно принимать не стоит. И уж точно не стоит принимать письмо, в котором в качестве обратного адреса указано нечто, вообще адресом не являющееся. За отказ в принятии для таких писем отвечают две опции:
Reject_non_fqdn_sender
reject_unknown_sender_domain
Первая - проверка адреса на написание, вторая - проверка существования домена.
Уже неплохо, но можно сделать кое-что ещё. Можно запросить сервер, обслуживающий указанный адрес отправителя, на предмет существования на нём пользователя с этим адресом. Действительно, вроде бы неплохая идея удостовериться в том, что обратный адрес действительно существует, иначе нам вполне может придти письмо от эфемерного фантома, о котором никто и не слыхивал.
Технически это реализуется очень просто: наш сервер открывает встречную SMTP сессию, пытаясь послать письмо по адресу отправителя. Если удаётся успешно пройти этап посылки RCPT TO с этим адресом, т.е. если принимающий сервер вдруг не заявляет, что указанного ящика на нём нет, то считается, что присланный нам обратный адрес существует. Данные (то есть письмо) при проверке естественно никакие не передаются, сессия прерывается после RCPT TO.
За такую проверку обратного адреса отвечает опция
Reject_unverified_sender
Из сказанного выше следует, что для любого адреса, с которого вы рассылаете почту из своего домена, должен существовать ящик на вашем сервере. Иначе ваши письма не пройдут проверку обратного адреса на стороне получателя и соответственно не будут доставлены по назначению. Это актуально для всяких рассылок и прочей вроде как односторонней коммуникации, не требующей ответа. Всегда создавайте ящики для всех адресов, с которых вы рассылаете почту. Если вы не хотите получать ответы на какой-то адрес, то просто посылайте письма на него в /dev/null, но принимать эти письма вы обязаны .
Reject_non_fqdn_recipient
Кроме того нам бы не хотелось принимать почту на адреса, для которых у нас нет почтовых ящиков. Чтобы настроить такое поведение надо сначала создать список обслуживаемых ящиков, дальше рассказать о нём Postfix через один из *_recipient_maps параметров конфигурационного файла, ну а дальше либо воспользоваться параметром конфигурационного файла
Smtpd_reject_unlisted_recipient = yes
Либо запрещающей опцией, имеющей тот же эффект:
Reject_unlisted_recipient
В любом случае Postfix перестанет принимать письма для обслуживаемых доменов , если не существует ящика для получателя. Однако это ограничение никак не скажется на пересылке корреспонденции на адреса, которые не находятся в обслуживаемых доменах.
Ну и наконец можно вообще запретить открытую пересылку писем через ваш Postfix, оставив только возможность принимать письма на известные адреса. Для этих целей служит опция
Reject_unauth_destination
Она запрещает отсылку писем всем незарегистрированным пользователям (да, вам придётся настроить SMTP авторизацию). Всегда используйте эту опцию! Иначе быстро попадёте во всякие DNSBL.
Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем при первом соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения - то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек.
О настройке грейлистинга в Postfix так же предлагаю прочитать в Google, это несложно и ошибиться не получится.
Для администраторов почтовых серверов:
Конечно, предложенные настройки фильтруют не весь спам. Поэтому вполне возможно вам потребуется дополнительно использовать ещё и контекстный фильтр, который будет анализировать содержание писем, например,