Домен для helo

Спам-фильтр проверка домена в HELO, EHLO

Дилер

Регистрация: 09-Июл-05
Местонахождение: Russian Federation
Статус: Offline
Количество сообщений: 172

На адрес, с которого пришел запрос HELO или EHLO SMTP фильтр никак не реагирует, за исключением проверки его в RBL. Домен же указаный в «mail From:» проверяется на присутсвие MX записей, однако это еще не факт, что письмо бало отослано изначально с этого домена. ОЧЕнь желательно поискать сам адрес, с которого пришел запрос в DNS, и если не нашли или нашли, но нет MX записей в зоне, выставить какой нибудь флаг. Анализ трассировки показал, что в 90% случаев по адресам, с которых приходит спам нет MX записей, зато в уважаемых почтовых серверах это присутствует mail.ru, list.ru и т.д. Конечно перестанет приниматься почта с «перенаправилетей» почты, но их в последнее время уже мало кто использует, в основном доставляют непосредственно. Эта проверка позволила бы очень здорово облегчить жизнь, т.к. спамеру, чтоб его письма приходили уже необходимо тогда зарегистрировать домен и зону, разместить в них MX записи, а это уже сложнее, чем отсылать спам с динамических адресов провайдеров. С уважением Check.

Плох не тот кто упал, а кто упав не захотел подняться.

Junior member

Регистрация: 20-Фев-06
Местонахождение: Russian Federation
Статус: Offline
Количество сообщений: 1986

В с-вах SMTP шлюза есть галка проверять адрес отправителя на наличие MX записи.

Дилер

Регистрация: 09-Июл-05
Местонахождение: Russian Federation
Статус: Offline
Количество сообщений: 172

Галка то есть, только вот результата нет. У меня на локальном комьютере SMTP сервер не стоял, на нем была запущена программа редиректа SMTP, есть такая прога, SMTP relay называется, вся почта приходила с одного единственного адреса, для которого не было даже записи в домене, и уж естественно не было и подавно MX записей для не существующего домена. Чисто теоритически эту программу можно было настроить отсылать письма и на другие адреса, не только на адрес моего почтовика. — НИ КАКОЙ РЕАКЦИИ, потому что, насколько я правильно понял Вы сами написали адрес отправителя, но не адрес отправки. Поэтому мы брем любой SMTP сервак, все письма помечаем (mail From:) ну например с @mail.ru и если адрес отправки не числится в RBL спам спокойно проникает в систему. Для создания SMTP рилея домен не нужен. Я имел ввиду именно адрес отправки.

Плох не тот кто упал, а кто упав не захотел подняться.

Дилер

Регистрация: 09-Июл-05
Местонахождение: Russian Federation
Статус: Offline
Количество сообщений: 172

Check :

Я же помоему очень понятно написал. 🙂

Плох не тот кто упал, а кто упав не захотел подняться.

Дилер

Регистрация: 09-Июл-05
Местонахождение: Russian Federation
Статус: Offline
Количество сообщений: 172

220 Traffic Inspector SMTP Gate, ver. 1.1.4.197, ready at Sat, 26 May 2007 19:18
:08 +0400
HELO mf1.mail.ru
250 B-SERVER Hello [ 192.168.222.22 ]
mail from^ 1CExchange
500 5.5.1 Unrecognized command
mail from: 1CExchange2006_7 @mail.ru
250 Sender OK
rcpt to: Eugeniy@bals.ru
250 Recipient OK
data
354 Start mail input; end with .
Vot i prolez ugastniy spam.
.
250 Queued mail for delivery

Ну и где же наша оборона. Все полностью набирал со своего локального компа. Галочка про которую вы сказали включена. Еще что нить нужно объяснять? Я имею ввиду проверку адреса который выделен красным по следующей методике: если домен «живой» а не левый то можно сделать обратный поиск в DNS, который сразу же определит, что адрес 192.168.222.22 совсем не тот, за кого себя выдает, со всеми вытекающими последствиями, не нужно такие адреса резать, просто нужно «добавить весу», возможно в теме проскользнет слово Куплю или еще что нить в этом роде и вес станет слишком большим 🙂
Name: mf1.mail.ru
Address: 194.67.23.217

Можно еще проанализировать: доменный уровень -1 [mf1.]mail.ru будет mail.ru, далее просматриваем зону и видим, что там например нет MX записи mf1 — еще весу! После такой элементарной проверки «детский» спам просто отдыхает. Неужели это сложно сотворить? Согласен на то, что проверка письма будет идти дольше, но гигабайты говна стоят дороже времени потраченного на обработку нежелательной почты.

Плох не тот кто упал, а кто упав не захотел подняться.

Expert

