Xavier De Cock wrote:
My patch was for 3.8.0
But this patch only change \n to \r\n... (or I missed something)
My patch add a . on line start if the first character of a line is a .
Because in SMTP Sending This: <<<EOT
Hello World, this is a line with a
. on first char of the second line
EOT;
Must be done this way:<<<EOS
Hello World, this is a line with a
.. on first char of the second line
.
EOS;
And, this wasn't done on the 3.8.0 (i reported the bug sometimes ago, i
don't know if the \n to \r\n "bug" was corrected)...
I will test my patch tomorrow on the internal server, and push it on
"production" one after a few tests, because this bug is a data loss bug,
and this can cause trouble (i have some reccurent bugs with very long
URL)
Yes, that was the issue. I got corrupted PDF files thanks to this. PDF
contains ./some/path/to/whereever paths in it and they got scrwed up
because of the dot issue.
But correcting the EOF's to conform to SMTP/LMTP ( both \r and \n must
be present during the communication) fixed that. It was called dot
stuffing IIRC. The receiving end (dbmail-lmtpd in my case), would not
unstuff the dots because of the so to say unfinished EOL.
So I guess what I'm saying is that dspam stuffed the dots (added the
extra .), but the receiving end did not removed it because the dot
unstuffing code tries to detect "\r\n.." and not "\n..".
So what you're saying is that dspam in 3.8.0 did NOT add the dots?
Because with 3.6.8 it works fine when the EOLs are fixed.
I have not used 3.8.0 yet.
Regards,
--
Aleksander Kamenik
system administrator
+372 6659 649
[EMAIL PROTECTED]
Krediidiinfo AS
http://www.krediidiinfo.ee/
