https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6583
--- Comment #6 from Mark Martinec <[email protected]> 2011-05-09 17:06:14 UTC --- Some comments, before I forget: Considering that logging has three different back-ends internally (file, stderr and syslog) and that it has a documented open interface for third-party backends (which is used at least by amavisd-new to integrate SpamAssassin logging with its own), I'd prefer that each backend logger takes care of its own limitations, which may not be the same for each. For example a file-based logging may be happy with logging UTF-8 text, while the syslog may not be. A syslog backend may have line length limitations, while others may not. A concern with the amavisd backend logger is that it does its own sanitation of nonprintable characters, so if SpamAssassin does it at the common Logger.pm routine, we'd end up with doubled backslashes - not too bad, but ugly nevertheless. So I'd move the sanitation line from Logger.pm into Logger/*.pm modules. And perhaps the Logger/File.pm is a candidate for less strict sanitation, like allowing 8-bit characters through. Btw, the suggested s/// does not cope with character codes above 255, which may happen to find its way into a string being sanitized. Also the '\' is not being doubled, which means that the result is not uniquely reversible (if it happens that a '\nnn' is literally in a string). Perhaps something like the following would do: $str =~ s{([^\040-\176])} { $1 eq '\\' ? '\\\\' : sprintf(ord($1) > 255 ? '\\x{%04x}' : '\\%03o', ord($1)) }egs; An alternative for sanitizing strings with characters above 255 is to encode them first into utf-8, and only then \ooo -quote them. Not sure what subset of characters should be allow to pass through un-encoded in PerMsgStatus::get_content_preview(). -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
