Re: Junk mixed in with ham on whitelists
On 02/22/18 15:56, David Jones wrote:
> On 02/22/2018 08:52 AM, Benny Pedersen wrote:
>> Giovanni Bechis skrev den 2018-02-22 15:39:
>>
sub check_dkim_valid {
my ($self, $pms, $full_ref, @acceptable_domains) = @_;
$self->_check_dkim_signature($pms) if !$pms->{dkim_checked_signature};
my $result = 0;
if (!$pms->{dkim_valid}) {
# don't bother
} elsif (!@acceptable_domains) {
$result = 1; # no additional constraints, any signing domain will do,
# also any signing key size will do
} else {
$result = $self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
}
return $result;
}
there we go :(
dkim signed should be any key bits allowed, but dkim valid should not
allow under minimal key bits
>>>
>>> $self->_check_dkim_signed_by already checks for miminal key bits
>>
>> elsif part is correct ?
>>
>> i read code as any key bits can make valid dkim
>
> That is also my finding based on:
>
> https://pastebin.com/mjvB0MKg
>
> which hit DKIM_VALID with a 768-bit key.
>
It doesn't for me:
-
X-Spam-Checker-Version: SpamAssassin 3.4.2-pre3-r1823175 (2018-02-05) on
bigio.paclan.it
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=5.0 tests=DKIM_SIGNED,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID
autolearn=no
autolearn_force=no version=3.4.2-pre3-r1823175
X-Spam-ASN: AS46606 69.89.16.0/20
X-Spam-Report:
* -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
* [69.89.18.3 listed in wl.mailspike.net]
* -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no
* trust
* [69.89.18.3 listed in list.dnswl.org]
* -0.0 SPF_PASS SPF: sender matches SPF record
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* valid
* 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Spam-Relay-Country: US ** US
-
SpamAssassin version 3.4.2-pre3-r1823175
running on Perl version 5.24.3
with Mail-DKIM-0.40 and Net-DNS-1.14
witch Mail::DKIM and Net::DNS version are you using ?
Giovanni
Re: Junk mixed in with ham on whitelists
On 02/22/2018 08:52 AM, Benny Pedersen wrote:
Giovanni Bechis skrev den 2018-02-22 15:39:
sub check_dkim_valid {
my ($self, $pms, $full_ref, @acceptable_domains) = @_;
$self->_check_dkim_signature($pms) if
!$pms->{dkim_checked_signature};
my $result = 0;
if (!$pms->{dkim_valid}) {
# don't bother
} elsif (!@acceptable_domains) {
$result = 1; # no additional constraints, any signing domain
will do,
# also any signing key size will do
} else {
$result =
$self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
}
return $result;
}
there we go :(
dkim signed should be any key bits allowed, but dkim valid should not
allow under minimal key bits
$self->_check_dkim_signed_by already checks for miminal key bits
elsif part is correct ?
i read code as any key bits can make valid dkim
That is also my finding based on:
https://pastebin.com/mjvB0MKg
which hit DKIM_VALID with a 768-bit key.
--
David Jones
Re: Junk mixed in with ham on whitelists
Giovanni Bechis skrev den 2018-02-22 15:39:
sub check_dkim_valid {
my ($self, $pms, $full_ref, @acceptable_domains) = @_;
$self->_check_dkim_signature($pms) if
!$pms->{dkim_checked_signature};
my $result = 0;
if (!$pms->{dkim_valid}) {
# don't bother
} elsif (!@acceptable_domains) {
$result = 1; # no additional constraints, any signing domain will
do,
# also any signing key size will do
} else {
$result =
$self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
}
return $result;
}
there we go :(
dkim signed should be any key bits allowed, but dkim valid should not
allow under minimal key bits
$self->_check_dkim_signed_by already checks for miminal key bits
elsif part is correct ?
i read code as any key bits can make valid dkim
Re: Junk mixed in with ham on whitelists
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/22/18 15:34, Benny Pedersen wrote:
> Benny Pedersen skrev den 2018-02-21 17:55:
>> David Jones skrev den 2018-02-21 17:41:
>>
>>> I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the
>>> size acceptable for whitelisting is different from the DKIM_VALID
>>> check?
>>
>> minimal key bits could be a plugin test yes, but imho it never made to do
>> this
>>
>>> Does the check_dkim_valid function need to also check for the
>>> dkim_minimum_key_bits size to consider it DKIM_VALID?
>>
>> i cant figure out where problem is either, since i am more a comal
>> programmer then a perl :=)
>>
>> DKIM_VALID and DKIM_VALID_AU should not give pass if minimal key bits is to
>> low
>
> sub check_dkim_valid {
> my ($self, $pms, $full_ref, @acceptable_domains) = @_;
> $self->_check_dkim_signature($pms) if !$pms->{dkim_checked_signature};
> my $result = 0;
> if (!$pms->{dkim_valid}) {
> # don't bother
> } elsif (!@acceptable_domains) {
> $result = 1; # no additional constraints, any signing domain will do,
> # also any signing key size will do
> } else {
> $result = $self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
> }
> return $result;
> }
>
> there we go :(
>
> dkim signed should be any key bits allowed, but dkim valid should not allow
> under minimal key bits
$self->_check_dkim_signed_by already checks for miminal key bits
Giovanni
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEqg3TnG6R3qYMxl94+r7qCYlyWOUFAlqO1hgACgkQ+r7qCYly
WOWbzQ//ZmOupz9AmyVV/155HcYOY9KpSN3FPNUxzNbfpQK/zEA2XK4XPIEKcsYn
qr7e81PlWnW/dKgquItylHxk3DOHUbn/+yUJ0WzVpbXXGWlW7Byf/PibzYSQa1tg
7RvQXgVBFjC+O67BhDxQH3JnHswf4H9pRjuF0jtErA/rgDEG8g8MV/3DG0jj0FpD
qRNKpkRy1pkS1lTe+yV9kvcz9pwiRygPjMGvMlEr+1pQ3T8iEgFTPSiBdwyVnaEc
JcgtpO/JQeGMcblIy+jF0ZJQbBYeHxD/W3S8gFcKbo0OT1CBdG/qARvA6TnUrTqb
J/kC4HfRgsWRe86SFSMOSmOCyhLuuKIv95Xsq+u9cqu9vPlJ80eY8Gf/bEg8wT5f
zlqecksTYN6Dl7GW7eKl11luQm6OM29p+a9woZ+i5K+pFokEfISg8LlpyUOVMb4O
AmHLE5O7xI+lvyK4g0CcQpbLC0EHaYCas/8q/0zKVCyws0gb5Pg8XB7K/VLDjtWP
etw6Qj8VGUPER1Kidh8VVH/My0kr9sRdFIhcJqCT4ISUfUjEELXzrLqcGdMxBoQg
/vTg/wnyfrxjIe6H9HuSEFiP0KWwlmwa0YPR0tU1SmxIm/fsOAuXaJDQiJdJZWEF
Koto7UjxXilu//X29y+ClF4DtwqYNO3zhDAO3eujwu5y3BSoOgo=
=iKOh
-END PGP SIGNATURE-
Re: Junk mixed in with ham on whitelists
Benny Pedersen skrev den 2018-02-21 17:55:
David Jones skrev den 2018-02-21 17:41:
I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the
size acceptable for whitelisting is different from the DKIM_VALID
check?
minimal key bits could be a plugin test yes, but imho it never made to
do this
Does the check_dkim_valid function need to also check for the
dkim_minimum_key_bits size to consider it DKIM_VALID?
i cant figure out where problem is either, since i am more a comal
programmer then a perl :=)
DKIM_VALID and DKIM_VALID_AU should not give pass if minimal key bits
is to low
sub check_dkim_valid {
my ($self, $pms, $full_ref, @acceptable_domains) = @_;
$self->_check_dkim_signature($pms) if
!$pms->{dkim_checked_signature};
my $result = 0;
if (!$pms->{dkim_valid}) {
# don't bother
} elsif (!@acceptable_domains) {
$result = 1; # no additional constraints, any signing domain will
do,
# also any signing key size will do
} else {
$result =
$self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
}
return $result;
}
there we go :(
dkim signed should be any key bits allowed, but dkim valid should not
allow under minimal key bits
Re: Junk mixed in with ham on whitelists
David Jones skrev den 2018-02-21 17:41: I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the size acceptable for whitelisting is different from the DKIM_VALID check? minimal key bits could be a plugin test yes, but imho it never made to do this Does the check_dkim_valid function need to also check for the dkim_minimum_key_bits size to consider it DKIM_VALID? i cant figure out where problem is either, since i am more a comal programmer then a perl :=) DKIM_VALID and DKIM_VALID_AU should not give pass if minimal key bits is to low
Re: Junk mixed in with ham on whitelists
On 02/21/2018 10:22 AM, Benny Pedersen wrote:
David Jones skrev den 2018-02-21 15:46:
Bug 7559 opened. I don't want to delay 3.4.2 either. I don't think
this is major enough to have to go into 3.4.2 unless someone can
provide a quick patch for Kevin.
in dkim.pm plugin i find
# minimal signing key size in bits that is acceptable for whitelisting
push (@cmds, {
setting => 'dkim_minimum_key_bits',
default => 1024,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
});
so it is solved in 3.4.1 ?
what version of Mail::DKIM does it fails with ?
I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the
size acceptable for whitelisting is different from the DKIM_VALID check?
Does the check_dkim_valid function need to also check for the
dkim_minimum_key_bits size to consider it DKIM_VALID?
--
David Jones
Re: Junk mixed in with ham on whitelists
David Jones skrev den 2018-02-21 15:46:
Bug 7559 opened. I don't want to delay 3.4.2 either. I don't think
this is major enough to have to go into 3.4.2 unless someone can
provide a quick patch for Kevin.
in dkim.pm plugin i find
# minimal signing key size in bits that is acceptable for whitelisting
push (@cmds, {
setting => 'dkim_minimum_key_bits',
default => 1024,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
});
so it is solved in 3.4.1 ?
what version of Mail::DKIM does it fails with ?
Re: Junk mixed in with ham on whitelists
On 02/21/18 00:24, Benny Pedersen wrote: > David Jones skrev den 2018-02-21 00:14: > >> https://pastebin.com/mjvB0MKg (scored 10.96) >> -0.10 DKIM_VALID Message has at least one valid DKIM or DK signature > > Authentication-Results: smtp3i.ena.net; > dkim=policy reason="signing key too small" (768-bit key) > header.d=mails-express.com header.i=@mails-express.com header.b="Mv82gS9m" > > why diffrent results ? I have those result on my laptop for that message and T_DKIM_INVALID is triggered. X-Spam-Checker-Version: SpamAssassin 4.0.0-r1823176 (2018-02-05) on bigio.paclan.it X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=DKIM_SIGNED,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=4.0.0-r1823176 X-Spam-ASN: AS46606 69.89.16.0/20 X-Spam-Report: * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [69.89.18.3 listed in list.dnswl.org] * -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) * [69.89.18.3 listed in wl.mailspike.net] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Spam-Relay-Country: US ** US
Re: Junk mixed in with ham on whitelists
On 02/21/2018 08:30 AM, Benny Pedersen wrote: Kevin A. McGrail skrev den 2018-02-21 14:44: On 2/21/2018 8:42 AM, David Jones wrote: Do we need to open a bug to get SA's DKIM code to check for a minimum key size? When in doubt, open a bug. more bugs will delay 3.4.2 :=) Bug 7559 opened. I don't want to delay 3.4.2 either. I don't think this is major enough to have to go into 3.4.2 unless someone can provide a quick patch for Kevin. -- David Jones
Re: Junk mixed in with ham on whitelists
Kevin A. McGrail skrev den 2018-02-21 14:44: On 2/21/2018 8:42 AM, David Jones wrote: Do we need to open a bug to get SA's DKIM code to check for a minimum key size? When in doubt, open a bug. more bugs will delay 3.4.2 :=)
Re: Junk mixed in with ham on whitelists
David Jones skrev den 2018-02-21 14:42: My guess is SA's DKIM check doesn't care about the size of the key. OpenDKIM has a setting of "MinimumKeyBits 1024" since anything smaller can be trivially cracked. Do we need to open a bug to get SA's DKIM code to check for a minimum key size? yes please what version of Mail::DKIM have this ?
Re: Junk mixed in with ham on whitelists
On 21-02-18 14:54, David Jones wrote: > On 02/21/2018 07:44 AM, Kevin A. McGrail wrote: >> On 2/21/2018 8:42 AM, David Jones wrote: >>> Do we need to open a bug to get SA's DKIM code to check for a minimum >>> key size? >> >> When in doubt, open a bug. >> > > Well. Ummm. I found this when starting to create the bug: > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7124 > Note that the patch in that PR sets the default to 512 bits, and not to 1024 as proposed in the bug, and which is what would be a current sane default. Not sure about the actual default in current SA code though. Kind regards, Tom
Re: Junk mixed in with ham on whitelists
On 02/21/2018 07:44 AM, Kevin A. McGrail wrote: On 2/21/2018 8:42 AM, David Jones wrote: Do we need to open a bug to get SA's DKIM code to check for a minimum key size? When in doubt, open a bug. Well. Ummm. I found this when starting to create the bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7124 -- David Jones
Re: Junk mixed in with ham on whitelists
On 2/21/2018 8:42 AM, David Jones wrote: Do we need to open a bug to get SA's DKIM code to check for a minimum key size? When in doubt, open a bug.
Re: Junk mixed in with ham on whitelists
On 02/20/2018 05:24 PM, Benny Pedersen wrote: David Jones skrev den 2018-02-21 00:14: https://pastebin.com/mjvB0MKg (scored 10.96) -0.10 DKIM_VALID Message has at least one valid DKIM or DK signature Authentication-Results: smtp3i.ena.net; dkim=policy reason="signing key too small" (768-bit key) header.d=mails-express.com header.i=@mails-express.com header.b="Mv82gS9m" why diffrent results ? My guess is SA's DKIM check doesn't care about the size of the key. OpenDKIM has a setting of "MinimumKeyBits 1024" since anything smaller can be trivially cracked. Do we need to open a bug to get SA's DKIM code to check for a minimum key size? -- David Jones
Re: Junk mixed in with ham on whitelists
On 20 Feb 2018, at 16:48, David Jones wrote: It doesn't seem like a good idea for whitelists to list these senders just because most of the email is ham. I can see no evidence for that in a quick check of my personal mail. In 10 years: 68 messages 50 spam (all reported) 6 replies to spam reports 2 OoO Autoreplies to mailing messages with vacation info for guys I didn't know. 8 messages to single-sender (webite-specific) addresses 2 messages from Namecheap themselves (privateemail.com ) trying to arrange an automatic monitoring rig for when their space lands on my (extremely irrelevant...) blacklist or a FBL for when I get spam from them. This raises the question: if a company whose business model is dependent on snowshoe spammers and domain squatters sends email asking for unpaid help in evading recognition of their essential evil, is it spam? In the previous decade: 64 messages, 56 spams, 8 ham (all from 3 websites to tagged addresses.) Of course, my personal email isn't representative. I reject a substantial fraction of the mail from the networks where those domains have servers, and for a complex of reasons I have extremely high confidence in those rejections being pure spam. So, the above is less spammy than if I tagged and delivered. What's special about such sources isn't that they're mostly ham or even significantly less spammy than a random sample of mail, it's that they have a lot of tiny customers who barely use email and occasional waves of transient spammers. It makes them hard to pigeonhole either way. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: Junk mixed in with ham on whitelists
David Jones skrev den 2018-02-21 00:14: https://pastebin.com/mjvB0MKg (scored 10.96) -0.10 DKIM_VALID Message has at least one valid DKIM or DK signature Authentication-Results: smtp3i.ena.net; dkim=policy reason="signing key too small" (768-bit key) header.d=mails-express.com header.i=@mails-express.com header.b="Mv82gS9m" why diffrent results ?
Re: Junk mixed in with ham on whitelists
On 02/20/2018 04:08 PM, David Jones wrote: On 02/20/2018 03:48 PM, David Jones wrote: On 02/20/2018 12:57 PM, Kevin A. McGrail wrote: On 2/20/2018 1:53 PM, David Jones wrote: Over the years I have noticed junk/spam email coming from these servers so I created this rule: header ENA_RCVD_NOTRUST Received =~ /\.(secureserver\.net|web-hosting\.com|websitewelcome\.com|inmotionhosting\.com|unifiedlayer\.com|ezhostingserver\.com|siteprotect\.com|internetbilisim\.net|privateemail\.com|registrar-servers\.com|emailsrvr\.com|registeredsite\.com) \[/ Well just spot checking, you've identified some of the largest ISPs on the planet. Secure Server is Wild West/Godaddy WebsiteWelcome is HostGator, etc. I knew they were major ISPs but spam still comes out of their servers at a higher rate than the occasional compromised account or bad customer of a good ESP (Exact Target, Mail Chimp, EMMA, etc). I don't think they are going to be indicative of spam or ham and I would individually blacklist domains and contact their abuse. I was doing that but always behind the whack-a-mole game. I wanted to do the opposite and set a level playing field from a whitelist perspective for those servers by offsetting the whitelist negative scores to get them back to around zero and let Bayes plus other content-based rules determine the allow or block. It doesn't seem like a good idea for whitelists to list these senders just because most of the email is ham. If a small percentage is spam, then how do we report that back to Hostkarma and dnswl.org? I can report it to SpamCop but that doesn't make it's way to the other whitelists. SPF record for websitewelcome.com that Hostgator recommends to their customers: v=spf1 include:spf.websitewelcome.com include:spf1.websitewelcome.com include:_spf.google.com That is ridiculous!!! It requires 8 DNS queries and shouldn't include Google's servers. I just received this perfect example where BAYES_80, DCC, and UNWANTED_LANGUAGE_BODY were the primary hits that blocked this. I see some with many whitelists that would normally bring it below the block threshold but now I have meta rules with ENA_RCVD_NOTRUST to add back points with local *_OFFSET rules. https://pastebin.com/mjvB0MKg (scored 10.96) Score Matching Rule Description 3.20 BAYES_80 Bayesian analysis determined this message has a 80%-95% chance of being spam. 3.20 DCC_CHECK Spam check using a checksum comparison with other mail servers on the Internet. 0.10DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.10 DKIM_VALID Message has at least one valid DKIM or DK signature 0.01DMARC_NONE 0.20ENA_NOT_DKIM_VALID_AU 1.20ENA_RCVD_NOTRUSTReceived from servers not trusted 1.20ENA_RCVD_NOTRUST_MSPIKE_H2_OFFSET 0.25HEADER_FROM_DIFFERENT_DOMAINS 0.00HTML_MESSAGEHTML emails can be used to hide or obscure spam. 0.50JMQ_SPF_NEUTRAL_ALL -0.20 RCVD_IN_DNSWL_NONE Sender listed at http://www.dnswl.org/, no trust -1.20 RCVD_IN_MSPIKE_H2 Average reputation (+2) -0.20 RCVD_IN_SENDERSCORE_80_89 -0.00 SPF_PASSSPF: sender matches SPF record 2.80UNWANTED_LANGUAGE_BODY Message written in an undesired language -- David Jones
Re: Junk mixed in with ham on whitelists
David Jones skrev den 2018-02-20 23:08: That is ridiculous!!! It requires 8 DNS queries and shouldn't include Google's servers. +1 v=spf1 ip4:23.83.208.1/20 ip4:23.91.112.0/20 ip4:46.232.183.0/24 ip4:50.87.152.0/21 ip4:50.116.64.0/18 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:100.42.48.0/20 ip4:104.152.64.0/21 ip4:104.171.0.0/20 ip4:108.167.128.0/18 ip4:108.175.144.0/20 ip4:108.177.8.0/21 ip4:108.177.96.0/19 ip4:108.179.192.0/18 ip4:162.144.0.0/16 ip4:162.253.144.0/21 ip4:162.254.160.0/21 ip4:172.217.0.0/19 ip4:172.217.32.0/20 include:spf1.websitewelcome.com ?all v=spf1 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:173.194.0.0/16 ip4:177.153.0.128/25 ip4:191.252.57.0/25 ip4:192.169.48.0/20 ip4:192.185.0.0/16 ip4:198.58.80.0/20 ip4:198.252.64.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.172.160.0/19 ip4:216.239.32.0/19 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ?all consider it +all is there a plan for max number of ips in a valid spf ?
Re: Junk mixed in with ham on whitelists
On 02/20/2018 03:48 PM, David Jones wrote: On 02/20/2018 12:57 PM, Kevin A. McGrail wrote: On 2/20/2018 1:53 PM, David Jones wrote: Over the years I have noticed junk/spam email coming from these servers so I created this rule: header ENA_RCVD_NOTRUST Received =~ /\.(secureserver\.net|web-hosting\.com|websitewelcome\.com|inmotionhosting\.com|unifiedlayer\.com|ezhostingserver\.com|siteprotect\.com|internetbilisim\.net|privateemail\.com|registrar-servers\.com|emailsrvr\.com|registeredsite\.com) \[/ Well just spot checking, you've identified some of the largest ISPs on the planet. Secure Server is Wild West/Godaddy WebsiteWelcome is HostGator, etc. I knew they were major ISPs but spam still comes out of their servers at a higher rate than the occasional compromised account or bad customer of a good ESP (Exact Target, Mail Chimp, EMMA, etc). I don't think they are going to be indicative of spam or ham and I would individually blacklist domains and contact their abuse. I was doing that but always behind the whack-a-mole game. I wanted to do the opposite and set a level playing field from a whitelist perspective for those servers by offsetting the whitelist negative scores to get them back to around zero and let Bayes plus other content-based rules determine the allow or block. It doesn't seem like a good idea for whitelists to list these senders just because most of the email is ham. If a small percentage is spam, then how do we report that back to Hostkarma and dnswl.org? I can report it to SpamCop but that doesn't make it's way to the other whitelists. SPF record for websitewelcome.com that Hostgator recommends to their customers: v=spf1 include:spf.websitewelcome.com include:spf1.websitewelcome.com include:_spf.google.com That is ridiculous!!! It requires 8 DNS queries and shouldn't include Google's servers. -- David Jones
Re: Junk mixed in with ham on whitelists
On 02/20/2018 12:57 PM, Kevin A. McGrail wrote: On 2/20/2018 1:53 PM, David Jones wrote: Over the years I have noticed junk/spam email coming from these servers so I created this rule: header ENA_RCVD_NOTRUST Received =~ /\.(secureserver\.net|web-hosting\.com|websitewelcome\.com|inmotionhosting\.com|unifiedlayer\.com|ezhostingserver\.com|siteprotect\.com|internetbilisim\.net|privateemail\.com|registrar-servers\.com|emailsrvr\.com|registeredsite\.com) \[/ Well just spot checking, you've identified some of the largest ISPs on the planet. Secure Server is Wild West/Godaddy WebsiteWelcome is HostGator, etc. I knew they were major ISPs but spam still comes out of their servers at a higher rate than the occasional compromised account or bad customer of a good ESP (Exact Target, Mail Chimp, EMMA, etc). I don't think they are going to be indicative of spam or ham and I would individually blacklist domains and contact their abuse. I was doing that but always behind the whack-a-mole game. I wanted to do the opposite and set a level playing field from a whitelist perspective for those servers by offsetting the whitelist negative scores to get them back to around zero and let Bayes plus other content-based rules determine the allow or block. It doesn't seem like a good idea for whitelists to list these senders just because most of the email is ham. If a small percentage is spam, then how do we report that back to Hostkarma and dnswl.org? I can report it to SpamCop but that doesn't make it's way to the other whitelists. -- David Jones
