Bug 6184 - FN header exists eval rule fails if header is 0 (ZERO) so does regex
Summary: FN header exists eval rule fails if header is 0 (ZERO) so does regex
Status: RESOLVED DUPLICATE of bug 5965
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (Eval Tests) (show other bugs)
Version: 3.2.5
Hardware: Other All
: P3 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-25 05:58 UTC by Michael Scheidell
Modified: 2009-08-25 08:49 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Scheidell 2009-08-25 05:58:48 UTC 
using sa debug, on this rule:

header __ST_ISMMS exists:X-MMS-Message-Type

will also FN on THIS rule:
header __ST_ISMMS X-MMS-Message-Type =~ /./

and FN on this rule:
header __ST_ISMMS X-MMS-Message-Type =~ /0/


(why does a 'zero' not be /./?)
a 1 is fine there, but not a zero?  does the header eval rules stip out a literal zero?


can see subrule hit in debug mode if header contains: (see subtests
X-Mms-Message-Type: 1

./sa-test.pl /tmp/RSbM-3pdTzIE.eml
__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART,__DOS_RCVD_MON,__DOS_RELAYED_EXT,
__FROM_ALL_NUMS,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAVE_BOUNCE_RELAYS,
__LAST_UNTRUSTED_RELAY_NO_AUTH,__MIME_VERSION,__MISSING_REF,__MSGID_OK_DIGITS,
__MSGID_OK_HEX,__NAKED_TO,__NO_REAL_NAME,__SANE_MSGID,__SARE_SPEC_SUBJ_LEO,
__SARE_WHITELIST_FLAG,__ST_ISMMS,__ST_ISMMS_SUBJECT,__TOCC_EXISTS
,__TVD_MIME_CT_MM



but nothing if:

X-Mms-Message-Type: 0

./sa-test.pl /tmp/RSbM-3pdTzIE.eml
__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART,__DOS_RCVD_MON,__DOS_RELAYED_EXT
,__FROM_ALL_NUMS,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAVE_BOUNCE_RELAYS,
__LAST_UNTRUSTED_RELAY_NO_AUTH,__MIME_VERSION,__MISSING_REF,__MSGID_OK_DIGITS,
__MSGID_OK_HEX,__NAKED_TO,__NO_REAL_NAME,__SANE_MSGID,__SARE_SPEC_SUBJ_LEO,
__SARE_WHITELIST_FLAG,__ST_ISMMS_SUBJECT,__TOCC_EXISTS,__TVD_MIME_CT_MM


using this set of headers to test:

Received: from atlmtaow02.cingularme.com (atlmtaow02.cingularme.com [66.102.165.7])
        by mx1.comprehensive.cc.spammertrap.net (Postfix) with ESMTP id 3EE131CC09C
        for <auser@domain.com>; Mon, 24 Aug 2009 10:16:49 -0400 (EDT)
X-Mms-MMS-Version: 18
Date: Mon, 24 Aug 2009 09:25:45 -0500
X-Nokia-Ag-Internal: ; smiltype=true; internaldate=1251123945625
Content-Type: multipart/mixed;  boundary="----=_Part_5643167_20618687.1251123945631"
X-Mms-Delivery-Report: 0
Received: from schagw01 ([209.183.32.189]) by atlmtaow02.cingularme.com
        (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20090824141645.NGJT6063.atlmtaow02.cingularme.com@schagw01> for
        <auser@domain.com>; Mon, 24 Aug 2009 10:16:45 -0400
X-Mms-Transaction-ID: MMS0000524776255
From: <999000000@mms.att.net>
To: auser@domain.com
X-Mms-Message-Class: 0
X-Mms-Read-Reply: 1
Mime-Version: 1.0
Message-ID: <21666699.1251123945632.JavaMail.wluser@schagw01>
X-Mms-Priority: 1
X-Mms-Message-Type: 0
Subject: Multimedia message
X-Nokia-Ag-Version: 2.0
Comment 1 Mark Martinec 2009-08-25 06:24:19 UTC 
I believe this is a duplicate for Bug 5965,
and is fixed in 3.3.0.
Comment 2 Karsten Bräckelmann 2009-08-25 08:49:10 UTC 
Agreed.

*** This bug has been marked as a duplicate of bug 5965 ***