2011-07-21 23 views
5

Gần đây một số khách hàng phàn nàn rằng họ đã nhận được email bị cắt xén. Các tiêu đề MIME đang hiển thị và dữ liệu được mã hóa base64, vv Nội dung cần được giải mã bởi ứng dụng thư của họ.Dòng mới thích hợp trong email là gì? LF hoặc CRLF?

Sau khi điều tra, tôi thấy rằng một số ứng dụng thư (gmx.de webmail đến tên một) đã chèn một dòng trống sau mỗi dòng khác, do đó thực sự làm mọi thứ rối tung lên.

Sau khi linh cảm, tôi đã thay đổi mã gửi thư của mình để thay thế tất cả CRLF chỉ bằng LF. Và lo và nhìn - thư đến toàn bộ.

Bây giờ, đây là kỳ lạ, bởi vì RFC 5322 khẳng định một cách rõ ràng rằng

2,3. Nội dung

Nội dung thư chỉ đơn giản là các dòng ký tự US-ASCII. Các chỉ có hai giới hạn trên cơ thể như sau:

o CR và LF PHẢI chỉ xảy ra với nhau như CRLF; họ KHÔNG PHẢI xuất hiện độc lập trong cơ thể.

Huh? Webmail xấu? Hay tôi đã đi sai ở đâu đó? Các trang web khác (như gmail) không có vấn đề gì với điều này, và thực sự có vẻ như đa số mọi người không có vấn đề gì (vì các khiếu nại rất ít).

Chỉ cần lưu ý - Tôi đang gửi email thông qua chức năng mail() của PHP trên hộp Linux. Phần mềm thư cơ bản có vẻ là qmail, nhưng tôi không chắc chắn.

Có vẻ như qmail doesn't like CRLF under similar conditions. Đây có phải là vấn đề không? Có phải nó đã được sửa chưa (trang đó chưa được cập nhật trong 4 năm)?

+0

Chắc chắn đó là CRLF. – BoltClock

+0

Vì vậy, bạn đã downvoted? O_o –

+0

Tôi thì không. Trong thực tế, tôi chỉ upvoted. – BoltClock

Trả lời

2

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

Lưu ý:

Nếu tin nhắn không nhận được, hãy thử sử dụng một LF (\ n) mà thôi. Một số tác nhân chuyển thư Unix (đáng chú ý nhất là qmail) thay thế LF bằng CRLF tự động (dẫn đến CR gấp đôi nếu sử dụng CRLF). Đây phải là phương sách cuối cùng, vì nó không tuân thủ RFC 2822.

Các vấn đề liên quan