Re: malformed To: header blocks further parsing
Il 06/06/13 11:51, Matteo Dessalvi ha scritto: Hi Fabio. Have you tried also the 'Language options' of SpamAssassin? Like the one described here: http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html#language_options Matteo Hi, thanks for your reply. I totally misunderstood SpamAssassin's rule description: it was referring to a NUL byte in the body, not to a body with a lenght of 0 bytes. SpamAssassin's parsing is working perfectly :) Thanks again, Fabio
Re: malformed To: header blocks further parsing
Hi Fabio. Have you tried also the 'Language options' of SpamAssassin? Like the one described here: http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html#language_options Matteo - Messaggio originale - Da: Fabio Sangiovanni A: users@spamassassin.apache.org Cc: Inviato: Mercoledì 5 Giugno 2013 12:26 Oggetto: malformed To: header blocks further parsing Hi everybody, I'm using spamassassin 3.3.2, along with postfix 2.6.6 and amavisd-new 2.8.0. The system spamassassin is running on is used primarily for URIDNSBL checks. Recently I had some messages classified as spam because of these rules: X-Spam-Report: * 1.2 TO_MALFORMED To: has a malformed address * 0.5 NULL_IN_BODY FULL: Message has NUL (ASCII 0) byte in message * 0.1 MISSING_MID Missing Message-Id: header * 1.8 MISSING_SUBJECT Missing Subject: header * 1.4 MISSING_DATE Missing Date: header The problem is that the body is not null at all, and headers aren't missing: what happens here is that the To: header contains chinese characters that are not in encoded word format and that interfere with spamassassin's parsing. This is a problem because the mail body can't be checked against other rules. Is there a way to fix this, other than changing MUA's behaviour to encode the message properly? How can I have spamassassin to parse the remaining part of the message in such conditions? Configuration follows (please let me know if you need further information): loaded plugins: loadplugin Mail::SpamAssassin::Plugin::URIDNSBL loadplugin Mail::SpamAssassin::Plugin::Check loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody local.cf: trusted_networks 192.168/16 internal_networks 192.168/16 skip_rbl_checks 1 use_learner 0 use_bayes 0 use_bayes_rules 0 bayes_auto_learn 0 score URIBL_SBL 5 score URIBL_DBL_SPAM 5 score URIBL_DBL_REDIR 5 score URIBL_DBL_ERROR 5 score URIBL_SC_SURBL 5 score URIBL_WS_SURBL 5 score URIBL_PH_SURBL 5 score URIBL_MW_SURBL 5 score URIBL_AB_SURBL 5 score URIBL_JP_SURBL 5 score URIBL_BLACK 0 score URIBL_RED 0 score URIBL_GREY 0 score URIBL_BLOCKED 0
malformed To: header blocks further parsing
Hi everybody, I'm using spamassassin 3.3.2, along with postfix 2.6.6 and amavisd-new 2.8.0. The system spamassassin is running on is used primarily for URIDNSBL checks. Recently I had some messages classified as spam because of these rules: X-Spam-Report: * 1.2 TO_MALFORMED To: has a malformed address * 0.5 NULL_IN_BODY FULL: Message has NUL (ASCII 0) byte in message * 0.1 MISSING_MID Missing Message-Id: header * 1.8 MISSING_SUBJECT Missing Subject: header * 1.4 MISSING_DATE Missing Date: header The problem is that the body is not null at all, and headers aren't missing: what happens here is that the To: header contains chinese characters that are not in encoded word format and that interfere with spamassassin's parsing. This is a problem because the mail body can't be checked against other rules. Is there a way to fix this, other than changing MUA's behaviour to encode the message properly? How can I have spamassassin to parse the remaining part of the message in such conditions? Configuration follows (please let me know if you need further information): loaded plugins: loadplugin Mail::SpamAssassin::Plugin::URIDNSBL loadplugin Mail::SpamAssassin::Plugin::Check loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody local.cf: trusted_networks 192.168/16 internal_networks 192.168/16 skip_rbl_checks 1 use_learner 0 use_bayes 0 use_bayes_rules 0 bayes_auto_learn 0 scoreURIBL_SBL5 scoreURIBL_DBL_SPAM5 scoreURIBL_DBL_REDIR5 scoreURIBL_DBL_ERROR5 scoreURIBL_SC_SURBL5 scoreURIBL_WS_SURBL5 scoreURIBL_PH_SURBL5 scoreURIBL_MW_SURBL5 scoreURIBL_AB_SURBL5 scoreURIBL_JP_SURBL5 scoreURIBL_BLACK0 scoreURIBL_RED0 scoreURIBL_GREY0 scoreURIBL_BLOCKED0