Регистрация: 27-Май-04
Местонахождение: Russian Federation
Статус: Offline
Количество сообщений: 580

и после такой проверки определенный и совсем не малый процент легальной почты тебе доходить не будет.

В корпоративной среде использование спаморезалок вообще вещь опасная и может поставить под удар бизнес-процессы. То есть, использовать их нужно КРАЙНЕ осторожно. Потому что если вдруг от кого-то из ваших партнёров вам перестанет ходить почта (потому что они вдруг оказались в каком-либо DNSBL), вас по голове не погладят.

Дилер

Регистрация: 09-Июл-05
Местонахождение: Russian Federation
Статус: Offline
Количество сообщений: 172

Bear :

после такой проверки определенный и совсем не малый процент легальной почты тебе доходить не будет.

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

Анализ статистики отклонения запросов показал — нормальные пользователи используют «НОРМАЛЬНЫЕ» домены для отсылки писем: yandex.ru, mail.ru, yahoo.ru, rambler.ru, либо свои собственные. Спамеры же для рассылки сообщений используют «левые» чаще всего динамические адреса, которые непринадлежат ни одному из доменов, которыми они в настоящий момент прикрываются в запросе Mail from: основная задача определить: действительно ли тебе пришло письмо от указанных доменов или им только прикрылись.

Кроме того, если партнер желает, чтобы его письмо дошло, то отсылать он его будет с «нормального» домена и IP адреса, числящегося в зоне этого домена.
Кто Вам мешает занести нормальные почтовые домены в список белых адресов, и присвоить им весовой коэффициент например
«-100»? Во всех вышеперечисленных доменах есть защита от рассылки спама через них, например mail.ru после третьего отосланного письма просит ввести цифро-буквенный код с картинки.

Фактически этот механизм лишь дополняет службу RBL, а использовать его или нет право всегда остается за администратором.

Ну если партнеры отсылают почту с «сомнительных» адресов, так возможно и не стоит с ними работать?
OFF:
Анекдот: Речевое приветствие на местной АТС «Вас приветствует фирма Мракбракзагранпоставка! Наберите номер внутреннего абонента в тональном режиме. Если Ваш телефон не поддерживает тонального набора, то положите трубку. как клиент Вы нас не интересуете. »

Плох не тот кто упал, а кто упав не захотел подняться.

Как настроить почтовый сервер для обхода спам-фильтров: руководство по DNS, SPF, DKIM

Содержание статьи

Кто отправляет письма

Сегодня возможность привязать свой домен к сервису предлагают многие веб-службы. Особо популярно размещение почты на Gmail или Яндексе. Все сообщения будут идти через предоставленный ими SMTP-сервер, проверенный поставщик услуг сам сформирует все необходимые заголовки и подписи, которые позволят пройти через любой спам-фильтр. Но такой вариант не всегда возможен. Например, организация имеет большое количество пользователей, нужны особые настройки для почты, недоступные в облачных сервисах. Или используется свой сервер с порталом, CMS или интернет-магазин, с которых нужно отправлять сообщения.

По умолчанию все PHP-приложения используют для отправки почты функцию mail() , которая, в свою очередь, отправляет их через локальный SMTP-сервер, описанный в php.ini .

Или в виртуальном хосте:

И хотя там в 100% случаев написан sendmail, на самом деле это может быть симлинк, а почту отсылает Postfix или Exim. Чтобы отправить почту из приложения, можно выбрать один из трех вариантов:

Сам движок иногда позволяет указать внешний SMTP-сервер (в дефолтных настройках или через плагин, в WordPress это WP Mail SMTP или Easy WP SMTP). Достаточно просто указать данные аккаунта, и все проблемы решены.
Использование программы-прокладки, которая эмулирует работу локального SMTP-сервера и отправляет сообщения через почтовый аккаунт на стороннем сервере. Здесь очень популярна SSMTP.
Использование своего почтового сервера. Придется, конечно, его настроить, зато больше возможностей конфигурации.

Нас интересует последний вариант. Разберем, как пробиться через антиспам-технологии и гарантированно доставить получателю сообщение. Сами фильтровать спам не будем. Это тема другой статьи. В качестве подопытного SMTP-сервера выберем Postfix и Exim, они популярны на хостингах, просты и понятны в настройках, хотя основные вопросы будут касаться всех SMTP-серверов.

Как не попасть в спам

