Digest delivery using EUC-JP

[Krystalz]

I have a set of servers, each of which run approximately 2,000 Mailman
lists.

We started receiving complaints from users on one of these particular
servers that they were unable to send digests.

After another technician and I went through the error logs, we found one
specific list which had an MBOX file for digests, but didn't have any users
which used digest mode. (digest was turned on). We moved the mbox
file, and within minutes all of the digests started to go through and the
problem went away.

We found this was the only of our lists which had digests turned on
(whether used or not), for all of our servers, which happened to be using
EUC-JP.

This was discussed on the MAILMAN-USERS group, and it was mentioned it
should be forwarded here. I am including a snippit of the conversation
below:

> > > I don't fully understand your situation but there is a common problem
in Japanese people who don't care (or ignorant) about 'machine dependent
characters' like number in circle or double width roman numerals. If
those characters are used in 'iso-2022-jp' declaration of charset, mailman
and python codecs fail to process such characters and single processes like
'cron/senddigests' stops working.

> > > My advice is to remove (or rename for later inspection) the
digest.mbox file from the Japanese list directory and set digestable=0 if
they keep using the 'machine dependent characters'.

> > > -Tokio

> > > Please file a bug report. I am just as frustrated as Kikuchi-san is
with the Japanese attitude toward standards, but this behavior of Mailman
is a violation of the Postel Principle ("be strict in what
you emit, but lax in what you accept"). Mailman functionality should
not be disabled by the contents of posts it handles; if it doesn't like
them, it should strip them or quarantine them without impeding the flow of
other posts.

> > > In the short run, you probably should disable digestible for that
list. Mailman's I18N is not very robust in this respect, and it may take
some time to fix. Tokio, is it possible that you could just default the
error policy for codecs as "replace" for charsets that are known to be
prone to "vendor extension"? And add an option for the set of
"replace-able" charsets
to be set by the list admin?

> > > -Stephen

[http://sourceforge.net/tracker/index.php?func=detail&aid=1698759&group_id=103&atid=100103]