Comments 73
Какая-то жуткая каша. Я понимаю, что программисты не сисадмины, но по вопросам настройки почтовых серверов столько написано, что это читать очень странно (всё в кучу, без объяснения куда к чему и т.д.).

И уж при чём тут bind9 совсем не понятно.
Старался как мог.

Вообще идея была в том, что бы собрать все в одно. Просто вот такого полного описания нет, приходилось собирать отовсюду по каждому проблемному заголовку.
Просто неправильный подход. Правильно поставленная задача звучит так:
Нужно, чтобы почта проходила нормально -> нужен нормальный почтовый сервер -> google
Предлагаете от функции mail() отказаться вообще и всё посылать через бот-аккаунт по SMTP, переписав все возможные скрипты?
Это не всегда выход.
На самом деле «обычному программисту» нужно ещё осознать тот факт, что реальная работоспособность его программы зависит от внешних условий, причём большей частью не от хоть как-то контролируемых на хосте типа mysql или memcache, а от настроек сервисов «третьих лиц» и одного соблюдения RFC821/822 не достаточно, чтобы письма успешно доходили до получателя. Я вот настроил на VDS postfix — письма уходят с него и приходят на мой gmail ящик, правда в спам попадают.

Относил на то, что предыдущий «владелец» IP спамом занимался и попал в чёрные списки, или вся подсеть даже. А о том, что это из-за несоответствия результатов реверс-резолвинга IP и резолвинга полей типа Return-Path и From даже мысль в голову не приходила. Ну не занимался я никогда настройкой или, тем более, разработкой систем защиты от спама и способами их преодолеть. А по мотивам поста настроил реверс (хотя не мало гуглить пришлось) и теперь письма в спам не уходят. Ещё нужно с spf разобраться, потому что у знакомого таки-уходят, видимо потому что он не жал 100500 раз на письма с моего хоста «Не спам».
Вообще gmail в основном относит к спаму письма без DKIM, попробуйте подписывать письма.

По мне это ключевой момент с Gmail.
Чушь. У меня куча почтовых доменов — и ни один из них не имеет DKIM. И всё отлично работает.

А вот если у письма message-id нет (и оно генерируется релеем гугля) — то это прямой путь в каталог спама.
Тем не менне вес проверки по DKIM у него выше, чем SPF и проверки по reverse DNS. Так что я бы советовал его всегда использовать.
Забыли в заголовке темы написать для какого почтового сервера, по статье уже стало понятно что для postfix, но тем не менее, надо знать какой сервер тут описывается до прочтения статьи
Идея правильная, я дописал во вступлении одно предложение для удобства.
dkim настраивается за 15 минут человеком без опыта администрирования линукс систем, по мануалам, доступным в гугле. там всего лишь надо добавить одну запись в днс и одно правило в конфиг сервера (у меня эксим), ну и сгенерировать ключи.
Зря минусуете. Для экзима это действительноиочень просто. Сам недавно через этот процесс прошел.
Ох уж эти названия статей. У статей с подобным названием лучше сразу в комментарии заглядывать, по ним видно, соответствует содержание названию или нет.
Я так и делаю:
Читаю комментарии -> читаю статью ->переобдумываю комментарии -> (возможно) отвечаю
Вступление (до ката) заинтриговало (тем более задача такая стоит где-то в тудузах), преамбула понравилась, а вот дальше, начиная с «Каких целей в заголовках нам требуется достичь?» включительно…

Может настройка и грамотная, но ни капли не понятная. Со второго прочтения понял, что цель основная это формирование заголовков, благодаря которым письмо пропустят спам-фильтры. С третьего понял, что это в основном заголовки не исходящие, а те, с которыми письмо попадёт в ящик пользователя (или не попадёт). В общем даже «Дано» (например, отправка письма из PHP-скрипта по адресу wartur.ru/index.php с помощью mail() ) и «Требуется» (например, письмо не должно попасть под спам-фильтры) не сформулированы толком. С k-wartur.wartur.ru вообще не понятно что такое.

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

