Нужно отметить, что если настройка отправки почты выполняется на выделенном сервере, особое внимание нужно уделить имени хоста hostname, который аж никак не должен быть равен = localhost.localdomain, и в отправляемой почте не должно быть заголовков со значениями типа [email protected], иначе такие письма будут улетать в каталог "Спам", а ИП адрес вашего сервера ссовременем попадёт в 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; [email protected] 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 [email protected]" - если есть пользовательский php.ini, а если нет, то непосредственно в самой функции mail(); пятым параметром. В противном случае заголовок "Return-Path: ..." будет равен примерно такому значению "Return-Path: <[email protected]>". ОЧЕНЬ желательно чтобы значение заголовка "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 [email protected] using -f". Этого заголовка с предупреждением можно избежать, указав доверенных пользователей в vi /etc/mail/trusted-users
Если нужно использовать отличный от vi /etc/mail/trusted-users файл то добавьте в vi /etc/mail/sendmail.mc следующие строки:
Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!
Пересоберите 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:
Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!
При этом имя домена желательно указать в 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 такого содержания:
Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!
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 как авторизованные почтовые серверы вашего домена. Когда почтовый сервер получателя принимает сообщение с адреса [email protected], он может проверить запись 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 itmag.pro.
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-мом, все служебные заголовки письма это подтверждают, то в таком случае, что мы можем сделать, так это экспериментировать с темой письма и его содержанием - это часто помогает, а также читаем ниже "ссылки по теме".
Ссылки по теме
- Установка и настройка OpenDKIM с MTA Postfix или Sendmail в CentOS 5,6
- Анализ записей SPF - Cправка - Google Apps
- Почтовый сервер Postfix
- Postfix before-queue Milter support
- Sender Policy Framework — официальный сайт стандарта
- Тесты для проверки SPF
- Reverse DNS
- About DKIM
- DKIM - Sendmail.com
- DomainKeys Identified Mail
- DomainKeys, DKIM, SPF, SpamAssassin Email Validator
- Blocklist Removal Center
- CBL Lookup Utility
- Multiple DNSBL lists check (total 82 lists)
- Аутентификация электронной почты с помощью ключа домена - Cправка - Google Apps
- Аутентификация электронной почты с помощью ключа домена: создание ключа - Cправка - Google Apps
- Аутентификация электронной почты с помощью ключа домена: изменение записей DNS - Cправка - Google Apps
- Ресурсные записи DNS
- opendkim-README
- opendkim.conf − Configuration file for opendkim
- The Default Sendmail Installation
- Common Sendmail Configuration Changes
- DomainKeys, DKIM, SPF, SpamAssassin Email Validator
- AOL Postmaster Reputation Check
- Технические и административные требования для отправки электронных сообщений на Mail.Ru
- [email protected] — сервис специально созданный для отправителей почты, которые хотят улучшить доставляемость и качество своих почтовых рассылок.
- Устранение неполадок с массовыми рассылками - Cправка - Gmail
- Рекомендации по осуществлению массовых рассылок - Cправка - Gmail
- Что такое DMARC - Cправка - Google Apps
- Почему сообщения помечаются как спам - Cправка - Gmail