Борьба со спамом — это головная боль всех администраторов почты. Причем в последнее время актуальна как раз обратная сторона медали: спам-фильтры буквально зверствуют. Поэтому спам в приходящей почте практически отсутствует, но вот нормальные сообщения постоянно куда-то пропадают, клиенты и руководство нервничают, и приходится дополнительно убеждаться, что сообщение дошло до адресата. И после установки SMTP-сервера с большой вероятностью придется еще повозиться, чтобы сообщения вообще хоть куда-то доходили. В частности, чтобы оценить настройки, следует посмотреть, доставляются ли письма в ящики основных почтовых систем Gmail, Яндекс, Mail.Ru. Обычно на этом этапе появляются первые сложности, и приходится решать все проблемы персонально.

Читать еще: Разрешение доменное имя в ip адрес

Почтовые сервисы используют многоуровневую систему фильтрации спама, причем настолько серьезную и засекреченную, что о принципах не знает даже их собственная техподдержка. И у каждого сервиса свои приоритеты. Хотя обычно некая подсказка о причине недоставки содержится в ответном письме сервиса. Также в анализе причин помогает сервис mail-tester.com, достаточно отправить письмо на указанный там адрес и затем после анализа получить результат и перечень проблем. Некоторые из них можно проверить и решить, еще не настраивая SMTP-сервер.

Mail-tester.com — хорошее подспорье в поиске проблем

Борьба со спамом породила множество технологий. Самая старая из них — blacklist, в который заносятся все IP и домены, занимавшиеся рассылкой спама, сюда же могут попасть открытые релеи, прокси и Dialup-адреса, используемые для удаленного доступа (то есть они теоретически не должны рассылать почту). Организованы такие blacklist по-разному. Популярностью пользуются DNSBL (DNS blacklist) — черные списки в формате DNS, которые легко опрашивать. На сегодня доступно множество баз, не все они популярны и используются. Проблема в том, что списка для конкретного почтового сервиса нет, сколько и какие они опрашивают — это тайна.

Доменные имена, как и IP-адреса, сегодня могут быть «бэушными». Есть вероятность, что до тебя ими пользовался сервис рассылки сообщений или хост, размещенный на нем, был взломан и рассылал спам. Соответственно, они вполне могут попасть в какой-то из DNSBL и быть проблемой. Mail.Ru отбрасывал письма с одного IP именно из-за того, что тот находился в одном из таких полузабытых списков, попав туда в 2010 году. Причем Mail.Ru даже не утруждался проверять правильность SPF и DKIM. Дело сдвинулось, лишь когда IP убрали из блек-листа.

Проверить IP или домен можно самостоятельно, отослав DNS-запрос к выбранному DNSBL-серверу при помощи утилиты dig:

Но удобнее пользоваться онлайн-сервисами, проверяющими сразу в нескольких базах. IP можно проверить в dnsbl.info (59 баз) или whatismyipaddress.com (72 базы), домен, кроме того, — в mxtoolbox.com (107 баз), spamhaus.org или multirbl.valli.org. Если вдруг домен или IP окажется в списке, лучше сразу написать в поддержку и убрать свой адрес.

Прогоняем домен по DNSBL-базам

Правильная DNS

При получении сообщения удаленный SMTP-сервер анализирует прежде всего его заголовок. Почтовая программа отправляет только From, To, Date, Subject и X-Mailer. Они в общем понятны и просто указывают, от кого и куда слать. Остальной заголовок формируется как SMTP-сервером, так и приложением, его отправляющим. Это, кстати, тоже нужно учитывать, потому что письма, отправляемые через Telnet, могут уходить, а с Roundcube — нет, просто потому, что у них разный заголовок. Roundcube, например, подставляет свой HELO/EHLO на основании переменной server_name или localhost, если она не определена. Поэтому иногда нужно просто задать его явно:

То же касается и самописных PHP-скриптов.

При передаче письмо будет проходить минимум через два SMTP-сервера, каждый из которых тоже добавляет что-то от себя в заголовок. В первую очередь каждый сервер добавляет свой Received: from. Читать их лучше снизу вверх. Самое нижнее сообщение — это сервер отправителя, самый верхний — сервер получателя. Хотя на самом деле серверов может быть больше, особенно это актуально при работе с крупными провайдерами услуг, которые, приняв письмо, перебрасывают его дальше, или при использовании на пути SMTP-прокси. Для анализа пути сообщения можно использовать сервис от Google, который покажет в понятной форме все SMTP-серверы, время прохождения и тесты SPF, DKIM и DMARC (о них дальше).

Путь письма

Заголовки Received отличаются, хотя есть общие правила. Типичный выглядит так:

Здесь сообщение было получено с сервера, который называется server.example.org, имеет IP 1.2.3.4, в приветствии helo было использовано это же имя, получил его Exim 4.80.1 сервера st15.provider.com. Сообщение отправлено с mail@example.org. Приняв такой заголовок, SMTP-сервер начинает проверять данные. Пробивает домен и IP по базам DNSBL. Проверяет наличие MX-записи у домена. MX изначально используется для поиска почтовых серверов, обслуживающих данный домен, ее наличие подтверждает, что домен отправляет почту.

