Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

UTF-8 Subject Logging

309 views
Skip to first unread message

Jim Smith

unread,
Apr 7, 2010, 5:52:56 AM4/7/10
to
Hi all,
 
I've enabled subject logging in my header checks so that I can see it in my mail logs, i.e-
 
header_checks.pcre contains /^Subject:/ WARN
Logging looks like - Apr 6 00:05:44 myserver.com postfix/cleanup[20484]: [ID 197553 mail.info] 4DC4E82: warning: header Subject: =?utf-8?B?UX..... (UTF-8 stuff in here)
 
How can I make it so that Subject: =?utf-8?B?UX..... is displayed correctly in it's native language? (in this case it's Chinese but it could be another language)
 
Jim.

Ralf Hildebrandt

unread,
Apr 7, 2010, 6:35:45 AM4/7/10
to
* Jim Smith <jim.sm...@gmail.com>:

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

Jim Smith

unread,
Apr 7, 2010, 6:53:02 AM4/7/10
to
Can it be done natively when writing to the maillog or do I need to copy the file elsewhere and then run a conversion tool across all the Subject fields to get the correct characters?
 
My maillogs are very large and I don't want to use resources converting them on the mail server, hence I'd copy them somewhere else before converting the Subject: string

Gábor Lénárt

unread,
Apr 7, 2010, 7:05:53 AM4/7/10
to
On Wed, Apr 07, 2010 at 07:52:56PM +1000, Jim Smith wrote:
[...]

> How can I make it so that Subject: =?utf-8?B?UX..... is displayed correctly
> in it's native language? (in this case it's Chinese but it could be another
> language)

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 ...)

mouss

unread,
Apr 7, 2010, 6:26:05 PM4/7/10
to
Jim Smith a �crit :

> Can it be done natively when writing to the maillog or do I need to copy
> the file elsewhere and then run a conversion tool across all the Subject
> fields to get the correct characters?
>
> My maillogs are very large and I don't want to use resources
> converting them on the mail server, hence I'd copy them somewhere else
> before converting the Subject: string
>

- 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...

Wietse Venema

unread,
Apr 7, 2010, 8:36:31 PM4/7/10
to
Jim Smith:

> Hi all,
>
> I've enabled subject logging in my header checks so that I can see it in my
> mail logs, i.e-
>
> header_checks.pcre contains /^Subject:/ WARN
> Logging looks like - Apr 6 00:05:44 myserver.com postfix/cleanup[20484]: [ID
> 197553 mail.info] 4DC4E82: warning: header Subject: =?utf-8?B?UX..... (UTF-8
> stuff in here)
>
> How can I make it so that Subject: =?utf-8?B?UX..... is displayed correctly
> in it's native language? (in this case it's Chinese but it could be another
> language)

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

0 new messages