Matt Kettler написа:
Милен Панков wrote:
Hi to all,
I'm using spamassassin for years without any serious problems.
First: In my answer's I'm assuming you are running 3.1.0 or higher. If you
aren't please specify your version.
Yes, it's 3.1.0, sorry
Except for one. My users write messages mostly in bulgarian and the
'SUBJ_ILLEGAL_CHARS' rule very often stops good mail.
I have put in my local.cf the line 'ok_languages bg en', but it doesn't
fix the problem.
No, if anything that will make your problem WORSE. The default here is "all". By
declaring an ok_languages you're limiting the number of acceptable languages.
Also note: this won't do anything at all unless you've got the textcat plugin
loaded in your v310.pre
Ok. I'll have that in mind.
For now I made this rule not giving any scores and this
temporary fixes the problem. My question is how can I make it work
without disabling it. I may be need to say to spamassassin not to check
for specific encodings. For example there are at least 4 encodings my
users use for writing/receiving mail (Windows-1251, KOI8-R, KOI8-U,
UTF-8). How can I do that?
Note that SUBJ_ILLEGAL_CHARS is NOT concerned with what language or character
set is used. It is concerned about it not being encoded properly.
Per RFC specifications, all characters in email-headers that aren't in the
normal ascii ranges must be QP encoded. This rule is essentially detecting that
the sender used extended range character sets, but their email client neglected
to properly QP encode it.
Realistically, you have two options:
1) tell the sender their client isn't properly QP encoding Bulgarian
text in
the subject headers.
2) accept that many email clients don't properly handle Bulgarian text,
and
disable this rule by adding "score SUBJ_ILLEGAL_CHARS 0" to your local.cf.
Well this happens mostly when we receive mail from some webmails for
example Yahoo, so I'm stuck with the second option, which I'm already using.
Thanks,
Milen