Дальше он производит обратное разрешение имени по IP через обратный DNS-запрос c помощью PTR-записи. То есть он узнает, сервер с каким именем должен быть по адресу, с которого пришло сообщение. Такое поведение было заложено в RFC 2505 от февраля 1999 года Anti-Spam Recommendations for SMTP MTAs. И хотя давно признано, что обратные зоны не являются достаточным условием для однозначного опознавания отправителя и часто приводят к ошибкам и задержкам, они все же поддерживаются. Поэтому они должны совпасть, иначе сообщение как минимум получит минус в рейтинге, а в худшем случае будет отброшено.

В нашем примере за IP 1.2.3.4 должен быть закреплен server.example.org. DNS-запись выглядит так:

Для IPv6 используется ip6.arpa. В принципе, знать об особенностях PTR необязательно, так как PTR, за редким исключением, настраивает только хостинг-провайдер. И если оно не устраивает, то нужно просто обратиться в поддержку. Проверить PTR можно при помощи запроса:

По факту PTR-запись после развертывания VDS может указывать на технический домен, представленный провайдером, вроде srv01.provider.net , в шаблоне VDS hostname вписан как Ubuntu1604 (меняется в /etc/hostname ), в HELO/EHLO SMTP-сервер пишет вообще localhost.localdomain , а письмо идет от домена example.org. Вероятность доставки письма при таких условиях будет стремительно приближаться к нулю. Хотя некоторые сервисы отмечают подобные несоответствия как ошибку и проводят полную проверку.

Особо хочется обратить внимание, что VDS обычно имеет два IPv4 и v6. Поэтому все сказанное касается обеих версий, так как письмо к одному серверу может идти по IPv4 и доставляться, а другой предпочитает использовать IPv6, и письмо может не доходить до получателя. При этом очень много провайдеров, предоставляя IPv6, абсолютно не утруждают себя настройкой PTR-записи, и ее проверка возвращает ошибку. Но Google, например, предпочитает IPv6 и сразу отбрасывает письмо, если PTR не совпадает с именем сервера. В ответном сообщении сервиса это выглядит так:

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Как не использовать «localhost.localdomain» в исходящем HELO/EHLO?

Я перепробовал почти все, что мог, и не могу заставить «localhost» выйти из моих заголовков email. Я оказался в списке CBL в Spamhaus, поэтому я пытаюсь исправить это, прежде чем подать заявку на удаление из списка.

У меня есть настройки DKIM, SPF, отправитель-ID auth. Проблема в том, что PHP или NGINX передает email в постфикс из localhost.

Я получаю эти заголовки «Received:», вставленные в исходящую почту:

Я думаю, что мне нужно очистить неизвестное и 127.0.0.1, а также localhost с именем пользователя nginx. Я бегу CentOS 6.3. Заранее спасибо за вашу помощь.

2 Ответа

Листинг CBL «localhost.localdomain»

Ваш хост был указан для имени «localhost.localdomain», которое он послал в команде helo/ehlo.

Вы можете исправить имя, используемое в исходящей команде helo/ehlo, используя одно из следующих действий:

изменение имени хоста в соответствии с сообщением hostname —fqdn
(FQDN = Полное Доменное Имя)
Это может быть OS/distribution dependent. Он исправляет подобные проблемы в большинстве MTAs.

опция smtp_helo_name в конфигурации postfix

Цитата со страницы CBL:

Этот адрес IP обозначается HELO ‘ как «localhost.localdomain», что нарушает соответствующие стандарты (в частности, RFC5321).
CBL не содержит списка для RFC нарушений как таковых. Однако это специфическое поведение сильно коррелирует с инфекциями спамботов. Другими словами, из тысяч и тысяч IP адресов HELO’, расположенных таким образом, все, кроме горстки, заражены и извергают мусор.

Я решил эту проблему путем:

Измените имя хоста непосредственно в постфиксной конфигурации:

Затем перезапустите postfix с sudo postfix reload

Debian, exim4. Настраиваем SMTP сервер для нашего веб-сервера

В данной статье я рассмотрю один из самых быстрых способов настройки smtp-демона для нашего вебсервера. Если вам нужен сервер, который ещё и должен принимать почту — проходите мимо. Эта статья подойдёт для тех, кто принимает почту гуглом или яндексом (на своём домене, само собой), но не хочет дергать их SMTP серверы, чтобы слать письма.

