Bug 6354 - Header ":name" modifier should only ever match a name
Summary: Header ":name" modifier should only ever match a name
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.3.0
Hardware: Other All
: P3 blocker
Target Milestone: 3.4.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-27 12:09 UTC by mouss
Modified: 2011-10-04 13:28 UTC (History)
3 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status
proposed patch patch None Mark Martinec [HasCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description mouss 2010-02-27 12:09:26 UTC
HK_NAME_FREE hits mail from free.fr (second french ISP) users. sample:

Return-Path: <php-return-74799-mouss=ml.netoyen.net@ml.ovh.net>
X-Relay-Countries: FR FR FR FR FR ** ** FR
X-Virus-Scanned: amavisd-new at netoyen.net
X-Spam-Flag: YES
X-Spam-Score: 5.042
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.042 required=5 tests=[COUNTRY_FR=0.01,
	GRDNS_IP4=0.1, HK_NAME_FREE=2.732, HTML_MESSAGE=0.001, S25R_3=2.199]
	autolearn=no
Received: from 66.mail-out.ovh.net (66.mail-out.ovh.net [91.121.185.67])
	by mx.netoyen.net (Postfix) with SMTP id 05BE3E548B4
	for <mouss@ml.netoyen.net>; Sat, 27 Feb 2010 12:43:08 +0100 (CET)
Received: (qmail 31603 invoked by uid 503); 27 Feb 2010 11:41:32 -0000
Received: from b7.ovh.net (HELO mail88.ha.ovh.net) (213.186.33.57)
  by 66.mail-out.ovh.net with SMTP; 27 Feb 2010 11:41:32 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
	by b0.ovh.net with SMTP; 27 Feb 2010 11:43:06 -0000
Mailing-List: Pour toute requete administrative, contactez php-help@ml.ovh.net; Liste geree par ezmlm
Precedence: bulk
X-No-Archive: yes
List-Post: <mailto:php@ml.ovh.net>
List-Help: <mailto:php-help@ml.ovh.net>
List-Unsubscribe: <mailto:php-unsubscribe@ml.ovh.net>
List-Subscribe: <mailto:php-subscribe@ml.ovh.net>
reply-to: php@ml.ovh.net
Delivered-To: mailing list php@ml.ovh.net
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
	by b0.ovh.net with SMTP; 27 Feb 2010 11:43:06 -0000
Received: from smtp3-g21.free.fr (212.27.42.3)
  by mx2.ovh.net with SMTP; 27 Feb 2010 11:43:04 -0000
Received: from smtp3-g21.free.fr (localhost [127.0.0.1])
	by smtp3-g21.free.fr (Postfix) with ESMTP id 7BBE1818119
	for <php@ml.ovh.net>; Sat, 27 Feb 2010 12:42:58 +0100 (CET)
Received: from zimbra5-e1.priv.proxad.net (zimbra5-e1.priv.proxad.net [172.20.243.155])
	by smtp3-g21.free.fr (Postfix) with ESMTP id A62CD818050
	for <php@ml.ovh.net>; Sat, 27 Feb 2010 12:42:56 +0100 (CET)
Date: Sat, 27 Feb 2010 12:42:55 +0100 (CET)
From: carlos.de.mones@free.fr
To: php@ml.ovh.net
Message-ID: <353813929.3253231267270975748.JavaMail.root@zimbra5-e1.priv.proxad.net>
In-Reply-To: <002801cab783$923e0fa0$b6ba2ee0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_108537_1186906016.1267270975747"
X-Originating-IP: [82.244.229.76]
X-Mailer: Zimbra 5.0 (ZimbraWebClient - FF3.0 (Mac)/5.0.15_GA_2815.UBUNTU8_64)
X-Authenticated-User: carlos.de.mones@free.fr
X-Ovh-Tracer-Id: 380554169998234514
X-Ovh-Remote: 212.27.42.3 (smtp3-g21.free.fr)
X-Ovh-Local: 213.186.33.45 (mx2.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Subject: =?utf-8?Q?Re:_[php]_d=C3=A9sinscription?=

------=_Part_108537_1186906016.1267270975747
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

J'ai le m=C3=AAme probl=C3=A8me !=20

...
Comment 1 Karsten Bräckelmann 2010-02-27 12:29:59 UTC
(In reply to comment #0)
> HK_NAME_FREE hits mail from free.fr (second french ISP) users. sample:

> From: carlos.de.mones@free.fr

Uh. The real problem here seems to be that in the case of an actually missing real name, From:name matches against the address, which it is not supposed to.

  header HK_NAME_FREE  From:name =~ /\b(?:get)?free\b/mi
Comment 2 Henrik Krohns 2010-02-27 13:05:54 UTC
Yep I would say that is certainly a bug. Some other rules also seem to assume it would only hit the name portion.
Comment 3 mouss 2010-02-27 13:20:06 UTC
(In reply to comment #2)
> Yep I would say that is certainly a bug. Some other rules also seem to assume
> it would only hit the name portion.

(In reply to comment #2)
> Yep I would say that is certainly a bug. Some other rules also seem to assume
> it would only hit the name portion.

I concur. tested a
    header TST_OVH  From:name =~ /\bovh\b/mi
and it hits
From: support@ovh.com


That said, even if this is fixed, HK_NAME_FREE will hit mail where users put there ISP in the display name:

From: joe \(free\) <joe@free.fr>

as well as

From: joe@free.fr <joe@free.fr>

Let me grep my mail for such things...
Comment 4 Karsten Bräckelmann 2010-02-27 13:47:43 UTC
Not a regression, though. :/  In the absence of a real name, From:name matches against the address. Same with 3.2.

This might even be correct, though unexpected, according to the documentation. "Appending :name to the header name will cause everything except the first real name to be removed from the header."

Priority P3, Severity normal.
Comment 5 Mark Martinec 2010-03-01 19:31:32 UTC
> Not a regression, though. :/  In the absence of a real name, From:name matches
> against the address. Same with 3.2.
> 
> This might even be correct, though unexpected, according to the documentation.
> "Appending :name to the header name will cause everything except the first real
> name to be removed from the header."

I can't see how that description could be interpreted as "in absence of a
real name, From:name matches against the address". I think the behaviour is
plain wrong and needs to be fixed to match the documentation, even if risking
bug-for-bug-compatibility.
Comment 6 Karsten Bräckelmann 2010-03-01 22:15:33 UTC
I didn't mean to justify current behavior, and absolutely agree that it is a bug. I wouldn't have bumped the Priority otherwise.

(That part of comment 4 was thinking out loud, whether splitting RFC hairs in order to come up with a smart-ass definition by which it possibly could be interpreted being correct would be possible.)
Comment 7 Henrik Krohns 2011-05-24 09:57:04 UTC
Should be fixed before 3.4
Comment 8 Mark Martinec 2011-09-23 13:31:40 UTC
> Should be fixed before 3.4

Fixed code and make docs consistent between Conf.pm and PerMsgStatus.pm:

trunk:
  Bug 6354: Header ":name" modifier should only ever match a name
Sending lib/Mail/SpamAssassin/Conf.pm
Sending lib/Mail/SpamAssassin/PerMsgStatus.pm
Committed revision 1174742.
Comment 9 Mark Martinec 2011-09-23 13:32:19 UTC
Created attachment 4970 [details]
proposed patch
Comment 10 Mark Martinec 2011-09-23 13:37:15 UTC
removed a debugging aid (Bug 6354)
  Sending lib/Mail/SpamAssassin/PerMsgStatus.pm
Committed revision 1174746.
Comment 11 Mark Martinec 2011-10-04 13:28:37 UTC
Closing. Fixed for trunk/3.4.0.