Re: Fake amavisd-new header lines in recent spam
On 11/10/2014 02:32 AM, Rich Wales wrote: This *AXB_XRCVD_8B8* rule seems excessively broad to me. It seems it could wrongly catch e-mail that was legitimately Amavis-scanned on its way out by a server whose name just happened to be eight characters long. I think a better rule would take advantage of other anomalies with these fake header lines, such as the following: * There is an *extraneous semicolon* before the "for" clause. There should be only one semicolon in a "Received:" line -- namely, the one just before the date/time stamp. * There is *no "from" clause*. A valid "Received:" line from an amavisd-new scan will always have a "from" clause -- and further, I believe a valid "from" clause from amavisd-new will always reference "localhost". * The "Received:" line from a real amavisd-new scan *shouldn't be the chronologically first* (physically last) "Received:" line. The first "Received:" line (time-wise) happens when a message is initially delivered to the local mail software; a genuine outbound amavisd-new scan will generate the chronologically *second* (physically second-to-last) "Received:" line. * The *port number is strange*. While it is not absolutely mandatory for an amavisd-new installation to use port 10024, I believe it is pretty much unheard of for amavisd-new to be set up to listen on ports like 7693, 7686, 7684, or 17196. Here is a sample rule which will detect the extraneous semicolon. header BOGUS_RCVD_AMAVIS Received =~ /\(amavisd-new,\s+port\s+\d+\).+;\s*for\b/ do we have your permission to add this rule to SA's masscheck / autopromoting ?
Re: Fake amavisd-new header lines in recent spam
This *AXB_XRCVD_8B8* rule seems excessively broad to me. It seems it could wrongly catch e-mail that was legitimately Amavis-scanned on its way out by a server whose name just happened to be eight characters long. I think a better rule would take advantage of other anomalies with these fake header lines, such as the following: * There is an *extraneous semicolon* before the "for" clause. There should be only one semicolon in a "Received:" line -- namely, the one just before the date/time stamp. * There is *no "from" clause*. A valid "Received:" line from an amavisd-new scan will always have a "from" clause -- and further, I believe a valid "from" clause from amavisd-new will always reference "localhost". * The "Received:" line from a real amavisd-new scan *shouldn't be the chronologically first* (physically last) "Received:" line. The first "Received:" line (time-wise) happens when a message is initially delivered to the local mail software; a genuine outbound amavisd-new scan will generate the chronologically *second* (physically second-to-last) "Received:" line. * The *port number is strange*. While it is not absolutely mandatory for an amavisd-new installation to use port 10024, I believe it is pretty much unheard of for amavisd-new to be set up to listen on ports like 7693, 7686, 7684, or 17196. Here is a sample rule which will detect the extraneous semicolon. header BOGUS_RCVD_AMAVIS Received =~ /\(amavisd-new,\s+port\s+\d+\).+;\s*for\b/ -- *Rich Wales* Palo Alto, CA ri...@richw.org
Re: URIBL_RHS_DOB #fail
Hi, * 1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old * [URIs: bestwestern.com] I looked around for a place to report an FP, but also thought everyone else should know about this, since it's so obviously incorrect. Their whois looks like the record was updated on the 31st. Not exactly a day ago, but could that even have something to do with it? DOB owner has been notifed. I think DOB was having a "bad hair day" this morning. I saw a number of FP hits on DOB for stuff that hadn't changed in years (EG amtrak.com ). It looks better now. When you see DOB do something like that do dig A yahoo.com.dob.sibl.support-intelligence.net if it replies with 127.0.0.2 - disable the rule and please report to the list. Thanks for your help, guys. Alex
Re: URIBL_RHS_DOB #fail
On 11/09/2014 11:51 PM, Dave Funk wrote: On Sun, 9 Nov 2014, Axb wrote: On 11/09/2014 09:51 PM, Alex Regan wrote: Hi guys, One of my user's hotel reservations almost got tagged incorrectly: * 1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: bestwestern.com] I looked around for a place to report an FP, but also thought everyone else should know about this, since it's so obviously incorrect. Their whois looks like the record was updated on the 31st. Not exactly a day ago, but could that even have something to do with it? DOB owner has been notifed. I think DOB was having a "bad hair day" this morning. I saw a number of FP hits on DOB for stuff that hadn't changed in years (EG amtrak.com ). It looks better now. When you see DOB do something like that do dig A yahoo.com.dob.sibl.support-intelligence.net if it replies with 127.0.0.2 - disable the rule and please report to the list. Axb
Re: URIBL_RHS_DOB #fail
On Sun, 9 Nov 2014, Axb wrote:
On 11/09/2014 09:51 PM, Alex Regan wrote:
Hi guys,
One of my user's hotel reservations almost got tagged incorrectly:
* 1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
* [URIs: bestwestern.com]
I looked around for a place to report an FP, but also thought everyone
else should know about this, since it's so obviously incorrect.
Their whois looks like the record was updated on the 31st. Not exactly a
day ago, but could that even have something to do with it?
DOB owner has been notifed.
I think DOB was having a "bad hair day" this morning. I saw a number of
FP hits on DOB for stuff that hadn't changed in years (EG amtrak.com ).
It looks better now.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: URIBL_RHS_DOB #fail
On 11/09/2014 11:20 PM, Axb wrote: On 11/09/2014 09:51 PM, Alex Regan wrote: Hi guys, One of my user's hotel reservations almost got tagged incorrectly: * 1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: bestwestern.com] I looked around for a place to report an FP, but also thought everyone else should know about this, since it's so obviously incorrect. Their whois looks like the record was updated on the 31st. Not exactly a day ago, but could that even have something to do with it? DOB owner has been notifed. fixed host -tA bestwestern.com.dob.sibl.support-intelligence.net Host bestwestern.com.dob.sibl.support-intelligence.net not found: 3(NXDOMAIN)
Re: URIBL_RHS_DOB #fail
On 11/09/2014 09:51 PM, Alex Regan wrote: Hi guys, One of my user's hotel reservations almost got tagged incorrectly: * 1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: bestwestern.com] I looked around for a place to report an FP, but also thought everyone else should know about this, since it's so obviously incorrect. Their whois looks like the record was updated on the 31st. Not exactly a day ago, but could that even have something to do with it? DOB owner has been notifed.
RE: Fake amavisd-new header lines in recent spam
>Yeah they tried a similar trick with MailScanner years ago, basically dont >trust someone elses mail to tell the truth as per usual You are right about trust, but in this case we can detect fake amavis-headers and score bigtime in a safe way. And from what I can tell from my logs it hits really hard. /MJ
Re: Fake amavisd-new header lines in recent spam
Yeah they tried a similar trick with MailScanner years ago, basically dont trust someone elses mail to tell the truth as per usual On Sunday, 9 November 2014, Marieke Janssen wrote: > >hitting like crazy and safe > > Confirmed, thank you. > > /MJ > > -- -- Martin Hepworth, CISSP Oxford, UK
RE: Fake amavisd-new header lines in recent spam
>hitting like crazy and safe Confirmed, thank you. /MJ
URIBL_RHS_DOB #fail
Hi guys, One of my user's hotel reservations almost got tagged incorrectly: * 1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: bestwestern.com] I looked around for a place to report an FP, but also thought everyone else should know about this, since it's so obviously incorrect. Their whois looks like the record was updated on the 31st. Not exactly a day ago, but could that even have something to do with it? Thanks, Alex
Re: Fake amavisd-new header lines in recent spam
On 11/09/2014 06:59 PM, Axb wrote: On 11/09/2014 06:45 PM, Rich Wales wrote: Hi. Recently, I've noticed that some spam arriving on my mail server contains a "Received:" header line citing amavisd-new -- possibly an attempt to trick spam filters into concluding the message has already been scanned and is presumably free of problems. Here is an example of one of these -- the physically last (i.e., chronologically first) "Received:" in the message. Received: by 03112d50.rn56dss9.lunafutral.com (amavisd-new, port 9150) with ESMTP id 03MBRTVHDVT112DXUHRJKRWD50; for ; Sat, 8 Nov 2014 17:41:05 -0700 The above line contains several clues that can distinguish it from a real "Received:" line generated by amavisd-new, so I imagine a rule could be created to detect this and increase a message's spam score accordingly. Should I go ahead and discuss this in greater depth here on this list? Or would it be better to go off-list with a smaller group of developers, so as not to give too many ideas to the black hats? :-) rule is sandbox waiting to be promoted http://svn.apache.org/repos/asf/spamassassin/trunk/rulesrc/sandbox/axb/20_axb_misc.cf AXB_XRCVD_8B8 hitting like crazy and safe http://ruleqa.spamassassin.org/20141108-r1637525-n/AXB_XRCVD_8B8/detail pick it up from the sandbox and score it as high as you want.
Re: Fake amavisd-new header lines in recent spam
On 11/09/2014 06:45 PM, Rich Wales wrote: Hi. Recently, I've noticed that some spam arriving on my mail server contains a "Received:" header line citing amavisd-new -- possibly an attempt to trick spam filters into concluding the message has already been scanned and is presumably free of problems. Here is an example of one of these -- the physically last (i.e., chronologically first) "Received:" in the message. Received: by 03112d50.rn56dss9.lunafutral.com (amavisd-new, port 9150) with ESMTP id 03MBRTVHDVT112DXUHRJKRWD50; for ; Sat, 8 Nov 2014 17:41:05 -0700 The above line contains several clues that can distinguish it from a real "Received:" line generated by amavisd-new, so I imagine a rule could be created to detect this and increase a message's spam score accordingly. Should I go ahead and discuss this in greater depth here on this list? Or would it be better to go off-list with a smaller group of developers, so as not to give too many ideas to the black hats? :-) rule is sandbox waiting to be promoted http://svn.apache.org/repos/asf/spamassassin/trunk/rulesrc/sandbox/axb/20_axb_misc.cf AXB_XRCVD_8B8
Fake amavisd-new header lines in recent spam
Hi. Recently, I've noticed that some spam arriving on my mail server contains a "Received:" header line citing amavisd-new -- possibly an attempt to trick spam filters into concluding the message has already been scanned and is presumably free of problems. Here is an example of one of these -- the physically last (i.e., chronologically first) "Received:" in the message. Received: by 03112d50.rn56dss9.lunafutral.com (amavisd-new, port 9150) with ESMTP id 03MBRTVHDVT112DXUHRJKRWD50; for ; Sat, 8 Nov 2014 17:41:05 -0700 The above line contains several clues that can distinguish it from a real "Received:" line generated by amavisd-new, so I imagine a rule could be created to detect this and increase a message's spam score accordingly. Should I go ahead and discuss this in greater depth here on this list? Or would it be better to go off-list with a smaller group of developers, so as not to give too many ideas to the black hats? :-) Rich Wales ri...@richw.org
Re: FPs on URI_HEX & NUMERIC_HTTP_ADDR
On Sun, 9 Nov 2014, David B Funk wrote:
For NUMERIC_HTTP_ADDR the rule is: /^https?\:\/\/\d{7}/is
If that pattern were terminated like:
/^https?\:\/\/\d{7}(?::\d+)?(?:\/|$)/is
it should prevent the FPs (hopefully with out destroying its effectiveness)
Oops, for that new formulation it would actually need to be:
/^https?\:\/\/\d{7,10}(?::\d+)?(?:\/|$)/is
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
FPs on URI_HEX & NUMERIC_HTTP_ADDR
Recently I've seen a bunch of FPs on URI_HEX & NUMERIC_HTTP_ADDR thanks to some
URLs that look like:
https : // 4490379 . fls . doubleclick . net / activityi
(extra spaces my addition, remove to see actual URL)
These were embedded in some amtrack ticket confirmation messages. Looking
at my logs, I see that the recent S/O ratios for those two rules have
dropped below 0.5 (IE now hit more ham than spam).
For NUMERIC_HTTP_ADDR the rule is: /^https?\:\/\/\d{7}/is
If that pattern were terminated like:
/^https?\:\/\/\d{7}(?::\d+)?(?:\/|$)/is
it should prevent the FPs (hopefully with out destroying its effectiveness)
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: OT: parking-nameservers
On 11/09/2014 08:03 AM, Robert Schetterer wrote: Am 08.11.2014 um 21:11 schrieb Reindl Harald: slightly OT but don't know a better list - has somebody a larger list of parking-only nameservers than below? sadly you find easily parking companies but not the dedicated nameservers or a clear information if they are *really* used only for the parked domains __ check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf ns1.sedoparking.com REJECT Domain is parked at sedo.com ns2.sedoparking.com REJECT Domain is parked at sedo.com ns1.fastpark.net REJECT Domain is parked at namedrive.com ns2.fastpark.net REJECT Domain is parked at namedrive.com these are safe to use, no false positive since years a.ns.ultsearch.com REJECT Domain is parked at a.ns.ultsearch.com b.ns.ultsearch.com REJECT Domain is parked at b.ns.ultsearch.com dont know about these take a look at buy.internettraffic.com sell.internettraffic.com