Еще раз, для меня не очевидно было почему раз, два и мои письма попадали в спам. И если будут идеи как по другому назвать статью, то тоже в студию, потому что я наверняка не прав, просто я так представляю эту проблему именно с точки входа функции main(), кончая пришедшим письмом на ящик пользователя с наименьший вероятностью попадания в спам.
Мен ваш пост инициировал на гугление и нашёл, в частности, forum.ixbt.com/topic.cgi?id=7:26978 — не то, что как работает механизм фильтрации, а что должно получиться, чтоб его проходить без потерь. Основная цель-то в этом, а не в том, какие заголовки должны быть.

В любом случае, спасибо, что помогли осознать проблему.

Жуть какая то.

У меня почему то вся настройка укладывается в
apt-get install sendmail

Этого вполне достаточно, чтобы отправлять сообщения о заказах и прочих мелочей. Sendmail Запускается на 127.0.0.1:25, с безопасностью проблем нет.

А у MODX Revolution, с которым я работаю, вообще прямо в админке прописываются настройки smtp сервера для отправки всей почты сайта. Все скрипты используют эти настройки — даже sendmail не нужен.

В общем, спасибо, конечно за статью, но жаль ваше время.

Не забываем про spf, ptr, helo, return-path и dkim, эти вещи я главным образом и опысывал, а сам я MTA на прием и спам фильтры устанавливать не умею, ибо я сам пользуюсь службами google. Я всю статью привязывал к тому моменту, что все это будет юзаться скриптами и только на отправки с сервера, а прием будет осуществляться на что-нибудь более современное.

> Все скрипты используют эти настройки — даже sendmail не нужен.
ну я же написал, что лучше пользоваться встроенным, чем внешними либами, которые самостоятельно через ботов могут соединяться, такой подход не подходит если у вас сервис более менее загружен и вы отправляете по письму в секунду, а не раз в день, или даже раз в минуту. Не говоря о том, что это все тормозит если вы эту либо не через крон прослойку запускаете.

Надеюсь немного пояснил.
Да зачем spf, ptr, helo, return-path и dkim для тупой отправки писем с сервера??? Для отправки не нужно ничего кроме МТА. Письмо же отправляет он?

Эти плюшки нужны для доверия к отправленным письмам со стороны других серверов.

Но если сайт отправляет письма от имени и ip реального домена, и с обратной зоной все окей — доверие и так будет. Не нужны такие сложности для отправки забытого пароля или информации о заказе.
>Да зачем ...ptr… для тупой отправки писем с сервера???

>и с обратной зоной все окей — доверие и так будет

Так надо или не надо? Зря я по прочтению статьи настроил обратную зону или нет?
PTR — крайне желательно, если ваш хостер позволяет.

Ну и статья то называется «Грамотная настройка сервера отправки почты для скриптов». Вот я и недоумеваю, почему у меня вся настройка сервера сводится к установке sendmail?
Позволяет и уже резолвится, просто не думал, что это важно.

Ну да, название неудачное.
При приеме почты чужой сервер смотрит, от какого домена она идет. А потом проверяет для этого домена ip и сверяет с вашим. Если совпадает — то это черный спам (коего 95% среди писем).

Если не совпадает — сразу подозрение. Зачем отправитель представляется чужим доменом?

