Ошибка при отправки сообщения php

Тривиальные ситуации, когда имеется непорядок со значением sendmail_path в конфигурации php, решаются легко. Проверьте через phpinfo();, чтобы у вас было задано значение типа /usr/sbin/sendmail -t -i в конфиге, и чтобы за /usr/sbin/sendmail действительно скрывался установленный и работающий MTA. Но сегодня пришлось побеждать менее типовую проблему: из php-скрипта почта как бы отправлялась, но где-то дальше сообщения терялись.

Убеждаемся, что PHP точно пытается отправить почту

Для начала напомню, что начиная с php 5.3 можно включить лог для всей исходящей почты, отсылаемой через функцию mail() из php. Достаточно в конфигурацию php.ini добавить такую настройку:

mail.log = /var/log/phpmail.log

При этом важно, чтобы пользователь, от которого работает php, имел доступ к файлу /var/log/phpmail.log на запись. Рекомендую для комфортной отладки создать файл и позволить всем в него записывать, примерно так:

touch /var/log/phpmail.log
chmod 666 /var/log/phpmail.log

Если у вас php работает как модуль Apache, то перезапустите последний.

Записи в логе будут примерно такие:

mail() on [/var/www/modules/system/system.mail.inc:83]: To: admin@example.tld --
Headers: From: user@example.tld

Если версия php у вас поновее чем 5.3, то в лог добавятся дата и время (что, конечно, очень полезно). Например, PHP версии 5.5.32 точно добавляет дату и время (но с какой в точности версии это началось — я не знаю). Всё-таки главное в этом логе — абсолютный адрес скрипта и номер строки, с которой вызывалась функция.

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

<?php
  $to = 'yourmail@example.tld';
  $subject = 'Test email subject';
  $message = 'Test from PHP at ' . date('Y-m-d H:i:s');
  mail($to, $subject, $message);
  echo 'Mail sent';
?>

У меня была как раз такая ситуация: php исправно делал свою работу и записи в логе почты оставлял (ничего при этом не оставляя в логе ошибок).

Проверяем, что письмо может отправить администратор из консоли (без всяких там PHP)

Одновременно с этим почта у меня прекрасно отправлялась из серверной консоли. Проверить можно так:

echo "Test message" | mail -s "Test emal subject" yourmail@example.tld

Если вдруг на вашем сервере нет утилиты mail, то установите пакет mailx вот так:

yum -y install mailx

Анализируем лог postfix

Пришлось заглядывать в лог почтовика. Он пишется в файл /var/log/maillog (актуально для CentOS).

И вот там-то нашлись неприятные записи такого характера:

18:34:31 postfix/sendmail[26381]: fatal: chdir /var/spool/postfix: Permission denied
18:51:16 postfix/sendmail[4603]: fatal: chdir /var/spool/postfix: Permission denied

Даже минимальный опыт общения с линуксом подсказывает, что тут дело либо в несоответствии прав/владельцев, либо в какой-то дефолтной защите, типа фаерволла или… SELinux. В данном случае «виноват» последний.

Отучаем SELinux блокировать почту, отправляемую из PHP

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

getsebool httpd_can_sendmail

Если вывод будет httpd_can_sendmail --> off, то значит вашу почту блокирует SELinux. Чтобы его от этого отучить на постоянной основе выполните команду:

setsebool -P httpd_can_sendmail 1

И после этого ждите несколько секунд, пока снова не увидите приглашение командной строки. Без ключа -P блокировка снимется только до перезагрузки.

Кстати, пусть вас не смущает, что в параметрах SELinux упомянут httpd. Даже если у вас Apache отсутствует в принципе, а используется, например, связка nginx и php-fpm, то почта всё равно может блокироваться с аналогичными симптомами. Решается проблема точно также и для php-fpm (меняем ту же переменную).

Запрещаем виртуальному хосту отправлять почту

Иногда бывает такая ситуация, что надо наоборот запретить отправлять почту какому-то сайту. Например, если ясно, что на нём вирус, но на лечение вируса нужно время.

Тогда действуем от противного — в настройки виртуального хоста проблемного сайта добавляем параметр:

php_admin_value sendmail_path "/dev/null"

И перезапускаем Apache, чтобы изменения вступили в силу. Либо вы можете включить упомянутый выше параметр SELinux, однако, учтите, что это не поможет, если в вашей системе SELinux отсутствует или перманентно отключен.

Есть send.php, в нем проблем вроде нет.

