Hello dennis, Friday, July 15, 2005, 10:08:56 PM, you wrote:
dsc> Ah, here is the From header: dsc> From: 360° Skin Care <[EMAIL PROTECTED]> dsc> Not 6 digits, but maybe the degree symbol is contributing. I'll advise not dsc> to start the username with 360°. Actually, that header is > From: =?iso-8859-1?b?MzYwsA==?= Skin Care <[EMAIL PROTECTED]> (where I replace the same username "info" with "xxxx" as you did). When I run the email you sent me offlist against SA 3.1.0, I get > X-Spam-Status: No, score=-1.2 required=5.0 > tests=ALL_TRUSTED,RCVD_IN_NJABL_DUL autolearn=ham > version=3.1.0-pre4-r208823 There's no sign of your FROM_STARTS_WITH_NUMS match there. The debug clearly shows > [31168] dbg: eval: all '*From' addrs: [EMAIL PROTECTED] which is what we expect. No leading digits in the username there. When I run the same test, the same email, against SA 3.0.3 here, I get > X-Spam-Status: No, score=3.2 required=5.0 > tests=AWL,FROM_STARTS_WITH_NUMS,HELO_DYNAMIC_DHCP,HELO_DYNAMIC_HCC, > HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL autolearn=no version=3.0.3 Your FROM_STARTS_WITH_NUMS is present. The debug shows the same > debug: all '*From' addrs: [EMAIL PROTECTED] So, yes, your problem is reproducible in version 3.0.3, and it also appears to be fixed (or at least it goes away) in version 3.1.0 I'm guessing that something about that iso-8859-1 encoding of the display name is causing the FRMO_STARTS_WITH_NUMS subroutine to get confused about where/what the username is in 3.0.3. Since it's fixed in 3.1.0, I choose not to dig any further than this. What you might want to suggest to your user is, for a while, to switch their From to something like > From: "360* Skin Care" <[EMAIL PROTECTED]> so there's no need for any encoding. In a month or so when SA 3.1.0 has been published and installed in the majority of SA sites, then they can go back to the encoding and the nice little degree sign, since the problem will have been fixed. Bob Menschel
