Funkce cs_mail() doručí zakódovaný text

Dojde to správně, ale klient by to měl dekódovat, jak mu říká hlavička Content-Transfer-Encoding: base64. S touto chybou jsem se ještě nesetkal.

Zkoušeli jste poslat více mailů? Dělá to soustavně, nebo je to náhodná chyba?

dan55:
„tak existuje ještě jiná ověřená možnost odesílání emailů s českými znaky“
Lze použít ještě Quoted-Printable. Viz RFC 2047 4. Encodings. Je třeba změnit hlavičku a ošetřit problémové znaky.
Už jsem párkrát přemýšlel o updatu funkce v FAQ, base64 je možná zastaralé, ale dosud mělo bezproblémovou podporu a měl jsem vyzkoušeno. Překvapuje mě, že zrovna The Bat dělá problémy...

Zkuste ještě smazat tu hlavičku From.

dan55:
„Nechci do toho motat php mailer apod...“
Proč? PHPmailer je spolehlivá a jednoduchá cesta, jak v PHP sestavit bezchybně mail.
Na koleně zbastlený mail má kromě toho často tendenci padat do spamu.

Dan55, Ďakujem ti za toto riešenie. Už pol roka sa znažím vyriešiž tiež tento problém, ale ani vo sne by ma nebolo napadlo, že riešenie je takéto ľahké. Som začiatočník v PHP a už som môj kód prekopal asi 100 krát a stáleto to bolo o tom istom. Na niektoré emalové účto proste priľla správa zakódovaná a na niektoré nie. Odstránenie <b>/r</b> moje problémy vyriešilo. Ďakujem ti.

cerkoxxl:
Původně tam bylo jen \n, pak jsme to přepsali na \r\n a nakonec jsme modifikovali na PHP_EOL. Tak můžete vyzkoušet současnou verzi, která by měla být nezávislá na serveru.

Alphard:
Proč platformně? Myslel jsem, že hlavičky mailů jsou právě nezávislé a specificky je tam \r\n

http://tools.ietf.org/html/rfc5322#section-2.2 RFC píše oddělení CRLF (\r\n pro ty kdo neznají)
("Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF")
stejně tak http://tools.ietf.org/html/rfc2045#section-2.10 a dalších odkazovaných

Nox:
Abych pravdu řekl, dát tam PHP_EOL navrhl Davex, věřím mu. Tu normu jsem četl (výběrově), jenže jak píše dan55 a teď i cerkoxxl, sekvence \r\n právě nefungovala. Jde jim to až po odstranění \r a ponechání \n.
Ten script jsem před pěti lety sestavoval já, a dal jsem tam jen \n, s tím myslím problémy nebyly, ale někdo navrhoval dát tam dle normy \r\n, jestli si dobře vzpomínám, tak to byl také Davex.
U současného stavu se nikdo neozval, že by mu to nefungovalo. Mně to šlo když jsem to testoval na Windows, ale jinak již delší dobu používám Nette\Mail\Message, takže vlastními zkušenostmi nemohu sloužit.
Nette sice používá \r\n a s problémy jsem se nesetkal, ale tam se to zase myslím nekóduje base64.

Nox:
„Myslel jsem, že hlavičky mailů jsou právě nezávislé a specificky je tam \r\n“
Změnu na \r\n jsem opravdu doporučil já, protože jsem si to původně také myslel, ale byla to chyba.

Na protokolu SMTP někdy až tolik nezáleží, protože v Linuxu může mezi PHP a poštmistrem (komunikujícím s ostatními pomocí SMTP) číhat ještě hloupý pošťák, který před předáním e-mailu poštmitrovi doplní \r před všechna \n a tak vzniknou problematické sekvence \r\r\n. Pokud si dobře pamatuji, tak se to stávalo u programu sendmail od starších verzí e-mailových serverů Postfix a Exim. E-mailový server Sendmail s tím myslím problémy neměl (shoda jmen Sendmail a sendmail není čistě náhodná - ostatní e-mailové servery se snaží být kompatibilní se Sendmailem, takže některé programy pojmenovávají stejně).

Ve Windows by naopak mohly být problémy se samotným znakem \n, protože tam PHP e-mail odesílá přímo pomocí SMTP.

Jako univerzální řešení se tedy jeví používání konstanty PHP_EOL. Jen doufám, že to nikdo nebude zkoušet na Mac OS X, a že Apple to FreeBSD nepřiohnul trochu víc a ponechal tam Unixové konce řádků.