Re: Bypass RBL checks for specific address
whitelist_to ? On 12/23/20 12:56 AM, Grant Taylor wrote: Is there a way to bypass RBL checks for a specific address? I've tried the all_spam_to option, but it looks like it artificially lowers the score and still runs normal tests. I'd like to disable RBL checks for one address.
Re: Bypass RBL checks for specific address
On 22 Dec 2020, at 18:56, Grant Taylor wrote: Is there a way to bypass RBL checks for a specific address? I've tried the all_spam_to option, but it looks like it artificially lowers the score and still runs normal tests. I'd like to disable RBL checks for one address. Do you have a setup that supports per-user preferences? e.g.: real system accounts. If so, you can disable off individual rules for a user by giving them a score of 0 in ~/.spamassassin/user_prefs if they have a real account or in whatever you use for per-user prefs if they are virtual users. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: More undetected hidden test spam signs
Right, but __STY_INVIS is currently tag-blind (it only looks for the style="" clause), so it hits that, and if lots of ham is hiding tracking images that way that might explain the poor S/O. I suspect that might be the case. The vast majority of invisible garbage I see is hidden in a ... pair, typically two per spam and about 50K in each one. Looking at the definition of the
Re: More undetected hidden test spam signs
On Tue, 22 Dec 2020, Loren Wilton wrote:
On 16 Dec 2020, at 23:21, Loren Wilton wrote:
I just got a batch of spams containing
Such rules are there. Unfortunately, for whatever reason, lots of ham uses
"invisible" text so it's not useful as a spam sign by itself and it's hard
to come up with any useful combination rules.
I think I may have figured it out - tracking images. Like:
style="visibility: hidden !important; display:none !important; max-height:
0; width: 0; line-height: 0; mso-hide: all;">
Note in your example the display:none is in a contained tag and not in an
opening tag of a span. The tag is probably fairly long because the URL is
probably huge, but it is still the one item that is hidden.
Right, but __STY_INVIS is currently tag-blind (it only looks for the
style="" clause), so it hits that, and if lots of ham is hiding tracking
images that way that might explain the poor S/O.
I put in a local rawbody rule for
m'.{100,}(?:$|)'is
and so far I haven't gotten any hits on ham.
How much spam hits that very simple case? I had a __SPAN_INVIS rule
(currently commented out) but IIRC it also had poor S/O. It wasn't as
simple as yours, though - perhaps I'm allowing for too many
syntactically-valid cases to try to avoid trivial avoidance by spam?
Of course that is a pretty heavy rule
It would be lighter if you didn't look for the tag closing. Is there a
reason you care about the closing for that?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
---
3 days until Christmas
Re: Bypass RBL checks for specific address
On 12/22/2020 6:56 PM, Grant Taylor wrote:
Is there a way to bypass RBL checks for a specific address? I've tried
the all_spam_to option, but it looks like it artificially lowers the
score and still runs normal tests. I'd like to disable RBL checks for
one address.
Grant,
First, I'm NOT an expert on all of this - so somebody might be able to
follow up with BETTER information, but this will hopefully point you in
the right direction.
So at some point, I think 10+ years ago, I needed to do this, and
instead of doing this at the spam filter level - I found that it worked
well to do this via BIND - so this works if you're using your own
locally-hosted BIND server for resolving DNSBL queries. So, for example,
if you qualified for use of the free version of SpamCop (as an example),
and you wanted to whitelist the IP 1.2.3.4, you could add the following
to your named.conf file:
zone "4.3.2.1.bl.spamcop.net" in { type master; notify no; file
"master/null.zone"; };
Then add another such record for each DNSBL that you use. Then the
"master/null.zone" file can be the following EMPTY zone (or something
like this - change as desired! This might not even be the best or
"right" way to do this - this is just what I had in that null.zone file
when I was doing this 10+ years ago):
$TTL 52w
@ IN SOA root.localhost. root.localhost (
2005012001 ; serial
52w ; refresh
52w ; retry
52w ; expire
52w ; ttl
)
@ IN NS localhost
localhost IN A 127.0.0.1
So by referencing an empty zone file, that way, each "zone" entry just
points to this one file, for maximum efficiency and caching, and you
don't have to reenter this for each zone. In the named.conf file, I
think each zone statement (my 1st example abovw) would go AFTER the
"options" section, but before the "includes" section. Obviously, if you
suddenly needed to do this for 10s of thousands of IPs or hostnames,
then maybe it would then start to have resource/maintenance issues - but
on a smaller scale, this works great!
HOWEVER - This was so long ago, that I don't know if this STILL works in
more recent version of BIND without causing issues? It is possible that
in more recent version of BIND, DNSSEC might interfere with being able
to do this?
So ANOTHER option might be to use the newer "response-policy" feature -
my first idea was a sort of hack - but this "response-policy" might be
more intended for exactly this purpose. So do a search on the following:
"response-policy" "BIND" "NXDOMAIN"
...with each in quotes, as shown, for instructions on how this is done.
So I think the example above, if implemented using "response-policy",
would be the following:
response-policy {
4.3.2.1.bl.spamcop.net IN CNAME .
};
Or something like that. Double-check my syntax. It might be wrong! So,
again, I've never done the "response-policy", so this is just to get you
started and point you in the right direction. If someone comes along and
corrects my possible mistakes, or provides BETTER info - that is
excellent - in the meantime, hopefully this will point you in the right
direction, or give you some ideas.
-- Rob McEwen, invaluement
Bypass RBL checks for specific address
Is there a way to bypass RBL checks for a specific address? I've tried the all_spam_to option, but it looks like it artificially lowers the score and still runs normal tests. I'd like to disable RBL checks for one address. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: More undetected hidden test spam signs
On 16 Dec 2020, at 23:21, Loren Wilton wrote:
I just got a batch of spams containing
Such rules are there. Unfortunately, for whatever reason, lots of ham
uses "invisible" text so it's not useful as a spam sign by itself and
it's hard to come up with any useful combination rules.
I think I may have figured it out - tracking images. Like:
style="visibility: hidden !important; display:none !important; max-height:
0; width: 0; line-height: 0; mso-hide: all;">
Note in your example the display:none is in a contained tag and not in an
opening tag of a span. The tag is probably fairly long because the URL is
probably huge, but it is still the one item that is hidden.
I put in a local rawbody rule for
m'.{100,}(?:$|)'is
and so far I haven't gotten any hits on ham.
Of course that is a pretty heavy rule, but it would seem to indicate that
hidden spans may not be that common in ham.
Re: More undetected hidden test spam signs
On Thu, 17 Dec 2020, John Hardin wrote: On Thu, 17 Dec 2020, @lbutlr wrote: On 16 Dec 2020, at 23:21, Loren Wilton wrote: I just got a batch of spams containing Interesting. I remember in the early days of html spam there were various rules to tag messages as spam when they had content that did not display. (Possibly pre-SpamAssasin or at least pre my use of SpamAssasin). Such rules are there. Unfortunately, for whatever reason, lots of ham uses "invisible" text so it's not useful as a spam sign by itself and it's hard to come up with any useful combination rules. I think I may have figured it out - tracking images. Like: The src link gets visited to retrieve the image so the message is tracked, but the display of the image is suppressed. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never does quite what I want. I wish Christopher Robin was here." -- Peter da Silva in a.s.r --- 3 days until Christmas
Re: Do the Yahooniverse domains share email address space?
On Mon, 21 Dec 2020, Axb wrote: On 12/21/20 7:19 PM, John Hardin wrote: Quick question for anyone who knows: Are the email addresses in the various domains in the yahoo family (e.g. yahoo.com, yahoo.com.hk, yahoo.com.my, yahoo.com.sg, yahoo.com.vn, yahoo.co.jp, yahoo.co.nz, yahoo.co.th, yahoo.co.uk, yahoo.es, yahoo.fr, etc.) all shared (i.e. which domain you use doesn't matter)? Or is a mailbox/account separate and distinct from ? Only yahoo.co.jp run their own setup and don't share with the rest of the world. ...so and and are all the same mailbox, but is separate from them? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never does quite what I want. I wish Christopher Robin was here." -- Peter da Silva in a.s.r --- 3 days until Christmas
