On Wed, 2007-02-21 at 15:29 +0100, Justin Mason wrote:
> actually I think this is already implemented in 3.2.0 -- see
> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4636 for details.

Nice.  This patch solves the message part problem.

With this, rules can be written in Unicode too.
A final change would be to let rules be written into other charserts.

Rule files are read separated.  A easy implementation would be to add a
file_charset option.  This option will advice the charset used by the
rule file like iso-8859-15 and be converted internally to unicode too if
and only if (IMO) normalize_charset option is set to 1.

-Raul Dias

> --j.
> 
> Raul Dias writes:
> > On Fri, 2007-02-16 at 15:35 +0000, Justin Mason wrote:
> > > Theo Van Dinter writes:
> > > > I'm assuming that there will be a Google Summer of Code 2007 going on, 
> > > > and
> > > > that the ASF will be involved again.  So it's a good time to start 
> > > > thinking
> > > > about things we'd like to put up as possible projects.
> > > > 
> > > > We still have a number of items from last year that we could use again.
> > > > Anything else that we'd like people to code up?
> > 
> > Another thing that might worth adding to GSC2007.
> > 
> > Internal Encoding/Charset used by SA.
> > 
> > I havent find anything like that, but that doesnt mean SA does not do
> > this already.  In this case sorry :)
> > 
> > Mail messages can have multiple encodings like ISO-8859-*, utf-8,
> > utf-16, windows-*, and so on.
> > 
> > Also, perl (unless set "use utf8") will default to the system encoding
> > like LC_CTYPE.
> > 
> > Rule writters needs a way to tell SA, which encoding their rules are.
> > 
> > This is not a real issue for english rule, but for other languages are,
> > like portugues, french, russian, chinese, japanese and so on.
> > 
> > The real problem is that a string in one encoding with special
> > characters is not the same in another encoding.
> > 
> > So, what is needed is:
> > 1 - a way to tell SA the encoding/charset used in some rules
> > 2 - SA convert the rules to an universal encoding internally 
> >     (e.g. utf-8/16).
> > 3 - Temporary reconvert to the message encoding/charset to proper match.
> > 
> > I really dont know if SA does somithing like this internally, but I
> > think it does not.
> > Doing this will require a considerable amount of work (so, gsc20007).
> > 
> > Without this kind of support, I see it will be easier in the future
> > spammers playing with charset to avoid specific rules.
> > 
> > -Raul Dias

Reply via email to