И тут уже все зависит от политики сервера. Кто то дает отлуп, кто-то помечает как спам, а кто-то вообще не проверяет PTR.
Это очень важно. Я вот на своих серверах обязательно это проверяю. И тут причина банальная. Огромное количество хостов в сети заражено. Это просто тачки юзеров и сами юзера не знают, что с их машин идет поток спама. Идти-то он идет, но PTR-ов у этих хостов на доменное имя с которого идет рассылка понятное дело нет. И все, можно от такого хоста не то, что письмо принимать, можно его соединение с ним сразу сбрасывать и не занимать ресурсы сервера на получение письма. Поскольку это происходит на фазе установления соединения, все отрабатывается очень быстро особенно если еще обзавестись локальным кэширующим DNS.
PTR — это одна из основных вещей. Некоторые сервера вообще отказываются принимать почту (не то что в спам фолдер) если PTR нет.
Вот статья дала мне повод его настроить. Уже автор время не зря потратил.
Проблема не в том, чтобы их отправлять, а в том, чтобы они попадали в ящик адресата и, желательно, не в «спам», а во «входящие». Основное решение проблемы лежит в области настройки DNS, а не MTA. Если, конечно, вы хотите отправлять почту от своего имени и минимизировать вероятность того, что ваши пользователи воспримут серьезно, письма отправленные от вашего имени, которые вы не отправляли.
Массовая почтовая рассылка через Exim или как не попасть в спам.

И от себя немного — почему просто так желательно не отправлять

$result = mail('yourmail@domain.ru', 'subject', 'message');


Например, если будет всё русскими буквами, то некоторые почтовые сервера не поймут какая кодировка. Для тела письма — в заголовках можно передать utf-8, а для сабжекта и to нужно добавить в само поле обозначение кодировки.

Вобщем, у меня приблизительно так выглядит это:

mail("=?utf-8?B?".base64_encode($to_name)."?= <$to_mail>",
"=?utf-8?B?".base64_encode($topic)."?=",
chunk_split(base64_encode($message)),
"From: =?utf-8?B?".base64_encode($from_name)."?= <$from_mail>\n
Content-Type: text/html; charset=utf-8\n
Content-Transfer-Encoding: base64\n
Content-Disposition: inline\nMIME-Version: 1.0");


Думаю, что phpmailer всё это учитывает.
Что верно то верно, здесь автор рекомендует использовать mail(), когда все же лучше использовать phpmailer в качестве оболочки над mail(), передав ей весь головняк с заголовками. Да и такой вопрос, как например, приаттачить файлик перестанет быть вопросом.
Хозяйке на заметку:

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

Если сайт расположен по адресу domain.com и отправляет письмо для admin@domain.com, но при этом MX запись сервера указывает на smtp.yandex.ru — то письмо наверняка не дойдет.

Это оттого, что МТА посмотрит на имя домена, увидит, что это он сам и попытается доставить письмо локально. А юзера такого в системе наверняка не будет, а если и будет — то за почтой он ходит на реальный сервер (в нашем случае — на mail.domain.com, который обслуживает yandex)

То есть, МТА обычно не узнает МХ запись для локального домена и такое письмо не доставит. При этом, письма на другие домены уйдут без проблем.

Решение для Sendmail:
nano /etc/mail/sendmail.mc

В конце дописываем (example.com меняем на свой домен, на котором висит сайт):
define(`MAIL_HUB', `example.com.')dnl
define(`LOCAL_RELAY', `example.com.')dnl

Сохраняем и запускаем команды:
sendmailconfig
service sendmail restart


Проблем а должна исчежнуть. Для других МТА придется погуглить самостоятельно.
Протестить вот так:
echo -e "To: user\nSubject: Test\nTest\n" | sendmail -bm -t -v


Вы должны увидеть что-то типа того:
>>> MAIL From:<bezumkin@domain.com> SIZE=30 AUTH=bezumkin@domain.com
250 2.1.0 <bezumkin@domain.com>... Sender ok
>>> RCPT To:<admin@domain.com>
>>> DATA
250 2.1.5 <admin@domain.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
050 <admin@domain.com>... Connecting to mx.yandex.ru. via relay...
050 220 mxfront31.mail.yandex.net (Want to use Yandex.Mail for your domain? Visit http://pdd.yandex.ru)
.......
Это оттого, что МТА посмотрит на имя домена, увидит, что это он сам и попытается доставить письмо локально. А юзера такого в системе наверняка не будет, а если и будет — то за почтой он ходит на реальный сервер (в нашем случае — на mail.domain.com, который обслуживает yandex)
То есть, МТА обычно не узнает МХ запись для локального домена и такое письмо не доставит. При этом, письма на другие домены уйдут без проблем.

Вообще, неработающая локальная доставка — это самая первостепенная проблема любого кривонастроенного почтового сервера. :)) К какому-либо конкретному MTA это отношения не имеет.
Локальная доставка — работает.
Доставка на чужие домены — работает.

Проблема возникает если почта вынесена на mail.domain.com, а отправить письмо пытается сайт с domain.com. Он не проверяет для себя самого МХ запись и сам себе доставляет письмо. Но реальная-то почта на другом сервере.

Это дефолтный конфиг, а не кривая настройка. Не уверен, что вообще существуют МТА, из коробки резолвящие МХ запись для самого себя.
Он не проверяет для себя самого МХ запись и сам себе доставляет письмо. Но реальная-то почта на другом сервере.

Вы похоже путаете домены и хостнеймы («A» запись в DNS) с адресом почтового сервера («MX» запись в DNS).
Если какой-то домен/субдомен прописан как локальный (по сути MTA всегда сначала смотрит в список локальных доменов, прежде чем пытаться резолвить MX запись через DNS), то, естественно, почта никуда за пределы сервера не уйдёт, что совершенно логично. Допустим, если ваш веб-сервер имеет системный хостнейм example.com, при том он же прописан в локальных доменах у MTA (работающем только на локальную доставку и отправку вовне) на этом же сервере, то наивно надеяться, что доставка почты будет работать корректно.
Решение же заключается в том, чтобы не использовать example.com в качестве хостнейма (как системного, так и в MTA, хотя, полагаю, можно ограничиться и только MTA), если приём почты для домена example.com обслуживает другой сервер.
Отличное решение!

И что же тогда использовать? Приведите примеры, какие имена нужно использовать для сайта и почтовых ящиков? Я так понимаю, разные?
Почтовые ящики тут не при чём вообще. А хостнейм можете поставить например www.example.com или какой угодно другой субдомен (pupkin.example.com), лишь бы он был.
>> Почтовые ящики тут не при чём вообще

Вот так открытие!!!

А как, по вашему мнению, почтовый сервер решает, на какой домен доставлять почту?
Уж не по домену ли после символа @?

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

у вас видимо нет соответствующей записи в DNS
хотя если веб-сервер всё же отвечает, но выдаёт что-то левое — то копайте в сторону хостнеймов у виртуального хоста вашего веб-сервера
не похоже что-то :))
В любом случае, меня не устраивает, что сайт открывается с www, а без www — не открывается.
UFO landed and left these words here
Я наоборот включаю. Не думаю, что найдётся так много случаев, когда домены для локальной доставки отличаются от хостнейма.
Еще раз.

Домен bezumkin.ru
Сайт bezumkin.ru, без www. Любой несуществующий поддомен открывает основной сайт.
Ящик ya@bezumkin.ru
Почту обслуживает Яндекс — МХ запись — mx.yandex.ru

С сайта от имени no_reply@bezumkin.ru отправляется письмо на ya@bezumkin.ru

По умолчанию, МТА на сервере bezumkin.ru просто переложит почту в директорию mail юзера ya на сервере bezumkin.ru (если он там есть).

МТА не спросит, какой сервер отвечает за почту домена bezumkin.ru (а это — yandex).

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

Варианты открывать сайт по имени www.bezumkin.ru или bezumkin2.ru меня не устраивают. Ящики с именами @mail.bezumkin.ru тоже не нужны.
По умолчанию, МТА на сервере bezumkin.ru просто переложит почту в директорию mail юзера ya на сервере bezumkin.ru (если он там есть).