<?php
$msg = "<h3>Обратая связь</h3>";
if(isset($_POST['name'])) { $msg .= "<br><strong>Имя:</strong> ".$_POST['name'];}
if(isset($_POST['tel'])) { $msg .= "<br><strong>Телефон:</strong> ".$_POST['tel'];}
if(isset($_POST['phone'])) { $msg .= "<br><strong>Телефон:</strong> ".$_POST['phone'];}
if(isset($_POST['mail'])) { $msg .= "<br><strong>E-mail:</strong> ".$_POST['mail'];}
if(isset($_POST['firstvalue'])) { $msg .= "<br><strong>Экологический стандарт:</strong> ".$_POST['firstvalue'];}
if(isset($_POST['secondvalue'])) { $msg .= "<br><strong>Что-то еще:</strong> ".$_POST['secondvalue'];}
if(isset($_POST['thirstvalue'])) { $msg .= "<br><strong>Последний пункт:</strong> ".$_POST['thirstvalue'];}



$EOL = "rn";
$boundary     = "--".md5(uniqid(time()));
$headers    = "MIME-Version: 1.0;$EOL";
$headers   .= "Content-Type: multipart/mixed; boundary="$boundary"$EOL";
$headers   .= "From: asd@gmail.com";

$multipart  = "--$boundary$EOL";
$multipart .= "Content-Type: text/html; charset=utf8$EOL";
$multipart .= "Content-Transfer-Encoding: base64$EOL";
$multipart .= $EOL;
$multipart .= chunk_split(base64_encode($msg));

$to  = 'asdf@gmail.com';

$subject = "Обратная связь";

mail($to, $subject, $multipart, $headers);

header('Location: https://moonway.by/aks?success=ok');

?>

И есть два модальных окна с формами, использующими этот скрипт отправки
В первом только одно поле — телефон. Отправка письма из этой формы работает.

<form class="under-construction" method="post" action="send.php">
   <div class="form-group email">
       <input class="form-control email" type="tel" name="tel"placeholder="Введите Ваш номер">
   </div>
   <button data-hover="Заказать звонок" class="btn btn-default btn-block progress-button" type="submit">
       <span class="button-label">Заказать звонок</span>
   </button>
 </form>

И вторая форма, не работает. Суть в том, что значения в input hidden подставляет js-скрипт.

<form class="under-construction" method="post" action="send.php">
                <div class="form-group email">
                    <input class="form-control name" type="text" name="name" placeholder="Введите Ваше имя" required>
                    <input class="form-control tel" type="tel" name="phone" placeholder="Введите Ваш номер телефона" required>
                    <input class="form-control email" type="email" name="mail" placeholder="Введите Ваш e-mail">
                    <input type="hidden" name="firstvalue" id="firstvalue">
                    <input type="hidden" name="secondvalue" id="secondvalue">
                    <input type="hidden" name="thirstvalue" id="thirstvalue">
                </div>
                <button data-hover="Отправить" class="btn btn-default btn-block progress-button" type="submit">
                    <span class="button-label">Отправить</span>  
                </button>                       
            </form>

Пробовала из send.php удалять строки, отвечающие именно за эти скрытые инпуты, и письма отправлялись.
В чем может быть проблема?

UPD: Перепробованы все возможные варианты. Письмо не приходит, если в форме есть поля, заполненные с помощью js.

Хотя есть части этого ответа, которые применяются только к использованию самой функции mail(), многие из этих шагов устранения неполадок могут быть применены к любой почтовой системе PHP.

Существует множество причин, по которым ваш скрипт не отправляет электронные письма. Трудно диагностировать эти вещи, если нет очевидной синтаксической ошибки. Без этого вам нужно пройти через контрольный список ниже, чтобы найти возможные потенциальные проблемы, с которыми вы можете столкнуться.

Убедитесь, что отчет об ошибках включен и установлен для сообщения обо всех ошибках

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

error_reporting(-1);
ini_set('display_errors', 'On');
set_error_handler("var_dump");

См. Этот ответ для получения дополнительной информации об этом.

Убедитесь, что функция mail() вызывается

Это может показаться глупым, но распространенной ошибкой является забыть фактически разместить функцию mail() в вашем коде. Удостоверьтесь, что он есть и не прокомментирован.

Убедитесь, что функция mail() вызывается правильно

bool mail (string $ to, string $ subject, string $ message [, string $ дополнительные_headers [, string $ дополнительные_параметры]])

Функция почты принимает три обязательных параметра и, необязательно, четвертый и пятый. Если ваш вызов на mail() не имеет по крайней мере трех параметров, он не сработает.

Если ваш запрос на mail() не имеет правильных параметров в правильном порядке, он также потерпит неудачу.

Проверка почтовых журналов сервера

Ваш веб-сервер должен регистрировать все попытки отправки электронной почты через него. Расположение этих журналов будет отличаться (вам может потребоваться спросить администратора вашего сервера, где они находятся), но их обычно можно найти в корневом каталоге пользователя в logs. Внутри будут сообщения об ошибках, сообщенные сервером, если таковые имеются, связанные с вашими попытками отправить электронную почту.

