You'd need to convert that string using a program
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hil...@charite.de | http://www.charite.de
As far as I know such a transformation is the job of a MUA for example, it's
not the MTA's task to do things like this, so maybe postfix is unable to do
that, and it's right that way. It's matter of taste but I would be upset to
see non-ASCII chars in syslog files anyway, but it's my problem :)
I think some syslog servers supports to redirect the log into the stdin of a
program, so you can have "on-line" conversion with that way, though ... I am
using this to have own custom logging format without the need to convert the
log file after the log rotate (which requires double of the disk space and
you can have it only after you have the log file to process, so otherwise I
wouldn't have information in my own format but I must wait a day ...)
- logs are ASCII. This has always been the case.
- postfix logs text as it comes. This is what logging is for (write
"real" infos)
if you want to ease reading logs, then convert logs to whichever form
you prefer. a
tail -F $logfile |perl showmelogs.pl
will do...
It is technically not possible to store non-ASCII content in
"unencoded" form, without also storing information about the
character set of that content. Otherwise, you'd be rendering
text with the wrong alphabet.
So, we would be just inventing another way of doing what ?utf-8?badf..?
are doing. Instead of re-inventing the wheel, let's just stick with
the existing ones.
Wietse