И кто мешает настроить наконец как надо? Список локальных доменов, который предшествует резолвингу любого MX, опять же… Естественно, ни в одном MTA по умолчанию это не предусматривается.
Ну так я и описал проблему и решение.

Это вы выступили с разоблачением:
>> Вообще, неработающая локальная доставка — это самая первостепенная проблема любого кривонастроенного почтового сервера. :))

Хотя речь шла о проблеме доставки нелокальной как раз.
Я вроде бы уже объяснил достаточно подробно про любую доставку. Убираете example.com из списка локальных доменов на сервере отправителя — почта для домена example.com будет отправляться вовне.
В порядке убывания важности, настройки аутентичности почтового сервера выглядеть должны примерно так:
— SPF запись
— обратная запись
— DKIM-подпись контента

Акцент на PTR делается у криворуких, наподобие мейлру, не учитывающих, что далеко не всегда эту запись можно поменять.
Согласен. Но еще добавлю что From и Return-Path тоже хотелось бы видеть осмысленным, а не что-нибудь вроде этого: your_hosting_account@hosting_domine.domine
Артемий Лебедев умывается кровавыми слезами, глядя на креативную картинку из этого поста.
Его душевные страдания в этом посте не интересуют никого. Не кружок дизайнеров собрался.
Вы правда думаете что я призываю его пожалеть?
Просто мне кажется, что чем бы человек не занимался, будь то оформление поста на хабре, или скажем написание софта под андроид, он либо старается сделать хорошо, либо получается говно. Хорошие посты обычно хорошо оформлены.
«Не кружок дизайнеров собрался.» — Это были ключевые слова.
Оформлена статья нормально, а на то, как сделана картинка, уверен, что большинству плевать.
Мое имя — не Артемий.
Но когда я вижу 100-килобайтную картинку такого размера — глаза увлажняются, и комок к горлу подступает.
mydestination — если я не ошибаюсь, это задает те домены с которых MTA будет принимать почту на обработку, если у вас виртуальный хостинг (что я устроил на сервере дома), то без _ALL_ у вас будут проблемы с отправкой почты с других доменов кроме указанных.

Неверно. Вы доки по Postfix хоть раз читали или всё изучали исключительно наугад?
Открываем Postfix configuration paramters — mydestination, читаем:
The list of domains that are delivered via the $local_transport mail delivery transport. By default this is the Postfix local(8) delivery agent which looks up all recipients in /etc/passwd and /etc/aliases. The SMTP server validates recipient addresses with $local_recipient_maps and rejects non-existent recipients.

Т.е. если резюмировать по-русски: mydestination задаёт домены/хостнеймы для которых доставка почты будет выполняться исключительно локально (в пределах текущего сервера), это строго необходимо, если вам не всё равно будет ли правильно работать доставка всевозможных системных оповещений. При этом получатели должны существовать в виде системных пользователей или системных алиасов. Обычно в этот параметр пишется имя хоста (то же, что и в /etc/hostname прописано) + localhost.
В случае же с почтовым сервером, обслуживающих много различных доменов/ящиков/алиасов, процедура настройки будет крайне отличаться, в зависимости от выбранной модели почтовых ящиков. Писать _ALL_ сюда в любом случае не стоит. Советую сперва прочитать про local_recipient_maps и virtual_mailbox_maps + virtual_mailbox_domains.
Круто, буду знать. Спасибо.
Я же сказал могу ошибаться, читал все броско и давно, а решал задачу исключительно отправки через скрипты PHP, все остальное меня в меньшей степени интересовало, так как остальное за меня решают умные парни из google и yandex.
А есть какая-нибудь статья по настройке sendmail на win системах с использованием gmail как основного сервера отправки? Сейчас у меня настроено, но как то криво, не знаю в чем проблема, но при отправке письма через mail() оно дублируется адресату и отправителю…
Почему задаю вопрос здесь, потому что в sendmaile не предусмотрена изначально работа с защищенными SMTP серверами…
Only those users with full accounts are able to leave comments. Log in, please.