Для нормальной работы сайта необходимо разрешить JavaScript, включая скрипты с доменов googlesyndication.com и doubleclick.net для отображения системы поиска по сайту и прочих сервисов Google.

Настройка sendmail и Postfix для правильной отправки электронной почты

logo

Настройка sendmail и Postfix для правильной отправки электронной почты Нужно отметить, что если настройка отправки почты выполняется на выделенном сервере, особое внимание нужно уделить имени хоста hostname, который аж никак не должен быть равен = localhost.localdomain, и в отправляемой почте не должно быть заголовков со значениями типа ???@localhost.localdomain, иначе такие письма будут улетать в каталог "Спам", а ИП адрес вашего сервера ссовременем попадёт в CBL (Composite Bloking List), а потом и в XBL (Exploits Block List).

Это условие важно соблюдать особенно тогда, когда 25-й порт открыт для внешнего мира. В CBL (Composite Bloking List) хосты попадают примерно по такой схеме: CBL сервис щупает 25-й порт вашего сервера (например: telnet smtp.mail.ru 2525), анализирует ответ "220 smtp46.i.mail.ru ESMTP ready" и если в нём находит localhost.localdomain, то ИП заноситься в CBL (Composite Bloking List), а после и в XBL (Exploits Block List).

Почта может не приходить по таким причинам как:

Final-Recipient: RFC822; ???????@list.ru
Action: failed
Status: 5.2.0
Remote-MTA: DNS; mxs.mail.ru
Diagnostic-Code: SMTP; 550 We cannot accept email from IP 94.249.240.244 without
a DNS PTR record. Contact your ISP/HSP to set up PTR record for your server.
Last-Attempt-Date: Sat, 17 Nov 2012 08:46:38 +0300
 
>>> DATA
<<< 550 We cannot accept email from IP 94.249.240.244 without a DNS PTR record.
Contact your ISP/HSP to set up PTR record for your server.
554 5.0.0 Service unavailable
... while talking to relay1.mail.zp.ua.:
>>> DATA
<<< 450 Client host rejected: cannot find your hostname, [94.249.240.244]
 
>>> DATA
<<< 550 We cannot accept email from IP 94.249.240.244 without a DNS PTR record.
Contact your ISP/HSP to set up PTR record for your server.
554 5.0.0 Service unavailable
... while talking to mxs.mail.ru.:
 
... while talking to mta6.am0.yahoodns.net.:
<<< 553 5.7.1 [BL21] Connections will not be accepted from 94.249.240.244, becau
se the ip is in Spamhaus's list; see http://postmaster.yahoo.com/550-bl23.html
... while talking to mta7.am0.yahoodns.net.:
<<< 553 5.7.1 [BL21] Connections will not be accepted from 94.249.240.244, becau
se the ip is in Spamhaus's list; see http://postmaster.yahoo.com/550-bl23.html
451 4.4.1 reply: read error from mta5.am0.yahoodns.net.

Заголовок "From: ...."

Желательно чтобы заголовок "From: ..." содержал почтовый адрес (ящик) из домена, с которого отправляется почта "Received: from ...", хотя это вовсе и не критично и не обязательно, главное чтобы у почтовиков принимающих нашу почту было доверие к нашему серверу с которого отправляется почта. Адрес отправителя "From: ..." устанавливается в настройках системы управления контентом CMS или же непосредственно в самой функции mail(); четвёртым параметром.

Заголовок "Return-Path: ..."

Обычно заголовок "Return-Path: ..." является важным заголовком в глазах почтовых сервисов. Установить его или в настройках php.ini, директива "sendmail_path = /usr/sbin/sendmail -t -i -f no-reply@remotehelp.pp.ua" - если есть пользовательский php.ini, а если нет, то непосредственно в самой функции mail(); пятым параметром. В противном случае заголовок "Return-Path: ..." будет равен примерно такому значению "Return-Path: <wrs@localhost.localdomain>". ОЧЕНЬ желательно чтобы значение заголовка "Return-Path: ..." всегда совпадало с именем домена с которого отправляется письмо, независимо от значения заголовка "From: ...", иначе оно может быть отправлено в "Спам" или же отклонено вовсе!


Если письмо отправляется от имени "From: ..." другого отправителя (домена) и не установлен "Reply-To: ...", то для ответа будет использоваться "Return-Path: ...". В CMS Joomla 1.5, заголовок "Reply-To: ..." устанавливается десятым параметром в функции JUtility::sendMail(); и по умолчанию при отправке ссылки другу по почте не используется в /components/com_mailto/controller.php, его нужно допиливать в ручную.

В почту отправляемую с аккаунта Gmail устанавливается только заголовок "Return-Path: ...", значение которого соответствует значению заголовка "From: ...", а также домену с которого оно отправлено, а по этому нет необходимости в добавлении заголовка "Reply-To: ...".