Внимание! Этот мануал описывает то, как настроить SMTP сервер (сервер отправки писем), отправить письмо через который можно только с того же сервера (то есть с localhost). При этом не будет требоваться никакой авторизации! Будьте внимательны.

Если необходимо настроить отправку почты с нашего сервера через почту для доменов от Яндекса.

Type Machine handling outgoing mail for this host (smarthost): smtp.yandex.ru:587

прописываем пароль для ящика в файле /etc/exim4/passwd.client:

Если почтовый сервер яндекс ругается, что нужно заполненное поле FROM. Прописываем его в файле /etc/exim4/conf.d/rewrite/00_exim4-config_header:

Теперь вы можете отправлять письма при помощи апача (чуть позже опишу как настроить) или командой вида echo «Testing Exim» | mail -s Test vlad@debian.pro

Ну и да — не стоит спамить 😉
Так же не используйте этот метод для тех случаев, когда доступ к серверу по ssh (или даже по ftp в каталоги, доступные по http) имеют доступ люди, которые могут начать спамить.

Как ограничить список ящиков, которым можно отправлять письма с сервера

Теперь создаём необходимые нам файлы:

В файл /etc/exim4/conf.d/router/01_exim4-outgoing-filter пишем правила, которые будут применяться к исходящей почте:

Если вы всё же выбрали «Split configuration into small files: no», то эти правила нужно вписать сразу после строчки

Это правило позволит отправлять только почту с любых ящиков доменов, которые перечислены в файле /etc/exim4/allowed.domains, или ящиков, перечисленных в файле /etc/exim4/allowed.mails. Обратите внимание на «или» — если домен написан в первом файле, то во втором смысле перечислять его ящики нет смысла. А если вам нужно разрешить отправку только с одного ящика домена — то не нужно писать его в allowed.domains, нужно написать конкретный ящик в allowed.mails

Ящики и домены нужно писать целиком (без регулярок, звездочек и прочего) по одному на строчку:

Проверить можно так:

где noreply@somepieceofshit.com — адрес отправителя, а youremail@adminunix.ru — адрес получателя.

В /var/log/exim4/mainlog в ответ на это вы увидите что-то в духе:

Как работают эти правила. Для начала стоит упомянуть, что у писем есть 2 важных заголовка — smtp.sender и header From:. smtp.sender, по сути, smtp-аккаунт, с которого происходит отправка письма. Поле From может содержать произвольную чушь, в том числе и совершенно левый ящик. Например, можно отправить письмо с smtp-аккаунта blah@someshit.com, но в поле From поставить admin@gmail.com. Чтобы посмотреть, кто реально отправил письмо — нужно будет лезть в его исходники. Большинство почтовых провайдеров при несовпадении этих полей кладёт такое письмо в спам. А спамеры, в свою очередь, шлют тонны писем с несовпадающими заголовками. Кхе.
Собственно, правило check_outgoing_from_header проверяет, чтобы в заголовке From содержалось имя smtp-аккаунта. Тут стоит упомянуть, что заголовок From: в нормальном письме выглядит примерно так — «inkvizitor68sl » (то есть помимо ящика содержит и имя/фамилию отправителя/ник или какую-нибудь другую чушь, которую он соизволит вписать туда). Именно поэтому, полагаться здесь на точное совпадение полей нельзя.

Второе правило (check_outgoing) проверяет, что значение поля sender (он же — smtp.sender, он же — smtp.name) подходит под одно из трех правил. Первое — sender пустой (сюда входят письма, сгенерированные самим почтовым сервером — например, отлупы о недоставке писем). Второе — sender совпадает с шаблоном *@любойдоменизспискаallowed.domains. Третье — поле sender целиком (пользователь@домен) указано в allowed.mails.

Так же учитывайте, что строчка в конфиге apache2 для вхоста вида:

выставляет значения поля sender в noreply@adminunix.ru (при том обойти это из самих скриптов уже не получится, только через htaccess). Поэтому, если ваша CMS шлет письма от ящика, отличного от указанного в этом месте — письма слать она перестанет.

Само собой, такая защита обходится (достаточно начать рассылать спам от «доверенных» ящиков) — авторизации всё ещё не требуется. Но мы можем в любой момент выключить ящик до того момента, пока не разберемся, что послужило источником спама на сервере.

В файле конфигурации php поправим sendmail_path.

В Debian: /etc/php5/apache2/php.ini или /etc/php4/apache2/php.ini

Правильная настройка SPF

Если кратко, то SPF — это способ борьбы со спамом.

Мы собираемся отправлять почту с сервера, PTR IP которого не равен одной из MX-записей сервера, а так же в большинстве случаев PTR IP не равен самому нашему домену (не всегда хостеры соглашаются менять PTR). В этом случае вероятность попадания писем в спам повышается. Но есть хороший способ ее понизить: указать правильно запись SPF нашего домена.