Проверка сбоя подключения к порту

Порт-блок — очень распространенная проблема, с которой сталкиваются большинство разработчиков, интегрируя свой код для доставки электронной почты с использованием SMTP. И это можно легко проследить на сервере maillogs (расположение сервера почтового журнала может варьироваться от сервера к серверу, как объяснялось выше). Если вы находитесь на сервере общедоступного хостинга, порты 25 и 587 по умолчанию остаются заблокированными. Этот блок специально предназначен вашим хостинг-провайдером. Это справедливо даже для некоторых выделенных серверов. Когда эти порты заблокированы, попробуйте подключиться с помощью порта 2525. Если вы обнаружите, что порт также заблокирован, единственное решение — связаться с вашим хостинг-провайдером, чтобы разблокировать эти порты.

Большинство хостинг-провайдеров блокируют эти почтовые порты, чтобы защитить свою сеть от отправки любых спам-писем.

Используйте порты 25 или 587 для соединений с обычным /TLS и с портом 465 для соединений SSL. Для большинства пользователей предлагается использовать порт 587, чтобы избежать ограничений по скорости, установленных некоторыми хостинг-провайдерами.

Не используйте оператор подавления ошибок

Когда оператор подавления ошибок @ добавляется к выражению в PHP, любые сообщения об ошибках, которые могут быть сгенерированы этим выражением, будут игнорироваться. Существуют обстоятельства, при которых использование этого оператора необходимо, но отправка почты не является одним из них.

Если ваш код содержит @mail(...) вы можете скрывать важные сообщения об ошибках, которые помогут вам отладить это. Удалите @ и проверьте, не сообщаются ли какие-либо ошибки.

Это целесообразно только после проверки с error_get_last() сразу для конкретных отказов.

Проверьте возвращаемое значение mail()

Функция mail():

Возвращает TRUE если почта была успешно принята к доставке, в противном случае FALSE. Важно отметить, что только потому, что почта была принята для доставки, это НЕ означает, что почта действительно достигнет предполагаемого адресата.

Это важно отметить, потому что:

• Если вы получили возвращаемое значение FALSE вы знаете, что ошибка заключается в том, что ваш сервер принимает вашу почту. Вероятно, это не проблема с кодировкой, а проблема конфигурации сервера. Вам нужно поговорить с вашим системным администратором, чтобы узнать, почему это происходит.
• Если вы получите TRUE возвращаемое значение, это не означает, что ваш адрес электронной почты определенно будет отправлен. Это просто означает, что письмо было отправлено на соответствующий обработчик на сервере с помощью PHP. Есть еще больше проблем с ошибкой вне контроля PHP, которые могут привести к тому, что письмо не будет отправлено.

Таким образом, FALSE поможет указать вам в правильном направлении, тогда как TRUE не обязательно означает, что ваша электронная почта была успешно отправлена. Это важно отметить!

Убедитесь, что ваш хостинг-провайдер позволяет отправлять электронные письма и не ограничивает отправку почты

Многие общие веб-хосты, особенно бесплатные провайдеры веб-хостинга, не позволяют отправлять электронные письма со своих серверов или ограничивать количество, которое может быть отправлено в течение любого заданного периода времени. Это связано с их усилиями по ограничению спамеров от использования их более дешевых услуг.

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

Проверьте папки спама; предотвращать помехи от сообщений электронной почты как спам

Зачастую по различным причинам электронные письма, отправленные через PHP (и другие языки программирования на стороне сервера), попадают в папку спама получателя. Всегда проверяйте их перед тем, как устранить неисправность вашего кода.

Чтобы избежать отправки почты, отправленной через PHP, в папку спама-получателя, вы можете делать различные действия, как в вашем PHP-коде, так и в других целях, чтобы минимизировать вероятность того, что ваши письма будут помечены как спам. Хорошие советы от Michiel de Mare включают:

• Используйте методы проверки подлинности электронной почты, такие как SPF и DKIM, чтобы доказать, что ваши электронные письма и ваше доменное имя принадлежат друг другу, и для предотвращения подмены имени домена. На веб-сайте SPF есть мастер для создания DNS-информации для вашего сайта.
• Проверьте обратный DNS, чтобы убедиться, что IP-адрес вашего почтового сервера указывает на имя домена, которое вы используете для отправки почты.
• Убедитесь, что IP-адрес, который вы используете, не включен в черный список
• Убедитесь, что адрес ответа — это действительный существующий адрес.
• Используйте полное, настоящее имя адресата в поле Кому, а не только адрес электронной почты (например, "John Smith" <[email protected]>).
• Контролируйте свои учетные записи о злоупотреблениях, такие как [email protected] и [email protected]. Это означает — убедитесь, что эти учетные записи существуют, читайте, что им прислали, и поступайте по жалобам.
• Наконец, очень легко отказаться от подписки. В противном случае ваши пользователи откажутся от подписки, нажав кнопку спама, и это повлияет на вашу репутацию.

