|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2001-01-27 03:42 UTC] chris dot php at bolt dot cx
The imap_8bit() function does not duplicate leading dots, which may cause a message to be cut off if it has a single dot on a line. Also, mail clients such as Outlook 2000 will strip these leading dots, which can cause an URL to be mangled if it is split along a dot (this is how I discovered the bug). To fix, replace any dots at the very start of a quoted-printable encoded line with 2 dots. (.hello becomes ..hello, etc) PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Nov 05 14:00:01 2025 UTC |
Not really a bug, but a known problem with buggy MTA's and clients. Also, fixing it would need to be done within the c-client, not PHP, and I don't think UW people will like to make their c-client less RFC-compliant. :( Details below. RFC2045 section 6.7 part (2) says: >(Literal representation) Octets with decimal values of >33 through 60 inclusive, and 62 through 126, inclusive, >MAY be represented as the US-ASCII characters which >correspond to those octets (EXCLAMATION POINT through >LESS THAN, and GREATER THAN through TILDE, respectively). Dot has a code of 46. Reading further says that characters !"#$@[\]^`{|}~ should be encoded too if we desire greater compatibility with some MTA's, but again, there no mention of '.'. !!!HOWEVER!!! Reading bolow in definitions of safe characters: >safe-char := <any octet with decimal value of 33 through > 60 inclusive, and 62 through 126. > ; Characters not listed as "mail-safe" in > ; RFC 2049 are also not recommended. RFC 2049 Section 3 item (8) says: >(8) Some mail transport agents will corrupt data that >includes certain literal strings. In particular, a >period (".") alone on a line is known to be corrupted >by some (incorrect) SMTP implementations, and a line >that starts with the five characters "From " (the fifth >character is a SPACE) are commonly corrupted as well. >A careful composition agent can prevent these >corruptions by encoding the data (e.g., in the quoted- >printable encoding using "=46rom " in place of "From " >at the start of a line, and "=2E" in place of "." alone >on a line). > >Please note that the above list is NOT a list of >recommended practices for MTAs. RFC 821 MTAs are >prohibited from altering the character of white space or >wrapping long lines. These BAD and invalid practices are >known to occur on established networks, and >implementations should be robust in dealing with the bad >effects they can cause. In other words, some mail clients and MTA's are known to mess this up. Yet, it is not the PHP or even c-client problem really.