SPF-запись — это обыкновенная запись доменной зоны, имеющая тип TXT. Узнать текущее ее значение для домена можно с помощью команды host в Linux:

В данном примере SPF-запись не задана. Зададим ее. С моего домена почта может отправляться с серверов Gmail и с моего сервера. Для начала узнаем, какой PTR моего сайта (adminunix.ru):

IP-адрес моего сервера 93.174.6.118. Узнаем PTR:

Видно, что PTR IP, к которому привязан мой домен (IP моего сервера) — server.adminunix.ru.

v=spf1 — версия SPF (первая);
a — разрешение отправлять почту с IP, указанного в A-записи домена (собственно с сервера, на который ваш домен ссылается);
mx — разрешение отправлять почту с IP, указанных в MX-записях домена (в нашем случае сервера Gmail);
ptr — разрешение отправлять почту с IP, PTR-запись которых содержит ваш домен (т.е. сам домен и поддомены);
include:_spf.google.com — подключение разрешений для серверов отправки почту Gmail (совсем не обязательно почта будет слаться с серверов, указанных в MX-записи);

all — нейтральная реакция на всю остальную почту; здесь можно указать -all, что будет значить, что почта, не попадающая под эти правила, — спам.
Если вы хотите отправлять почту с сервера, не попадающего под все эти правила, его можно указать по IP или домену PTR, например:

v=spf1 a mx ptr ptr:example.com include:_spf.google.com

Запись указывается для вашего домена соответствующим образом, который определяет владелец DNS-сервера. Обычно сервером заведует хостер и предоставляет возможность вносить изменения в DNS-зоны через панель хостинга. Либо сам по запросу в саппорт меняет запись. В зональном файле должна появиться запись вида:

adminunix.ru. TXT v=spf1 a mx ptr include:_spf.google.com

После обновления зоны host выдаст следующее:

$ host -t TXT adminunix.ru
adminunix.ru TXT »v=spf1 a mx ptr include:_spf.google.com

После всей этой настройки функция mail () в PHP начнет слать почту через ваш локальный сервер на законных основаниях для антиспам-ботов. Но косяк будет в том, что в поле отправителя будет фигурировать адрес системного пользователя www-data@localdomain. Нас это не устраивает. Чтобы почта правильно слалась из mail (), необходимо использовать ее дополнительный параметр.

bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )

Именно $additional_parameters нас и интерисует. В него надо передавать реального отправителя:

mail ($to, $subject, $message, $additional_headers, $additional_parameters.» -frealsender@adminunix.ru»);

Указывается отправитель слитно с параметром -f.

Теперь отправленные через mail () письма будут абсолютно адекватны (при условии, что вы указываете все нужные SMTP-заголовки, вроде “FROM:”, “TO:” и т.д.).

А если несколько сайтов с разными IP (настройка Exim для отправки писем с разных IP)?

Читать еще: Txt записи домена

Мы хотим использовать локальный SMTP-сервер для отправки почты со всех сайтов на сервере. Никаких проблем нет, если настроен Exim правильно (см. выше). Но проблема появляется, если разные сайты работают на разных IP. Мы не хотим в почте «палить» то, что все наши сайты живут на одном сервере. Но Exim по умолчанию шлет всю почту с основного (первого) IP сетевого интерфейса, а этот IP всем получателям в SMTP-заголовках “Received:” письма. Кроме того, там указывается и имя сервера, которые мы в случае с разными сайтами на сервере выбрали нейтральными.

Чтобы не «палить» IP сервера, нужно отсылать письмо на удаленный сервер с IP, равного A-записи домена сайта. Делается это несложно путем изменения конфига Exim. Внесем изменения в настройки транспорта SMTP Exim. Если вы выбрали монолитный конфиг, то нужно отредактировать файл:

local_interfaces = a.a.a.a : b.b.b.b : c.c.c.c : d.d.d.d
smtp_active_hostname = $lsearch<$value>>
smtp_banner = «$smtp_active_hostname ESMTP $tod_full»

Находим в файле строку “remote_smtp:” (поиск в nano — F6). Добавляем в конец этого блока:

Это значит, что при отправке письма нужно определить домен отправителя почты (для sender@adminunix.ru это adminunix.ru) и отправить почту с IP, к которому этот домен привязан. Само собой разумеется, что домен должен быть привязан к серверу, где установлен Exim.

Так же нужно создать файл в любом месте файл привязки доменов к IP (у домена может быть несколько IP, так что просто lookup-ить его не прокатит). Я выбрал для файла место: /etc/exim4/domain2ip

Туда вводим наши домены по шаблону:

