2011-07-21 16 views
5

Ostatnio niektórzy klienci skarżyli się, że otrzymywali zniekształcone wiadomości e-mail. Wyświetlały się nagłówki MIME, dane zakodowane w base64 itd. Rzeczy, które powinny zostać odkodowane przez ich klientów pocztowych.Jaki jest prawidłowy znak nowej linii w wiadomościach e-mail? LF lub CRLF?

Po przeprowadzeniu dochodzenia odkryłem, że niektórzy klienci pocztowi (adres e-mail gmx.de do nazwy) wstawili pustą linię po każdej innej linii, co naprawdę wszystko zepsuło.

Po przeczuciu zmieniłem kod wysyłania wiadomości, aby zastąpić wszystkie CRLF tylko LF. A oto i oto - poczta przybyła w całości.

Teraz jest to dziwne, ponieważ RFC 5322 wyraźnie stwierdza, że ​​

2.3. Body

Treść wiadomości to po prostu linie znaków US-ASCII. tylko dwa ograniczenia na ciele są następujące:

o CR i LF MUST występują tylko razem jako CRLF; NIE MUSZĄ pojawiać się niezależnie w ciele.

Huh? Zły webmail? A może gdzieś poszedłem źle? Inne webmails (np. Gmail) nie mają z tym problemów i wydaje się, że większość ludzi nie ma problemów (skoro reklamacja jest niewielka).

Uwaga - wysyłam wiadomości e-mail za pośrednictwem funkcji PHP mail() w systemie Linux. Podstawowym oprogramowaniem pocztowym wydaje się być qmail, ale nie jestem pewien.

Wygląda na to, że qmail doesn't like CRLF under similar conditions. Czy to może być problem? Czy to już nie jest naprawione (ta strona nie zaktualizowała się za 4 lata)?

+0

Jestem pewien, że to CRLF. – BoltClock

+0

A więc przegłosowałeś? O_o –

+0

Nie zrobiłem. W zasadzie właśnie przegłosowałem. – BoltClock

Odpowiedz

2

http://www.php.net/manual/en/function.mail.php stany

Uwaga:

Jeśli wiadomości nie są odbierane, spróbuj użyć LF (\ n) tylko. Niektórzy agenci przesyłania poczty Unixowej (w szczególności qmail) automatycznie zamieniają LF na CRLF (co prowadzi do podwojenia CR, jeśli użyto CRLF w postaci ). To powinno być ostatecznością, ponieważ nie jest zgodne z RFC 2822.

Powiązane problemy