V emailu vidím že jak subject, tak html tělo je v UTF-8 bez typicky výrazného escapování.
... hele, a zjistil sis vubec co to je? ...
Protoze z tohoto plyne ze netusis ... protoze nejde o ani subj ani o telo, jde o mailovou adresu.
Jelikoz se to stalo u 3 mailu (2+1), ktere jsem rucne preposilal at user neprijde o nic, tak jsem se presne dival do zdrojaku tech mejlu.
Pripad e-shopu (ten se starym PHP) obsahuje UTF-8 pouze u
Subject: z tech co jsou v headerech, emaily tam jsou bez jmen, jen mailova adresa a ta zadne utf8 prirozene neobsahuje. Dale to tvrdi v headerech
Content-Type: text/html; charset=utf-8 a telo zpravy je jedno html, neni to multipart, ani encoded a je nativne v UTF-8.
Druhy pripad - fakturacni systemu ktery leze skrze amazonaws, obsahuje cestinu v Subject, ale ta je spravne quoted. Pak je tam multipart telo (protoze PDF priloha), s touto hlavickou:
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Ale nasledny html flagment je nativne v utf8 coz je 8-bit "binarka".
Takze z toho mi plyne, ze kdyz seznam.cz SMTP neanoncuje SMTPUTF8, a ja mam pripraven tady ten "binarni" payload, tak to lokalni postfix nema kam poslat.
Jeste by to mohl byt problem postfixu, ze nespravne detekuje potrebu daneho rozsireni, kdyz mu dodavam ten mail k preposlani.Forward command je tento, parametry jsou escapovany, je to PHP demon co hlida slozku s frontou:
`/usr/sbin/sendmail -f $qfrom $qdest <$qmail`Chyba se zacala dit az pote co jsem updatoval postfix nedavno.
Ted jsem SMTPUTF8 vypnul, podle prvnich dvou postu v tomto vlakne, zda byl problem i s dovecotem, netusim - preposilani a dovecot jsou u nas vzajemne se vylucujici (co se preposila nepouziva imap, a co pouziva imap se nepreposila, takze nemam tuseni o potencialne chybnem mejlu - leda ze bych si udelal objednavku na stejnem eshopu.. zas az tak me to nezajima uz v teto fazi).
9 Odpovědí
1601 Zhlédnutí