You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Amir Caspi <ce...@3phase.com> on 2015/09/28 21:25:33 UTC
Add "may be forged" minor rule?
Hi all,
So, one of my users has been getting dozens of spams per day lately, that have been getting BAYES_999 but not triggering any other point rules. All of these spams have forge warnings in the Received header, and it seems like it might be worth adding a low-scoring "may be forged" rule... what do people think? (Apparently HTML_FONT_LOW_CONTRAST is only a placeholder when network tests are enabled? Not sure why, seems like it should be useful at all times.)
Two spamples:
http://pastebin.com/1AhK1DiU
http://pastebin.com/LVRy5Bu6
My user is apparently getting the first runs, before these servers have gotten onto the DNSBLs. Subsequent duplicate spams were properly caught by SA after the DNSBLs caught up, but the first waves get through.
Normally, I would hope that my URI templates would catch these. However, although the first one would be caught by one of my AC_SPAMMY_URI_PATTERNS subrules (specifically, __AC_STOPRANDDOM_URI, though not sure if this ever made it to distribution or not) now that I've added the new TLDs to that rule, the second spample will specifically bypass this rule because of the extra subdirectory. I could start adding additional subdirectory checks to that rule, but it's already so ungainly when checking for the domains literally, and I'm worried about FPs if checking for "any" subdirectory. (Yes, I could just blacklist those TLDs, but I'd prefer avoiding the nuclear option unless that's the only option.)
(1) The only pattern I've noticed that's common to all of these spams is that the Received line includes a "(may be forged)" warning. SA doesn't seem to have a rule for this. Would it be worthwhile adding something like 0.1 or 0.2 points for such warnings? Although I know ham can also include this warning, such a low score normally wouldn't cause FPs, but when combined with BAYES_99 + BAYES_999, should be enough to push it over the edge. Does anyone see any potential downside to this? Would people be interested in making such a rule standard?
(2) Does anyone have any better rules that might hit on these spammy templates? So far, besides the URI scheme, I haven't really found good patterns, except for the forge warning in the Received header. There's a lot of the "repeated numerical identifier" in the random "Bayes-poison" text at the bottom (yes, I know it doesn't really work well as Bayes poison, I just can't think of another name for it), but SA doesn't have a good way of checking for that kind of pattern. Some of them use a lot of # or = or - or whatever to create line breaks, but that's also not uniform and could be fodder for FPs. Has anyone identified any other decent template identifiers against which to write rules?
(3) Should HTML_FONT_LOW_CONTRAST become a higher-scoring rule when network tests are enabled? It only scores 0.001 now, maybe that should be upped to 0.1 instead? Wondering why it's a placeholder now, and scores only without network tests.
Thanks.
--- Amir
Re: Add "may be forged" minor rule?
Posted by RW <rw...@googlemail.com>.
On Mon, 28 Sep 2015 15:28:52 -0500 (CDT)
David B Funk wrote:
> In the OP's context "may be forged" indicates FCDNS failed. This
> could be due to a deliberate obfuscation attempt or a simple
> temporary network/DNS issue.
>
> The "Botnet" plugin will catch those as well as other kinds of
> DNS/hostname type indications and allow score adjustments.
And if you do test for "may be forged", make sure it only matches on
the MX received header.
Re: Add "may be forged" minor rule?
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 28 Sep 2015, John Hardin wrote:
> On Mon, 28 Sep 2015, Amir Caspi wrote:
>
>> My user is apparently getting the first runs, before these servers have
>> gotten onto the DNSBLs. Subsequent duplicate spams were properly caught by
>> SA after the DNSBLs caught up, but the first waves get through.
>
> Is greylisting an acceptable option in your environment?
>
> Also: both of those samples have URIs and From addresses using unusual new
> TLDs. You might want to add something like this:
>
> header FROM_RARE_TLD From:addr =~
> /\.(?:work|space|club|science|pub|red|blue|green|link|ninja|lol|xyz|faith|review)>?$/i
> describe FROM_RARE_TLD From address in rarely-nonspam TLD
> score FROM_RARE_TLD 3.000
>
> uri URI_RARE_TLD
> m;://[^/]+\.(?:work|space|club|science|pub|red|blue|green|link|ninja|lol|xyz|faith|review)(?:/|\b);i
> describe URI_RARE_TLD URI refers to rarely-nonspam TLD
> score URI_RARE_TLD 3.000
>
> (I've yet to add these to my sandbox.)
>
>
> IME "may be forged" in a Received header refers to the fact that an untrusted
> user was running sendmail to submit the message. I don't know how good a spam
> sign it is by itself, but in concert with BAYES_999 and/or URI_RARE_TLD it
> would probably be worthwhile.
>
In the OP's context "may be forged" indicates FCDNS failed. This could be due to
a deliberate obfuscation attempt or a simple temporary network/DNS issue.
The "Botnet" plugin will catch those as well as other kinds of DNS/hostname type
indications and allow score adjustments.
I'll second John's suggestion on rules to add points for off-beat TLDs. I don't
score them quite so heavily but have a larger collection of names and regularly
add to them.
They're also useful in metas with other things. (EG: BAYES_99 && OFFBEAT_TLDs )
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Add "may be forged" minor rule?
Posted by Amir Caspi <ce...@3phase.com>.
On Sep 28, 2015, at 10:17 PM, David B Funk <db...@engineering.uiowa.edu> wrote:
> By itself not a strong spam sign, but good for metas.
FWIW, I added this is a rule with 0.2 points. "Unfortunately," my user's snowshoe hits today have all been hitting RDNS_NONE instead of this rule, so I can't quite gauge its effectiveness. RDNS_NONE has enough points to push these snowshoes over the threshold, which is nice... hopefully this new rule will accomplish the same.
Might I recommend to KAM to include a RCVD_MAY_BE_FORGED rule with low (e.g., 0.2) points into the sandbox and test it against the corpus, to see whether it's worth keeping as a regular rule? RW recommended having this hit only on the MX server Rec'd header but I don't know if that's possible with a generic rule within SA's current framework. (e.g., is there a global variable that can hold the MX server, or list of MX servers, that can be evaluated within the RE?)
Thanks.
--- Amir
Re: Add "may be forged" minor rule?
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 28 Sep 2015, Amir Caspi wrote:
[snip..]
> AFAIK the "may be forged" indicates that rDNS lookup on the sending IP did not match the HELO information provided by the client, and wasn't specific to trusted or untrusted users. Is that not the case?
>
> Using it alone definitely would be a recipe for FP, because I've seen plenty of ham with this. However, I was thinking maybe scoring it 0.1 or 0.2 points, which would then be sufficient when added to BAYES_99 + BAYES_999 to knock an otherwise-non-scoring spam over the threshold. I guess it could be meta-ruled for additional protection.
>
> Would something like this be sufficient, or should I make the RE more stringent?
>
> # Add spamminess to "may be forged" warning in Received header
> header RCVD_MAY_BE_FORGED Received =~ /\(may be forged\)/
> describe RCVD_MAY_BE_FORGED Fake HELO info in Received header
> score RCVD_MAY_BE_FORGED 0.2
No, as created/used by sendmail that "may be forged" message only relates to the
sending MTA's DNS data. It means that the full-circle-DNS info for the sending
MTA's IP-addr didn't match (IP-addr -rDNS-> host.FQDN -fDNS-> IP-addr).
It has nothing to do with the HELO information.
That can be due to anything from deliberate obfuscation to a simple temporary
net/DNS glitch. Often caused by an ISP/MSP who is too lazy to maintain their DNS
infrastructure correctly.
By itself not a strong spam sign, but good for metas.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Add "may be forged" minor rule?
Posted by RW <rw...@googlemail.com>.
On Mon, 28 Sep 2015 17:29:15 -0700
Dave Warren wrote:
> You might also want to see if you can avoid greylisting some big
> senders. There is zero advantage in greylisting Google, Outlook.com,
> Outlook 365, Yahoo, AOL, etc, as you know they're real mail servers
> and you know they will retry. For senders that send a large amount of
> good mail, content filtering is worthwhile, but greylisting won't do
> anything but potentially delay legitimate traffic.
That's not entirely true because there's scope for URIs and deep IP
addresses to get listed during the delay, and Bayes to learn from
spamtrap addresses.
Re: Add "may be forged" minor rule?
Posted by Dave Warren <da...@hireahit.com>.
On 2015-09-28 14:39, David Jones wrote:
> I thought the same thing so I eased it in with the sqlgrey discrimination
> option. My users never even knew I implemented it since I went live on
> a Friday evening. I filter for almost 100,000 mailboxes and zero complaints
> from users, just a lot less reports of spam to our support mailbox.
One other trick you can use, if you haven't already considered it and
are starting a fresh implementation, see if you can "prime" the database
by feeding recent history into the greylist "approved" list before you
start. Or if not, start with a 1 second greylist period for the first
couple weeks, such that any retry gets through, then raise it to a more
reasonable number once your greylist database has a more useful picture
of the type of mail you receive.
> You could use the discrimination to just start with those rare 4 letter
> and longer TLDs and ease into it.
I've had good success by only triggering greylisting if a session is
already suspicious in some fashion. My current criteria are:
- EHLO or rDNS mismatch.
- SPF fail or softfail.
- DKIM headers exist, but don't validate.
- SpamAssassin score over 4.9.
- "Suspicious" TLD (a moving target, I admit).
- Any DNSBL hit.
Some of these are applied at RCPT TO time, some not until DATA, but none
of these are candidates to reject mail outright, just to run it through
greylisting. If greylisting decides to let it through, it will get
accepted, but if not, maybe a 30 minute cool down period will be enough
for other DNSBLs or bayes to be ready to reject it outright.
You might also want to see if you can avoid greylisting some big
senders. There is zero advantage in greylisting Google, Outlook.com,
Outlook 365, Yahoo, AOL, etc, as you know they're real mail servers and
you know they will retry. For senders that send a large amount of good
mail, content filtering is worthwhile, but greylisting won't do anything
but potentially delay legitimate traffic.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: Add "may be forged" minor rule?
Posted by David Jones <dj...@ena.com>.
________________________________________
>From: Reindl Harald <h....@thelounge.net>
>Sent: Monday, September 28, 2015 3:11 PM
>To: users@spamassassin.apache.org
>Subject: Re: Add "may be forged" minor rule?
>Am 28.09.2015 um 22:04 schrieb Amir Caspi:
>> On Sep 28, 2015, at 1:53 PM, John Hardin <jh...@impsec.org> wrote:
>>
>> Is greylisting an acceptable option in your environment?
>>
> Probably not. I've got some users who would not accept it. I'm thinking
>of implementing it anyway, but right now, not a viable option
I thought the same thing so I eased it in with the sqlgrey discrimination
option. My users never even knew I implemented it since I went live on
a Friday evening. I filter for almost 100,000 mailboxes and zero complaints
from users, just a lot less reports of spam to our support mailbox.
You could use the discrimination to just start with those rare 4 letter
and longer TLDs and ease into it.
>depending on your MTA just order greylisting *after* SPF and DNSWL's
>we do the same for HELO/PTR policies with no delays / FP's
>yes, we are speaking here about the layer long before SA
This is the best thing you can do to block zero-hour and compromised
account spam before the sending IP becomes listed on enough RBLs
to actually get blocked.
Re: Add "may be forged" minor rule?
Posted by Reindl Harald <h....@thelounge.net>.
Am 28.09.2015 um 22:04 schrieb Amir Caspi:
> On Sep 28, 2015, at 1:53 PM, John Hardin <jh...@impsec.org> wrote:
>
>> Is greylisting an acceptable option in your environment?
>
> Probably not. I've got some users who would not accept it. I'm thinking of implementing it anyway, but right now, not a viable option
depending on your MTA just order greylisting *after* SPF and DNSWL's
we do the same for HELO/PTR policies with no delays / FP's
yes, we are speaking here about the layer long before SA
Re: Add "may be forged" minor rule?
Posted by Adam Katz <an...@khopis.com>.
On 09/28/2015 02:55 PM, RW wrote:
> On Mon, 28 Sep 2015 14:27:33 -0700 (PDT) John Hardin wrote:
>>> # Add spamminess to "may be forged" warning in Received header
>>> header RCVD_MAY_BE_FORGED Received =~ /\(may be forged\)/
>>> describe RCVD_MAY_BE_FORGED Fake HELO info in Received header
>>> score RCVD_MAY_BE_FORGED 0.2
>> RE looks fine. I'd just describe it as "forgery warning in Received
>> header" rather than trying to interpret *why* the warning is there.
This has existed (in sandbox form, with stats) for quite a while:
header __MAY_BE_FORGED Received =~ /\(may be forged\)/
meta MAY_BE_FORGED __MAY_BE_FORGED && !__NOT_SPOOFED && !__VIA_ML
describe MAY_BE_FORGED Relay IP's reverse DNS does not resolve to IP
MSECS SPAM% HAM% S/O RANK SCORE NAME
0 1.3921 0.1703 0.891 0.65 0.01 T_MAY_BE_FORGED
0 1.4303 0.2045 0.875 0.64 (n/a) __MAY_BE_FORGED
So this isn't the strongest of spam indicators, at least in the general
case.
> YMMV but I find that in deep received headers "may be forged" is a
> slight ham indicator. That's why I suggested limiting the match to the
> MX server's received header.
It's a spam indicator on *some* /properly implemented/ mail
infrastructures. You need to test it on your own infrastructure to
ensure that sendmail and rDNS are playing nice together. If your
infrastructure /doesn't/ add this header (this is a sendmail thing
iirc), you do not want this type of rule. Even if it does, you have the
issue of external mail servers adding this header. That's why the above
meta rule excludes mailing lists.
-Adam
--
Adam Katz
@adamhotep <https://twitter.com/adamhotep>
Re: Add "may be forged" minor rule?
Posted by Amir Caspi <ce...@3phase.com>.
On Sep 28, 2015, at 3:55 PM, RW <rw...@googlemail.com> wrote:
>
> YMMV but I find that in deep received headers "may be forged" is a
> slight ham indicator. That's why I suggested limiting the match to the
> MX server's received header.
In that case it likely couldn't be a distributed rule, unless it could make use of trusted_networks or some similar setting to know which is the correct header... are you recommending keeping this a manual rule only?
Thanks.
--- Amir
thumbed via iPhone
Re: Add "may be forged" minor rule?
Posted by RW <rw...@googlemail.com>.
On Mon, 28 Sep 2015 14:27:33 -0700 (PDT)
John Hardin wrote:
e stringent?
> >
> > # Add spamminess to "may be forged" warning in Received header
> > header RCVD_MAY_BE_FORGED Received =~ /\(may be forged\)/
> > describe RCVD_MAY_BE_FORGED Fake HELO info in Received header
> > score RCVD_MAY_BE_FORGED 0.2
>
> RE looks fine. I'd just describe it as "forgery warning in Received
> header" rather than trying to interpret *why* the warning is there.
YMMV but I find that in deep received headers "may be forged" is a
slight ham indicator. That's why I suggested limiting the match to the
MX server's received header.
Re: Add "may be forged" minor rule?
Posted by John Hardin <jh...@impsec.org>.
On Mon, 28 Sep 2015, Amir Caspi wrote:
> On Sep 28, 2015, at 1:53 PM, John Hardin <jh...@impsec.org> wrote:
>
>> Is greylisting an acceptable option in your environment?
>
> Probably not. I've got some users who would not accept it. I'm
> thinking of implementing it anyway, but right now, not a viable option.
You can whitelist on a per-recipient basis, at least in the tool I use
(milter-greylist).
>> Also: both of those samples have URIs and From addresses using unusual
>> new TLDs. You might want to add something like this:
>
> I've adjusted the score of blacklist_uri_host down to only 3 points when
> Bayes is enabled, so blacklisting would effectively do the same as what
> you're suggesting, I think... maybe not handling the "From" part. But,
> as mentioned, I was hoping to find something that did not enable
> wholesale TLD trashing, although I do acknowledge that this is sometimes
> the best option.
>
>> IME "may be forged" in a Received header refers to the fact that an
>> untrusted user was running sendmail to submit the message. I don't know
>> how good a spam sign it is by itself, but in concert with BAYES_999
>> and/or URI_RARE_TLD it would probably be worthwhile.
>
> AFAIK the "may be forged" indicates that rDNS lookup on the sending IP
> did not match the HELO information provided by the client, and wasn't
> specific to trusted or untrusted users. Is that not the case?
I'm working off rusty memory, but I don't think this specific annotation
rDNS-related, at least in Sendmail.
> Using it alone definitely would be a recipe for FP, because I've seen
> plenty of ham with this. However, I was thinking maybe scoring it 0.1 or
> 0.2 points, which would then be sufficient when added to BAYES_99 +
> BAYES_999 to knock an otherwise-non-scoring spam over the threshold. I
> guess it could be meta-ruled for additional protection.
>
> Would something like this be sufficient, or should I make the RE more stringent?
>
> # Add spamminess to "may be forged" warning in Received header
> header RCVD_MAY_BE_FORGED Received =~ /\(may be forged\)/
> describe RCVD_MAY_BE_FORGED Fake HELO info in Received header
> score RCVD_MAY_BE_FORGED 0.2
RE looks fine. I'd just describe it as "forgery warning in Received
header" rather than trying to interpret *why* the warning is there.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
You are in a maze of twisty little protocols,
all written by Microsoft.
----------------------------------------------------------------------
Re: Add "may be forged" minor rule?
Posted by Amir Caspi <ce...@3phase.com>.
On Sep 28, 2015, at 1:53 PM, John Hardin <jh...@impsec.org> wrote:
> Is greylisting an acceptable option in your environment?
Probably not. I've got some users who would not accept it. I'm thinking of implementing it anyway, but right now, not a viable option.
> Also: both of those samples have URIs and From addresses using unusual new TLDs. You might want to add something like this:
I've adjusted the score of blacklist_uri_host down to only 3 points when Bayes is enabled, so blacklisting would effectively do the same as what you're suggesting, I think... maybe not handling the "From" part. But, as mentioned, I was hoping to find something that did not enable wholesale TLD trashing, although I do acknowledge that this is sometimes the best option.
> IME "may be forged" in a Received header refers to the fact that an untrusted user was running sendmail to submit the message. I don't know how good a spam sign it is by itself, but in concert with BAYES_999 and/or URI_RARE_TLD it would probably be worthwhile.
AFAIK the "may be forged" indicates that rDNS lookup on the sending IP did not match the HELO information provided by the client, and wasn't specific to trusted or untrusted users. Is that not the case?
Using it alone definitely would be a recipe for FP, because I've seen plenty of ham with this. However, I was thinking maybe scoring it 0.1 or 0.2 points, which would then be sufficient when added to BAYES_99 + BAYES_999 to knock an otherwise-non-scoring spam over the threshold. I guess it could be meta-ruled for additional protection.
Would something like this be sufficient, or should I make the RE more stringent?
# Add spamminess to "may be forged" warning in Received header
header RCVD_MAY_BE_FORGED Received =~ /\(may be forged\)/
describe RCVD_MAY_BE_FORGED Fake HELO info in Received header
score RCVD_MAY_BE_FORGED 0.2
Thanks.
--- Amir
Re: Add "may be forged" minor rule?
Posted by John Hardin <jh...@impsec.org>.
On Mon, 28 Sep 2015, Amir Caspi wrote:
> My user is apparently getting the first runs, before these servers have
> gotten onto the DNSBLs. Subsequent duplicate spams were properly caught
> by SA after the DNSBLs caught up, but the first waves get through.
Is greylisting an acceptable option in your environment?
Also: both of those samples have URIs and From addresses using unusual new
TLDs. You might want to add something like this:
header FROM_RARE_TLD From:addr =~ /\.(?:work|space|club|science|pub|red|blue|green|link|ninja|lol|xyz|faith|review)>?$/i
describe FROM_RARE_TLD From address in rarely-nonspam TLD
score FROM_RARE_TLD 3.000
uri URI_RARE_TLD m;://[^/]+\.(?:work|space|club|science|pub|red|blue|green|link|ninja|lol|xyz|faith|review)(?:/|\b);i
describe URI_RARE_TLD URI refers to rarely-nonspam TLD
score URI_RARE_TLD 3.000
(I've yet to add these to my sandbox.)
IME "may be forged" in a Received header refers to the fact that an
untrusted user was running sendmail to submit the message. I don't know
how good a spam sign it is by itself, but in concert with BAYES_999 and/or
URI_RARE_TLD it would probably be worthwhile.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Where are my space habitats? Where is my flying car?
It's 2010 and all I got from the SF books of my youth
is the lousy dystopian government. -- perlhaqr
-----------------------------------------------------------------------
Re: Add "may be forged" minor rule?
Posted by Axb <ax...@gmail.com>.
On 09/28/2015 09:54 PM, Axb wrote:
> On 09/28/2015 09:49 PM, Amir Caspi wrote:
>> On Sep 28, 2015, at 1:34 PM, Axb <ax...@gmail.com> wrote:
>>
>>> you may need to start looking at a local RBL and start blocking IP
>>> ranges
>>>
>>> been blocking snowshoe from Baraka Streaming Technologies Inc
>>> 38.113.188.0/22 since 2014-06-18 - no complaints - ymmv
>>
>> Will look into it, but that doesn't really address my questions. It
>> would take care of this batch of snowshoe but I'm thinking more
>> generally. Would a "forged" rule be worthwhile, or not recommended
>> for some reason? (If low-scoring.) And why is HTML_FONT_LOW_CONTRAST
>> just a placeholder when network tests are enabled?
>>
>>> whois is your friend...
>>
>> Not sure how whois would have helped me here... the SOA for this IP
>> range is amanah.com, but that doesn't really tell me much.
>>
>> Thanks.
>
>
> you run whois on the IP...
>
> X-ClientAddr: 38.113.189.110
>
> take a look... way down...
>
> whois 38.113.189.110
>
>
>
>
> Found a referral to rwhois.cogentco.com:4321.
>
> %rwhois V-1.5:0010b0:00 rwhois.cogentco.com
> network:ID:NET4-2671BC0016
> network:Network-Name:NET4-2671BC0016
> network:IP-Network:38.113.188.0/22
> network:Postal-Code:M5H 4E7
> network:Country:CA
> network:City:Toronto
> network:Street-Address:157 Adelaide St W
> network:Org-Name:Baraka Streaming Technologies Inc.
> network:Tech-Contact:ZC108-ARIN
> network:Updated:2015-06-19 18:43:09
then you get hold of fast-rdns.pl from
http://www.spamshield.org/fast-rdns.pl
and use that to check ranges, and if you're lucky find all kinds of nice
muck before "listing"...
enough sauce for today .-)
Re: Add "may be forged" minor rule?
Posted by Axb <ax...@gmail.com>.
On 09/28/2015 09:49 PM, Amir Caspi wrote:
> On Sep 28, 2015, at 1:34 PM, Axb <ax...@gmail.com> wrote:
>
>> you may need to start looking at a local RBL and start blocking IP ranges
>>
>> been blocking snowshoe from Baraka Streaming Technologies Inc 38.113.188.0/22 since 2014-06-18 - no complaints - ymmv
>
> Will look into it, but that doesn't really address my questions. It would take care of this batch of snowshoe but I'm thinking more generally. Would a "forged" rule be worthwhile, or not recommended for some reason? (If low-scoring.) And why is HTML_FONT_LOW_CONTRAST just a placeholder when network tests are enabled?
>
>> whois is your friend...
>
> Not sure how whois would have helped me here... the SOA for this IP range is amanah.com, but that doesn't really tell me much.
>
> Thanks.
you run whois on the IP...
X-ClientAddr: 38.113.189.110
take a look... way down...
whois 38.113.189.110
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# http://www.arin.net/public/whoisinaccuracy/index.xhtml
#
#
# The following results may also be obtained via:
#
http://whois.arin.net/rest/nets;q=38.113.189.110?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
# start
NetRange: 38.0.0.0 - 38.255.255.255
CIDR: 38.0.0.0/8
NetName: COGENT-A
NetHandle: NET-38-0-0-0-1
Parent: ()
NetType: Direct Allocation
OriginAS: AS174
Organization: PSINet, Inc. (PSI)
RegDate: 1991-04-16
Updated: 2011-05-20
Comment: Reassignment information for this block can be found at
Comment: rwhois.cogentco.com 4321
Ref: http://whois.arin.net/rest/net/NET-38-0-0-0-1
OrgName: PSINet, Inc.
OrgId: PSI
Address: 2450 N Street NW
City: Washington
StateProv: DC
PostalCode: 20037
Country: US
RegDate:
Updated: 2015-06-04
Comment: rwhois.cogentco.com
Ref: http://whois.arin.net/rest/org/PSI
ReferralServer: rwhois://rwhois.cogentco.com:4321
OrgNOCHandle: ZC108-ARIN
OrgNOCName: Cogent Communications
OrgNOCPhone: +1-877-875-4311
OrgNOCEmail: noc@cogentco.com
OrgNOCRef: http://whois.arin.net/rest/poc/ZC108-ARIN
OrgAbuseHandle: COGEN-ARIN
OrgAbuseName: Cogent Abuse
OrgAbusePhone: +1-877-875-4311
OrgAbuseEmail: abuse@cogentco.com
OrgAbuseRef: http://whois.arin.net/rest/poc/COGEN-ARIN
OrgTechHandle: IPALL-ARIN
OrgTechName: IP Allocation
OrgTechPhone: +1-877-875-4311
OrgTechEmail: ipalloc@cogentco.com
OrgTechRef: http://whois.arin.net/rest/poc/IPALL-ARIN
RTechHandle: PSI-NISC-ARIN
RTechName: IP Allocation
RTechPhone: +1-877-875-4311
RTechEmail: ipalloc@cogentco.com
RTechRef: http://whois.arin.net/rest/poc/PSI-NISC-ARIN
# end
# start
NetRange: 38.112.0.0 - 38.119.255.255
CIDR: 38.112.0.0/13
NetName: COGENT-NB-0002
NetHandle: NET-38-112-0-0-1
Parent: COGENT-A (NET-38-0-0-0-1)
NetType: Reallocated
OriginAS:
Organization: PSINet, Inc. (PSI)
RegDate: 2003-08-20
Updated: 2004-03-11
Comment: ReferralServer: rwhois://rwhois.cogentco.com:4321/
Ref: http://whois.arin.net/rest/net/NET-38-112-0-0-1
OrgName: PSINet, Inc.
OrgId: PSI
Address: 2450 N Street NW
City: Washington
StateProv: DC
PostalCode: 20037
Country: US
RegDate:
Updated: 2015-06-04
Comment: rwhois.cogentco.com
Ref: http://whois.arin.net/rest/org/PSI
ReferralServer: rwhois://rwhois.cogentco.com:4321
OrgNOCHandle: ZC108-ARIN
OrgNOCName: Cogent Communications
OrgNOCPhone: +1-877-875-4311
OrgNOCEmail: noc@cogentco.com
OrgNOCRef: http://whois.arin.net/rest/poc/ZC108-ARIN
OrgAbuseHandle: COGEN-ARIN
OrgAbuseName: Cogent Abuse
OrgAbusePhone: +1-877-875-4311
OrgAbuseEmail: abuse@cogentco.com
OrgAbuseRef: http://whois.arin.net/rest/poc/COGEN-ARIN
OrgTechHandle: IPALL-ARIN
OrgTechName: IP Allocation
OrgTechPhone: +1-877-875-4311
OrgTechEmail: ipalloc@cogentco.com
OrgTechRef: http://whois.arin.net/rest/poc/IPALL-ARIN
# end
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# http://www.arin.net/public/whoisinaccuracy/index.xhtml
#
Found a referral to rwhois.cogentco.com:4321.
%rwhois V-1.5:0010b0:00 rwhois.cogentco.com
network:ID:NET4-2671BC0016
network:Network-Name:NET4-2671BC0016
network:IP-Network:38.113.188.0/22
network:Postal-Code:M5H 4E7
network:Country:CA
network:City:Toronto
network:Street-Address:157 Adelaide St W
network:Org-Name:Baraka Streaming Technologies Inc.
network:Tech-Contact:ZC108-ARIN
network:Updated:2015-06-19 18:43:09
%ok
Re: Add "may be forged" minor rule?
Posted by Amir Caspi <ce...@3phase.com>.
On Sep 28, 2015, at 1:34 PM, Axb <ax...@gmail.com> wrote:
> you may need to start looking at a local RBL and start blocking IP ranges
>
> been blocking snowshoe from Baraka Streaming Technologies Inc 38.113.188.0/22 since 2014-06-18 - no complaints - ymmv
Will look into it, but that doesn't really address my questions. It would take care of this batch of snowshoe but I'm thinking more generally. Would a "forged" rule be worthwhile, or not recommended for some reason? (If low-scoring.) And why is HTML_FONT_LOW_CONTRAST just a placeholder when network tests are enabled?
> whois is your friend...
Not sure how whois would have helped me here... the SOA for this IP range is amanah.com, but that doesn't really tell me much.
Thanks.
-- Amir
Re: Add "may be forged" minor rule?
Posted by Axb <ax...@gmail.com>.
On 09/28/2015 09:25 PM, Amir Caspi wrote:
> Hi all,
>
> So, one of my users has been getting dozens of spams per day lately, that have been getting BAYES_999 but not triggering any other point rules. All of these spams have forge warnings in the Received header, and it seems like it might be worth adding a low-scoring "may be forged" rule... what do people think? (Apparently HTML_FONT_LOW_CONTRAST is only a placeholder when network tests are enabled? Not sure why, seems like it should be useful at all times.)
>
> Two spamples:
>
> http://pastebin.com/1AhK1DiU
> http://pastebin.com/LVRy5Bu6
>
you may need to start looking at a local RBL and start blocking IP ranges
been blocking snowshoe from Baraka Streaming Technologies Inc
38.113.188.0/22 since 2014-06-18 - no complaints - ymmv
whois is your friend...