adminunix.ru: 123.123.123.123
vasya.ws: 123.123.123.124

Не забудьте дописать домен в файл в случае появления нового сайта.
Кстати, строку helo_data = «$sender_address_domain» можно добавить в файл даже если у вас один IP на все сайты. Тогда в команде HELLO SMTP-протокола (а, следовательно, и в заголовках писем) будет фигурировать ваш домен.

Идея с указанием интерфейса взята отсюда: http://www.directadmin.com/forum/showthread.php?t=36468

Остается проверить, чтобы все ваши настройки работали верно. Для этого просто отправим письмо с локального сервера через консоль.

$ mail -a «From:feedbee@adminunix.ru» -s Test feedbee@gmail.com — -ffeedbee@adminunix.ru
Test
Cc:

Проверяем отосланное письмо в ящике получателя:

А вот текст SMTP-протокола:

P.S. Чтобы отправленная почта не попадала в спам, отправляйте письма только от имени реально существующих на серверах Gmail адресов на ваших доменах. Туда же повалятся уведомления о недоставках.

Чтобы при отправке писем root’у, как это любят делать многие утилиты (например smartd), письмо уходило не на root@example.org, а на admin@adminunix.ru. Я изменил /etc/aliases:

В файл /etc/exim4/conf.d/rewrite/00_exim4-config_header пишем правила,

А для затирания Received из заголовков писем с ip серверов которые коннектятся к нашему почтовику надо добавить вот эту строчку:

Домен для helo

Прячем имя внутреннего почтового сервера

Иногда может возникнуть необходимость изменить данные, заполняемые нашим почтовиком в заголовке письма. Чаще всего это HELO/EHLO, каноническое имя хоста.
Также может возникнуть необходимость скрыть имя внутренного почтового сервера в исходящей почте, заменив его на имя внешнего почтового сервера (шлюза) mail.domain.ru.

Во-первых, имя почтового сервера «выдает с потрохами» внутренний макрос sendmail’a — макрос $j.
( «. «Официальное» доменное имя для этого узла. Оно полностью уточнено, если может быть найдена полная квалификация.(т.е. команда hostname -f должна выдавать полное доменное имя) Оно должно быть переопределено, чтобы быть полностью уточненным доменным именем, если ваша система не сконфигурирована таким образом, что может найти его автоматически. )»

Другими словами, $j — это полностью разрешенное имя хоста, которое определяется следующим образом: сначала вызывается команда gethostname, которая дает имя хоста, это имя хоста затем передается команде gethostbyname, которое должно вернуть каноническое имя хоста (см. op.me).
$j — полностью определенное имя хоста (FQDN — fully qualified domain name).
«It is unwise to try to change this» — http://www.sendmail.org/m4/README.txt

Теперь посмотрим на заголовок письма. У меня нет внешних и внутренних серверов, но я могу привести пример письма, пришедшего с моего mx-a с большим весом на основной mx. Правда, для того, чтобы воспринимать этот заголовок в нужном контексте, мысленно перевернем последовательность продвижения письма и вообразим, что первый mx, на который пришло письмо — это внутренний почтовик, с которого письмо ушло на внешний сервер, а основной mx — внешний сервер, отправляющий письмо с нутреннего почтовика в мир.
А 213.60.13.146 — адрес моего почтового клиента (хотя на самом деле, это какой-то злобный спамер).
Если ничего не понятно, то считайте просто, что apache.anrb.ru — это внутренний сервер, а mail.anrb.ru — внешний, и все 🙂

Заполнено внешним почтовиком:
Return-Path:
Received: from apache.anrb.ru (www.anrb.ru [212.193.134.3])
здесь: apache.anrb.ru — HELO, указанное внутренним сервером во время SMTP-сессии,
то есть, открывая smtp-сеанс, внутренний почтовик сказал HELO apache.anrb.ru
www.anrb.ru — имя внутреннего почтовика, определенное по PTR-записи ip-адреса 212.193.134.3 в обратной зоне;
[212.193.134.3] — ip-адрес внутреннего почтовика;
by mail.anrb.ru (8.14.2/8.14.2) with ESMTP id m0Q6E6wP024784
for ; Sat, 26 Jan 2008 11:14:06 +0500

Заполнено внутренним почтовиком:
Received: from [213.60.13.146] ([213.60.13.146])
213.60.13.146 — якобы мой пользователь
by apache.anrb.ru (8.14.2/8.14.2) with ESMTP id m0Q5rP89011675
apache.anrb.ru — значение макроса $j, указанного явно (см. ниже)
for ; Sat, 26 Jan 2008 10:53:29 +0500