См. Как вы уверены, что адрес электронной почты, который вы отправляете программно, автоматически не помечен как спам? для получения дополнительной информации по этой теме.

Убедитесь, что все почтовые заголовки поставлены

Некоторые спам-программы отклонят почту, если отсутствуют общие заголовки, такие как «От» и «Ответ на»:

$headers = array("From: [email protected]",
    "Reply-To: [email protected]",
    "X-Mailer: PHP/" . PHP_VERSION
);
$headers = implode("rn", $headers);
mail($to, $subject, $message, $headers);

Убедитесь, что заголовки сообщений не имеют синтаксических ошибок

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

$headers = array("From [email protected]", // missing colon
    "Reply To: [email protected]",      // missing hyphen
    "X-Mailer: "PHP"/" . PHP_VERSION      // bad quotes
);

Убедитесь, что значение получателя правильно

Иногда проблема такая же простая, как неправильное значение для получателя сообщения электронной почты. Это может быть связано с использованием неправильной переменной.

$to = '[email protected]';
// other variables ....
mail($recipient, $subject, $message, $headers); // $recipient should be $to

Другой способ проверить это — записать код получателя в вызов функции mail():

mail('[email protected]', $subject, $message, $headers); 

Это может применяться ко всем параметрам mail().

Отправить на несколько аккаунтов

Чтобы устранить проблемы с электронной почтой, отправьте свое электронное письмо на несколько учетных записей электронной почты у разных поставщиков электронной почты. Если ваши электронные письма не поступают в учетную запись пользователя Gmail, отправьте те же письма на учетную запись Yahoo, учетную запись Hotmail и обычную учетную запись POP3 (например, вашу учетную запись электронной почты, предоставленную поставщиком услуг Интернета).

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

Убедитесь, что код соответствует методу формы

Если вы установили метод формы в POST, убедитесь, что вы используете $_POST для поиска значений формы. Если вы установили его в GET или не установили его вообще, убедитесь, что вы используете $_GET для поиска значений формы.

Убедитесь, что значение action формы указывает на правильное местоположение

Убедитесь, что атрибут action формы содержит значение, указывающее на ваш почтовый код PHP.

<form action="send_email.php" method="POST">

Убедитесь, что веб-хост поддерживает отправку электронной почты

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

Электронная почта к их технической поддержке (после поездки к их онлайн-поддержке или FAQ) должна уточнить, доступны ли возможности электронной почты на вашем сервере.

Убедитесь, что почтовый сервер localhost настроен

Если вы работаете на своей локальной рабочей станции с помощью WAMP, MAMP или XAMPP, сервер электронной почты, вероятно, не установлен на вашей рабочей станции. Без него PHP не может отправлять почту по умолчанию.

Вы можете преодолеть это, установив базовый почтовый сервер. Для Windows вы можете использовать бесплатную Mercury Mail.

Вы также можете использовать SMTP для отправки своих писем. Посмотрите на этот отличный ответ от Викаса Дувиди, чтобы узнать, как это сделать.

Включить собственный пользовательский mail.log

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

ini_set("mail.log", "/tmp/mail.log");
ini_set("mail.add_x_header", TRUE);

Подробнее см. Http://php.net/manual/en/mail.configuration.php. (Лучше всего включить эти опции в возможностях php.ini или .user.ini или .htaccess.)

Проверьте с помощью службы проверки почты

Существуют различные службы проверки доставки и спама, которые вы можете использовать для тестирования вашей настройки MTA/webserver. Обычно вы отправляете почтовый пробник To: их адрес, затем получаете отчет о доставке и более конкретные отказы или анализы позже:

• mail-tester.com (бесплатный/простой)
• glockapps.com (бесплатно/$$$)
• senforensics.com (регистрация/$$$)
• mailtrap.io (pro/$$$)
• ultratools/…/emailTest (только для проверки /MX)
• Различные: http://www.verticalresponse.com/blog/7-email-testing-delivery-tools/

Использовать другую почтовую программу

Функция PHP, встроенная в функцию mail() удобна и часто выполняет свою работу, но имеет свои недостатки. К счастью, есть альтернативы, которые предлагают больше возможностей и гибкости, включая решение многих проблем, описанных выше:

• Наиболее популярным является: PHPMailer
• Точно так же: SwiftMailer
• Или даже старшая PEAR :: Mail.

Все они могут быть объединены с профессиональным SMTP-сервером/поставщиком услуг. (Поскольку типичные общие 15/15 общие планы веб-хостинга поражают или пропускают, когда дело доходит до настройки/настройки электронной почты).