У Postfix и Sendmail разный подход к "Return-Path: ...". Так например в начале настройки Postfix, первое отправленное через него письмо пришло без заголовка "Return-Path: ..." (или то меня проглючило, ни-ни, перепроверил же - без Return-Path) и для его появления нужно было указывать адрес возврата явно при помощи " -f", Sendmail же вставляет заголовок "Return-Path: ..." автоматически собирая его из пользователь@mydomain.com, где "пользователь" имя пользователя от которого работает Apache/PHP, а mydomain.com обычно localhost или localhost.localdomain.

Sendmail не позволяет посторонним модифицировать заголовки при помощи -fвключительно и обнаружив такую модификацию вставляет в письмо заголовок X-Authentication-Warning с сообщением типа "X-Authentication-Warning: mydomain.com: username set sender to no-reply@mydomain.com using -f". Этого заголовка с предупреждением можно избежать, указав доверенных пользователей в vi /etc/mail/trusted-users

Если нужно использовать отличный от vi /etc/mail/trusted-users файл то добавьте в vi /etc/mail/sendmail.mc следующие строки:

FEATURE(`use_ct_file')
define(`confCT_FILE', `/etc/mail/trusted.list')
# или если файл не обязательно должен существовать
define(`confCT_FILE', `-o /etc/mail/trusted.list')

Пересоберите sendmail.cf из sendmail.mc: m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf, перезапустите sendmail.

Заголовки "Received: from ..." и "Received: by ..."

Значения заголовков "Received: from ..." и "Received: by ..." являются важными при определении уровня доверия к серверу отправляющему электронную почту. Настраивается в vi /etc/postfix/main.cf:

sh-4.1# vi /etc/postfix/main.cf
myhostname = remotehelp.pp.ua
mydomain = remotehelp.pp.ua
sh-4.1# service postfix restart

При этом имя домена желательно указать в SPF записи! Простым пользователям редактирование /etc/postfix/main.cf запрещено, это парафия администратора сервера и если он не указал myhostname явно, то в заголовках "Received: from ..." и "Received: by ..." будем иметь:

Received: from localhost.localdomain ([93.170.128.114])
 
Received: by localhost.localdomain (Postfix, from userid 502)
id 0512F44F13; Sun, 4 Nov 2012 13:48:22 +0400 (MSK)

Предупреждение "postfix/local[26184]: dict_nis_init: NIS domain name not set - NIS lookups disabled"

postconf | grep nis
alias_maps = hash:/etc/aliases, nis:mail.aliases
lmtp_sasl_mechanism_filter =
smtp_sasl_mechanism_filter =

NIS - это Network Information Services, а если NIS lookups disabled у нас не используется, то идём в vi /etc/postfix/main.cf, удаляем nis:mail.aliasesили снимаем комментарий с "#alias_maps = hash:/etc/aliases", а потом service postfix restart

В sendmail дела обстоят немного печальнее... Для установки хоста нам предлагают использовать так называемый cf/README - Masquerading And Relaying маскарад хостов, для чего в vi /etc/mail/sendmail.mc указываем MASQUERADE_AS(`example.com') домен, от имени которого будем слать почту, а в MASQUERADE_DOMAIN(`localhost.localdomain') имя домена, почта от которого должна будет замаскирована как MASQUERADE_AS(`example.com'). Но, весь этот маскарад полностью не решает поставленной задачи и в служебных заголовках мы продолжаем встречать строки:

Received: from mydomain.com (localhost.localdomain [127.0.0.1])
Received: (from user@localhost)

Где user имя пользователя в системе. В некоторых постах встречается совет добавить в vi /etc/hosts, перед "localhost localhost.localdomain" имя своего домена, вот так:

127.0.0.1 mydomain.com localhost localhost.localdomain localhost4 \
    localhost4.localdomain4
::1 localhost6 localhost6.localdomain6

Но этот фокус не канает и после такой правки vi /etc/hosts, мы получаем в письмах почти такие же служебные заголовки, только уже с добавкой "(may be forged)", что в переводе значит "возможно подделано":

Received: from mydomain.com (mydomain.com [127.0.0.1] (may be forged))
Received: (from user@localhost)

Так, что этот костыль не канает и вопрос остаётся открытым... Как вариант можно попробовать в vi /etc/mail/submit.mc изменить значение строки "FEATURE(`msp', `[127.0.0.1]')dnl" на реальный ИП нашего сервера и внести в /etc/hosts соответствующую запись. Очевидно, что это адрес для пересылки почты и соответственно ИП "127.0.0.1" числится как localhost и как бы мы не извращались в заголовках письма будут мелькать записи с упоминанием localhost!

/etc/hosts

Не будет лишним добавить в /etc/hosts строку "93.170.128.114 remotehelp.pp.ua", в помощь заголовку "Received: from ..." и "Received: by ..."

/etc/sysconfig/network

При необходимости в файле /etc/sysconfig/network можно сменить "HOSTNAME=localhost.localdomain" для постоянного использования, а на время hostname можно установить командой hostname new.hostname.

/etc/resolv.conf

Также для успешной отправки почты наш сервер использует DNS сервера, которые должны быть прописаны в файле /etc/resolv.conf: "nameserver 8.8.8.8", здесь указан DNS сервер Google

SPF (Sender Policy Framework - структура политики отправителя)

Агенты передачи электронной почты, которые получают почтовые электронные сообщения, иногда с помощью простого DNS-запроса запрашивают SPF-информацию, таким образом идентифицируя сервер отправителя. Правила SPF определены в RFC 4408

Чтобы для домена прописать SPF запись, требуется доступ к редактированию DNS записей домена-отправителя. Создаем запись типа TXT такого содержания:

v=spf1 +mx +a:remotehelp.pp.ua +ip4:93.170.128.114 include:_spf.google.com ~all

v= определяет версию SPF. Далее идёт список механизмов верификации: «+a:?» разрешает прием писем от указанного домена, если его IP-адрес совпадает с IP-адресом, который указан в A-записи; «+mx» разрешает принимать письма, если отправляющий домен указан в одной из MX-записей; «-all» — указывает на то, что электронные сообщения, которые не прошли верификацию при помощи перечисленных ранее механизмов, следует отвергнуть. Также можно использовать «~all» - в таком случае электронное письмо, которое не прошло верификацию, не будет отклонено, но может быть более тщательно изучено (SoftFail), а «+all» означает, что весь мир наши друзья.

Параметр include:_spf.google.com дополняет/включает нашу SPF запись, почтовыми доменами (SPF записю) серверов гугля, эта запись нужна если вы используетесь почтой для домена от Google Apps, и если её не добавить то все письма отправленные с гугля от имени вашего домена (Google Apps) будут восприняты как спам:

Предположим, в вашем домене example.com используется служба Gmail. Вы создаете запись SPF, которая определяет почтовые серверы Google Apps как авторизованные почтовые серверы вашего домена. Когда почтовый сервер получателя принимает сообщение с адреса polzovatel@example.com, он может проверить запись SPF домена example.com, чтобы определить, является ли сообщение действительным. Если сообщение поступило с сервера, который не входит в число почтовых серверов Google Apps, перечисленных в записи SPF, почтовый сервер получателя может отклонить его как спам.

SPF запись заточите под свою ситуацию, удалите или добавьте некоторые параметры. Подробнее о синтаксисе SPF записей можно найти на официальной странице http://www.openspf.org/SPF_Record_Syntax

Reverse DNS entry

Смотреть выше: "<<< 550 We cannot accept email from IP 94.249.240.244 without a DNS PTR record."

Прописать обратную ДНС зону (Reverse DNS entry), может только владелец IP адреса. Обратная зона, благодаря PTR записи, для ИП обеспечивает превращение ИП адреса в имя хоста, проверить её наличие можно при помощи утилиты nslookup 93.170.128.114 или nslookup -type=PTR 93.170.128.114 или через веб сервис http://centralops.net/co/DomainDossier.aspx. PTR запись должна выглядеть примерно так:

114.128.170.93.in-addr.arpa PTR remotehelp.pp.ua.

MX запись в DNS

Очень желательно чтобы среди ДНС записей домена, с которого отправляется электронная почта, присутствовала MX запись указывающая на именно на тот домен с которого шлётся электронная почта.

DKIM подпись электронной почты

DomainKeys Identified Mail — метод аутентификации E-mail. Технология DomainKeys Identified Mail (DKIM) объединяет в себе несколько методов антифишинга и антиспама, целью которых является повышение качества идентификации и классификации легитимной электронной почты.

Вместо обычного IP-адреса, для идентификации отправителя электронного сообщения DKIM добавляет к нему цифровую подпись, которая связанна с именем домена. Подпись DKIM проверяется на стороне получателя, и в зависимости от результатов, применяются «белые» или «чёрные» списки.

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

Под занавес

В почтовых сервисах гугля и яху довольно интеллектуальные и щепетильные спам фильтры, а поэтому даже правильно настроенная и подписанная DKIM-мом, исходящая с проверенного сервера, имеющего SPF, PTR и МХ запись, почта иногда может уходить в каталог "Спам".

Если sendmail и postfix настроены верно, почта правильно подписана DKIM-мом, все служебные заголовки письма это подтверждают, то в таком случае, что мы можем сделать, так это экспериментировать с темой письма и его содержанием - это часто помогает, а также читаем ниже "ссылки по теме".

Ссылки по теме

Олег Головский

Рекомендуемый контент



Добавить комментарий

АХТУНГ! Все комменты модерасятся модерастом. Мессаги исключительно рекламного или оскорбительного содержания не публикуются, а поэтому злостным спамерам, пранкерам и прочей сетевой нечисти рекомендуем напрасно не тратить своего времени и удовлетворять свои больные фантазии на специализированных Интернет ресурсах! Разумная же критика, замечания, дополнения и хвалебные оды приветствуются, также допускается легкий флуд или троллинг :)


Защитный код
Обновить

Рейтинг@Mail.ru 2 megabytes