Hi Klaus, Am 2017-01-15 um 17:43 schrieb Klaus Ethgen: > Hi Willi, > > Am Sa den 14. Jan 2017 um 16:43 schrieb Willi Mann: >> in order to come closer to a fix for this issue, I propose the following >> two patches: > > >> 0001-Add-outputencoding-parameter.patch > >> This patch allows to configure the value for the charset in the >> Content-Type line in mail output. This should address Klaus Ethgen's >> original concern. > > Well, partly. It will, in fact, let me configure it the way, that it > solves my issue. > > However, It does not fix the issue itself as it does not ensure that the > output in mail is that charset. As I mentioned before, this is exactly > the issue. The mail could be easily in UTF-8. But then there has to be > logic to keep sure that the mail is in that charset. Without, you could > still end with logical incorrect mails that are (partly) in different > charsets that is illegal for UTF-8.
I understand that the illegal UTF-8 is bad. But I have to admit that I'm not yet sure why it is bad in terms of security, especially since we are talking about mail - and anyone could send you an e-mail with illegal UTF-8 sequences. >> Since most people use UTF-8, I left the default at UTF-8. > > No objection about that. But you cannot be sure that log stuff is in the > same charset. Yeah, that I'm aware of. >> 0002-Use-pager-on-stdout-output-to-terminal.patch > [...] >> Let me know what you think about these patches. > > Patches looks good for me for fixing the bug partly. Nevertheless I > would expect some use of iconv for really ensure the choosed charset. > Maybe even encguess can come to use for guessing the input. Does anybody have a good idea on how to implement this? Concerning the second part (guessing the input encoding), I'm not really sure at what point logwatch should try to guess and assume a particular charset. Especially for the first part, does anybody know some example code? Maybe some other project that had to solve the same issue in Perl? Willi
