IT Runs

Еще одно решение проблемы mail в php

Поступило еще одно решение проблемы с темой (subject) письма, отправляемого функцией mail в php (подробности здесь: http://itruns.ru/post/422397378/sendmail). За решение спасибо ereptoris:

$subject = '=?UTF-8?'; //Говорим, что у нас в теме текст в соответствующей кодировке

$subject .= 'B?'; //А текст зашифрован алгоритмом base64

$subject .= base64_encode($content) . '?='; // Кодируем текст и дописываем завершающее выражение

Нечто похожее описано на той же странице на php.net. Может быть кому-то так и удобнее, не спорю. Лично для меня, более простой и очевидный способ я описал в предыдущей заметке, тем более, mb_string в любом случае подключен и никакой его глючности я пока что не заметил.

Новые потрясающие выкрутасы с sendmail

В темпе вальса переводим все письма в UTF-8! И, само собой, ничто никогда не работает сразу так, как хочется =).

Если в header просто заменить кодировку на UTF-8:

Content-type: text/html; charset=utf-8

само тело письма преобразуется нормально. Однако тема (subject) продолжает подражать самым изысканным иероглифам. На сайте php.net нашлась вот такая строчка:

$subject= mb_encode_mimeheader($subject, “UTF-8”, “B”, “\n”);

Сработало. Почему-то, не с первого раза, но это я уже не в силах объяснить.

И еще одна тупая ошибка sendmail

Сегодня вдруг обнаружилось, что на всех серверах не работает отправка почты. Почта отправляется юзерам при регистрации и еще по нескольким замечательным поводам. И, естественно, после перехода на новую тех. площадку с новыми серверами, новой версией php и так далее, никому в голову не пришло потестить эту незначительную функцию.

История такова: php работает, sendmail работает, но при отправки письма из php с помощью стандартной mail(), она выплевывает ошибку типа “sh: -t: command not found”. Выплевывает, как водится в лог ошибок, поэтому ее никто и не заметил.

Пару минут гугления показали, что в php.ini нужно прописать путь к sendmail:

sendmail_path = /usr/sbin/sendmail

прописал. Картина изменилась. Теперь ошибка выглядела еще большим бредом: Recipient names must be specified. Еще полчаса мучений привели к следующей коррекции пути к sendmail:

sendmail_path = /usr/sbin/sendmail -t

Это решило проблему. Не очень понятно, что это значит, но работает. Обновил php.ini, перезапустил веб-сервер, и все в порядке.

Как остановить спам-бота, созданного собственными руками

Последние 2 дня регулярно получаю по 300-500 писем от одного из скриптов. Все письма были поставлены в очередь еще в пятницу, и сервер их постепенно отправляет. Я упорно удалял эти письма из ящика, пока не вспомнил, что такая проблема уже возникала, и решил я ее просто почистив очередь sendmail. Сработало и в этот раз:

rm -rf /var/spool/mqueue/*

Справедливости ради надо сказать, что в прошлый раз все было сложнее - очередь была в разы больше, и rm -rf обламывался с сообщение типа “too many arguments”. Тогда все решилось методичным набором комманд типа:

rm -rf /var/spool/mqueue/a*
rm -rf /var/spool/mqueue/b*
rm -rf /var/spool/mqueue/c*

и так далее. Долго, тупо… но времени придумать что-то поумнее просто не было.

Кстати, чтобы просмотреть всю очередь можно использовать комманду:

mailq

И вот еще:

http://lists.freebsd.org/pipermail/freebsd-questions/2004-March/041322.html

не читал, но вроде что-то умное написано. Может пригодиться.