[laimas]

отправляю без From - потому что странное дело с From письмо не доходит

Если адрес To совпадает с адресом From, то почтовый сервер может такое письмо отклонить, Яндекс, с недавних пор, это делает гарантировано.

<style type="text/css"> в письме, это, конечно, красиво, но никак не гарантирует, что будет принято к вниманию. Почта все-так не веб страница и различные почтовые сервера и почтовые клиенты в этом отношению поступают по своему усмотрению. То что вы можете видеть красоту на одном, совсем не означает, что на другом тоже такое будет. Кроме того, даже поддерживая стили встроенные, поддержка может быть только некоторых, а не всего существующего разнообразия.

Отправлять адресату письмо как HTML и надеяться, что он таковым его и прочтет, это как гадать на кофейной гуще - вид письма определяет не mime тип его, а настройки почтового ящика, если пользователь определил получать письма как текст, то ваше письмо будет кошмарным для него. Гарантированно читабельным для получателя будет письмо содержащее в себе две части - text/plain и text/html.

Ваше письмо по типу конечно же глупость - его содержание объявляется и как text/plain (строка 55) и как text/html (строка 62).

subject: $subject\r\n - объявления charset на тему письма не влияют, тему нужно кодировать.

Тип multipart имеет три субтипа - mixed, alternative и related, которые используются синтаксически одинаково, но имеют разное предназначение:

mixed - используется, когда в рамках одного почтового сообщения имеется несколько независимых друг от друга, и равнозначных частей. Самый простой пример такого письма - сообщение с вложением.
alternative - используется, когда в одном почтовом сообщении содержится несколько частей, содержащих одну и ту же информацию, предназначенную для отображения на различном клиентском ПО - например текстовая и HTML версия одного и того же письма.
related - используется, когда в одном почтовом сообщении содержится несколько частей, формирующих один итоговый документ. Пример - HTML письмо с картинками. Запомните, по стандарту только в этом случае должны работать ссылки на Contend-id элементов вида <img src="cid:image">.

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

mixed - порядок частей для наших задач не имеет значения.

alternative - части должны быть расставлены по порядку, от более простых к более сложным. RFC регламентирует процесс выбора одной из версий письма клиентом пользователя примерно так: "В общем случае, почтовый клиент должен отображать последнюю доступную ему версию документа". То есть, при формировании текстовой и HTML-версий письма необходимо вперед поставить текстовую.

related - первой в очереди должна идти основная часть (HTML документ, например). Следом - все остальные. По большому счету, стандартом регламентирован специальный параметр "start", который указывает на основную часть документа, но этим лучше не злоупотреблять.

Любая из частей письма может так же иметь Content-type: multipart, а значит можно выстроить некоторое подобие древовидной структуры, гарантирующей, что каждая из частей письма займет правильное место. Например структура письма, имеющего текстовую и HTML версию (HTML с картинками), а так же приложенный документ MS Word:

Content-type: multipart/mixed
    Content-type: multipart/alternative
        Content-type: text/plain
        Content-type: multipart/related
            Content-type: text/html
            Content-type: image/jpeg
            Content-type: image/jpeg
    Content-type: application/msword

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

$CRLF = substr(PHP_OS, 0, 3) != "WIN" ? "\n" : "\r\n";

Но лучше использовать константу PHP_EOL возвращающую необходимое в зависимости от платформы.

Рекомендации и регламенты отправления почтовых сообщений описаны в соответствующих документах RFC.