SA Bugzilla – Bug 6354
Header ":name" modifier should only ever match a name
Last modified: 2011-10-04 13:28:37 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 ...
(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
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. (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...
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.
> 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.
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.)
Should be fixed before 3.4
> 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.
Created attachment 4970 [details] proposed patch
removed a debugging aid (Bug 6354) Sending lib/Mail/SpamAssassin/PerMsgStatus.pm Committed revision 1174746.
Closing. Fixed for trunk/3.4.0.