Разное

Вот такая фигня иногда приходит от сервера в ответ на письмо посланное функцией mail

This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:   user@dimain.com     (generated from user@domain.com)     LMTP error after end of data: 554 5.6.0 Message contains NUL characters

Проблема в том что другие письма нормально приходят, посланныетой же функцией из того же места. В чём может быть проблема?
Подозреваю что в "Message contains NUL characters". А чтоэто за "NUL characters"?

PS. Надо изменить название темы на "ошибка LMTP"

Вы пытаетесь отправлять нечто, не являющееся текстом. Сервер на это ругается.

Письмо пишется в стандартном textarea. Что там можно ввести такого запрещённого?
А можно тогда как-нить почистить письмо перед отправкой чтобы остался только текст?

Что угодно можно ввести. Надо изучать отправляемое тело.
Попробуйте применить count_chars(). Если не поможет - попробуйте сериализовать тело и показать его здесь(в аттаче).

Тело, к сожалению, показать не могу, это конфиденциальная переписка.
А нельзя ли полюбопытствовать что это за NUL CHARACTERS такие и как с ними бороться?
Чё-то в сети по этому поводу вообще ничего нету... 2 дня уже ищу.
Я так понимаю это как-то со спамом связано, или я не прав

NUL char это символ с кодом 0
Точно также как, например, символ 0 - это символ с кодом 48
А бороться с ними обычно не приходится. В тексте им просто неоткуда взяться.
Двоичные файлы обычно пересылают вложениями, кодируя данные в формате base64 (base64_encode()) и превращая тем самым в чистый текст.

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

А что тогда делать в моём случае?
Майл - сервер заворачивает обычные нормальные письма. Тело письма формируется в текстареа. Откуда же берутся эти nul characters? В день бывает около 100 писем. Из них 1-2 не проходят и возвращаются. Что же такое юзеры вводят? Может тут дело в том что некоторые копируют и вставляют текст из ворда или других редакторов. Так могут появится nul characters?

Так - могут.
А банально удалять их с помощью str_replace не получается?
$body = str_replace('', chr(0), $body);
А заодно и другие нетекстовые?

Не получается :( Да и не в них дело похоже...
Провёл тест:

mail('yashik@domain.com','test',substr($body,0,500),$headers); // Пришло mail('yashik@domain.com','test',substr($body,500),$headers); // Пришло mail('yashik@domain.com','test',$body,$headers); // Не пришло

Всё, блин, я в ауте. Как так??? По частям приходит. Целиком нет

Теперь уменьшайте цифру 500 до нуля. Можно методом половинного деления.

Уменьшил

mail($mail,$subject,substr($body,153),$headers);// не пришло mail($mail,$subject,substr($body,154),$headers);// пришло mail($mail,$subject,substr($body,0,154),$headers);// пришло

Ничего не понимаю...

Внимательно смотрите фрагмент в районе 153 символа.

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

Что за почтовые системы?
Вряд ли тут с длиной связано, потому что проходят гораздо более объёмные письма
Сделал так:

$frag = substr($body,150,5);   $f = count_chars($frag);   echo "<pre>";   print_r($f);

получил:

[32] -2 [111]-1 [114]-1 [116]-1

Т.е. нулевыми символами даже и не пахнет...

Всё, тупик...

Не длина письма, а длина любой строки письма. Возможно, что длина этой строки - 1153 (или около того) символа. Соответственно, когда её режешь с 154 позиции, длинная строка разбивается на две строки, каждая из которых короче 1000 символов.
Возможно, конкретное ограничение - вовсе не тысяча, а совсем другое. Тысяча - это декларация по RFC-821.

Всё! Алилуйа. так и есть. проблему решает строчка:

$message = chunk_split($message,1000);

Trianon спасибо огромное за терпение и естественно за помощь.

Так злобно - прям по живому?
Хотя б пробел чтоли какой нашли....

Сначала тоже хотел, но там возможен html код. А пробел в ненужном месте может порушить его, а перевод строки вроде как на html не влияет.

Я имел в виду - поискать пробел и по пробелу порезать.
Перевод строки влияет в той же мере, что и пробел.
Конечно, если распилить по пробелу каким образом текстовое значение атрибута какого-нибудь тега - ничего хорошего не выйдет.
Но резать грубо по 1000 позиции - еще хуже. Можно порезать имя тега, имя атрибута, значение. Так будет плохо почти наверняка.

Чё-то как-то мудрёно получается...
Вот кстати неплохая задачка для раздела задачи :)
порезать текст на части по пробелам через заданные промежутки символов.
Т.е. через каждые например 900 символов ищем предыдущий пробел и заменяем его на перевод строки.

Мудрёно, конечно. Может, правда, регулярным выражением можно решить...

Не так. Через 1000 символов непрерывающейся строки от последнего LF назад ищем пробел, который бы не оказался в значении атрибута тега. Впрочем, если там javascript - будет еще сложнее.

Javascript нету точно, только html возможен