Макрос $j по умолчанию упоминается в следующих местах.
I. В приветствии внутреннего почтового сервера (к заголовку письма это не имеет никакого отношения): в стандартной конфигурации макрос $j вставляется в в приветствие по умолчанию, обнародуя таким образом имя почтовика.
II. В подзаголовке Received:, который заполняет внешний сервер, а именно
в HELO/EHLO, которым поздоровался внутрений сервер (макрос $s- имя хоста отправителя, выставляется из флага командной строки -p или кодом сервера SMTP), для HELO/EHLO по умолчанию он также использует макрос $j;
III. В подзаголовке Received:, который заполняет внутренний сервер, внутренний макрос $j указывается явно.

Во-вторых, внутренний почтовый сервер засвечивается и во внутреннем макросе $_ (подтвержденный адрес отправителя, состоит из доменного имени и ip-адреса релея отправителя —
$&[$&])

Итак, если мы сумеем повлиять на макросы $j и $_ , то задачу мы решим.

Но для начала рассмотрим неявные способы воздействия.

1. Сначала разберемся с приветствием. В стандартном конфиге приветствие имеет вид:
SmtpGreetingMessage=$j Sendmail $v/$Z; $b
Как видите, и здесь упоминается макрос $j.

1.1. Можно его иключить из заголовка, заменив его на другое доменное имя.
Для этого необходимо добавить в sendmail.mc:
define(`confSMTP_LOGIN_MSG’, `mail.domain.ru; Sendmail $v/$Z; $b;’)

README:
confSMTP_LOGIN_MSG SmtpGreetingMessage
[$j Sendmail $v/$Z; $b]
The initial (spontaneous) SMTP greeting message. The word «ESMTP» will be inserted between the first and second words to convince other sendmails to try to speak ESMTP.

1.2. Можно самостоятельно задать доменное имя, используя опцию
define(`confDOMAIN_NAME’, `mail.domain.ru’) на внутреннем почтовике.
Это позволит заменить макрос $j в
— приветствии,
— Received: внутреннего сервера (явный $j),
— Received: внешнего сервера (HELO/EHLO внутреннего).

Подчеркну: оба способа не изменяют содержание макроса $j, а просто заменяют макрос на указанный домен.

2. Теперь разберемся с подзаголовком Received.
2.1. Как я только что сказала, опция define(`confDOMAIN_NAME’, `mail.domain.ru’) с успехом справится с именем внутреннего почтовика в пп.I и II.

2.2. Однако существует еще другая возможность.
2.2.1.За формат подзаголовка Received: отвечает опция confRECEIVED_HEADER, и в стандартной конфигурации он имеет вид:
Received: [$?sfrom $s $.$?_($?s$|from $.$_)
$.$?(authenticated)
$.by $j ($v/$Z)$?r with $r$. id $i$?u
for $u; $|; $.$b]

Этот заголовок можно переписать, заменив $j на mail.domain.ru.
Вариант особо немногословного заголовка для внутреннего почтовика:
define (`confRECEIVED_HEADER’,`id $i; $b’) —
здесь обозначены лишь идентификационный номер письма в очереди и дата, и нет канонического имени хоста.

2.2.2. А для изменения HELO/EHLO, которым здоровается внутренний почтовик, и который внешний почтовик записывает в свой Received, начиная с версии 8.14.0 можно использовать опцию:
confHELO_NAME HeloName If defined, use as name for EHLO/HELO command (instead of $j).
Эта опция д.б. прописана в конфиге внутреннего сервера, она позволит изменить его HELO по своему уразумению.
Для младших версий подействовать на HELO напрямую невозможно.

Вот вы теперь скажете, зачем городить весь этот огород, если можно повлиять на макрос $j.

Еще раз вернусь к его определению:
Значение макроса $j определяется вызовом gethostname для получения текущего hostname, с последующей передачей его в gethostbyname, который должен вернуть каноническую версию имени хоста. Если все прошло успешно, то в $j выставляется полностью определенное имя.
Проще говоря, при наличии у хоста полного доменного имени, определяемого командой hostname -f, именно это значение и будет выставлено в макрос $j.

0 0 голоса

Рейтинг статьи

Домен для helo

Спам-фильтр проверка домена в HELO, EHLO

Как настроить почтовый сервер для обхода спам-фильтров: руководство по DNS, SPF, DKIM

Содержание статьи

Кто отправляет письма

Как не попасть в спам

Правильная DNS

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Как не использовать «localhost.localdomain» в исходящем HELO/EHLO?

2 Ответа

Листинг CBL «localhost.localdomain»

Похожие вопросы:

Debian, exim4. Настраиваем SMTP сервер для нашего веб-сервера

Правильная настройка SPF

Домен для helo