Re: IADB whitelist - again

[Luis E. Muñoz]

On 2 Mar 2018, at 0:48, Sebastian Arcus wrote:

But why does SA have to expose a rule for each and every code IADB 
provides?


So that users can implement their own policies if desired? So that 
different rules can have a more granular effect on the inbound email 
flow, without this being a simply binary affair (present, not present)? 
More reasons come to mind, but it all boils down to exposing all the 
available information to the users in order for them to make better 
decisions.


As I mentioned in one of my prior responses, I personally know of 
operations that use that data granularity to their advantage.


SA is an antispam solution, IADB is a facilitator for the marketing 
industry (in spite of their continuous protestations on this list). 
The goals of the two are not the same. Surely SA can decide by itself 
what is really useful from a spam filtering point of view - not churn 
out whatever it gets passed by marketing whitelists? SA uses other 
whitelists (some may I say a lot more useful than IADB), and it only 
exposes one or two rules for each.


I doubt IADB is in a position to dictate to anyone how to use (or not) 
the data it provides. Not SA, not anybody else. Participants in IADB 
(listees and users) voluntarily act so. As someone else in this thread 
pointed out, IADB provides a useful ham signal.


I think the goals of both are fairly aligned. An antispam solution is 
not good if it blocks wanted email. IADB is conveying information about 
the stated policies / practices of the sending organization. Assisted 
with this information, SA can take better decisions about specific 
pieces of email.


Also, there is RCVD_IN_IADB_DOPTIN, so RCVD_IN_IADB_OPTIN may be 
"someone somehow gave us your name somewhere" (i.e. "single opt-in") 
rather than "we confirmed you actually want to receive our garbage" 
("double opt-in").


So effectively pretty useless, as if you ever made the mistake of 
forgetting to untick the "receive email from our carefully selected 
partners" in the past, you will never be able to take that consent 
back as your email address gets passed from entity to entity. Consent 
to be emailed marketing material is a joke - and SA shouldn't be a 
facilitator - otherwise its value as a spam filter is gone.


I fail to see how SA is acting as a facilitator in this case. SA ships 
with rules that look up all the available information about a piece of 
email and then, hands this information to a set of rules that decide 
what should happen to that email. You're objecting to the scores being 
applied to those rules because you received one email that you believe 
doesn't align with the results of one of those rules and want to drop 
those rules from the distribution.


What would happen if the email you wanted came from a mail server listed 
in Spamhaus? Would you then argue for removing rules using Spamhaus from 
SA altogether?


I would urge you to follow the advice of other list members and actually 
report the misclassified spam so that involved parties can take action.


The scores appear hardcoded (50_scores.cf) vs. from masscheck 
(72_scores.cf) so they may be *very* stale.


In that case maybe at least some of the rules should be removed then


In this case it seems to me that you already have a desired outcome and 
will grasp at any shred of argument to justify it.


Best regards

-lem

Re: IADB whitelist - again

[John Hardin]

On Fri, 2 Mar 2018, Sebastian Arcus wrote:

On 01/03/18 19:50, David Jones wrote:

On 03/01/2018 12:29 PM, Sebastian Arcus wrote:
I know I have brought up this issue on this list before, and sorry for the 
persistence, but having 7 different rules adding scores for the IADB 
whitelist still seems either ridiculous, or outright suspect:


-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
  [199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-0.0 RCVD_IN_IADB_LISTED    RBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DK    RBL: IADB: Sender publishes Domain Keys record
-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender


There is simply no reason in the interest of SA as an antispam solution 
to publish all those rules.


Sure there is: to allow the site admin the ability to make fine-grained 
decisions in local rules.


I am concerned when the default settings in SA effectively facilitate 
marketing companies to stuff my Inbox full of junk.


-0.6 points makes the difference?

Perhaps the default scores need to be reviewed, but simply having the 
rules isn't problematic.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Once more, please; I missed it the last time: what's the difference
  between "Quantitative Easing" and "Counterfeiting"?
---
 11 days until Albert Einstein's 139th Birthday

Re: IADB whitelist - again

[John Hardin]

On Sat, 3 Mar 2018, Noel Butler wrote:


On 03/03/2018 04:40, John Hardin wrote:


On Fri, 2 Mar 2018, Sebastian Arcus wrote:


-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
[199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record
-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender

I am concerned when the default settings in SA effectively facilitate 
marketing companies to stuff my Inbox full of junk.


-0.6 points makes the difference?

Perhaps the default scores need to be reviewed, but simply having the
rules isn't problematic.


Have to agree with him, it can make all the difference in some cases,
I'd prefer to see the rules stay, but all at score 0


-0.001 surely... 0 = disabled = breaks dependencies.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  How can you reason with someone who thinks we're on a glidepath to
  a police state and yet their solution is to grant the government a
  monopoly on force? They are insane.
---
 11 days until Albert Einstein's 139th Birthday

Re: IADB whitelist - again

[Noel Butler]

On 03/03/2018 04:40, John Hardin wrote:

> On Fri, 2 Mar 2018, Sebastian Arcus wrote: On 01/03/18 19:50, David Jones 
> wrote: On 03/01/2018 12:29 PM, Sebastian Arcus wrote: I know I have brought 
> up this issue on this list before, and sorry for the persistence, but having 
> 7 different rules adding scores for the IADB whitelist still seems either 
> ridiculous, or outright suspect:
> 
> -0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
> [199.127.240.84 listed in iadb.isipp.com]
> -0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
> -0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
> -0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
> -0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
> -0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record
> -0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender

There is simply no reason in the interest of SA as an antispam solution
to publish all those rules. 
Sure there is: to allow the site admin the ability to make fine-grained
decisions in local rules.

> I am concerned when the default settings in SA effectively facilitate 
> marketing companies to stuff my Inbox full of junk.

-0.6 points makes the difference?

Perhaps the default scores need to be reviewed, but simply having the
rules isn't problematic. 

Have to agree with him, it can make all the difference in some cases,
I'd prefer to see the rules stay, but all at score 0, allowing those
admins who want differently, to change the local scores. 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

Re: IADB whitelist - again

[Sebastian Arcus]

On 01/03/18 19:04, John Hardin wrote:

On Thu, 1 Mar 2018, Sebastian Arcus wrote:

I know I have brought up this issue on this list before, and sorry for 
the persistence, but having 7 different rules adding scores for the 
IADB whitelist still seems either ridiculous, or outright suspect:


-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
    [199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-0.0 RCVD_IN_IADB_LISTED    RBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DK    RBL: IADB: Sender publishes Domain Keys 
record

-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender


It really raises some very uncomfortable questions regarding the 
impartiality of SA and/or its anti-spam capabilities. And by the way, 
this message is definitely unsolicited, and in now way we gave any 
sort of permission or consent to this company or its "affiliates" to 
email us - so the whole "All mailing list mail is opt-in" is nonsense.


And why have "Sender has reverse DNS record" and "Sender publishes SPF 
record" as separate IADB rules - when SA itself already checks for 
these? Isn't this just a glaring way of pumping up SA scores for the 
IADB subscribers?


Don't assume malice right off the bat. More likely it is that IADB 
provides all those status codes and SA exposes a rule for each, with 
minimal scores, to allow local tuning if desired.


But why does SA have to expose a rule for each and every code IADB 
provides? SA is an antispam solution, IADB is a facilitator for the 
marketing industry (in spite of their continuous protestations on this 
list). The goals of the two are not the same. Surely SA can decide by 
itself what is really useful from a spam filtering point of view - not 
churn out whatever it gets passed by marketing whitelists? SA uses other 
whitelists (some may I say a lot more useful than IADB), and it only 
exposes one or two rules for each.




Also, there is RCVD_IN_IADB_DOPTIN, so RCVD_IN_IADB_OPTIN may be 
"someone somehow gave us your name somewhere" (i.e. "single opt-in") 
rather than "we confirmed you actually want to receive our garbage" 
("double opt-in").


So effectively pretty useless, as if you ever made the mistake of 
forgetting to untick the "receive email from our carefully selected 
partners" in the past, you will never be able to take that consent back 
as your email address gets passed from entity to entity. Consent to be 
emailed marketing material is a joke - and SA shouldn't be a facilitator 
- otherwise its value as a spam filter is gone.




The scores appear hardcoded (50_scores.cf) vs. from masscheck 
(72_scores.cf) so they may be *very* stale.


In that case maybe at least some of the rules should be removed then

Re: IADB whitelist - again

[Sebastian Arcus]

On 01/03/18 19:50, David Jones wrote:

On 03/01/2018 12:29 PM, Sebastian Arcus wrote:
I know I have brought up this issue on this list before, and sorry for 
the persistence, but having 7 different rules adding scores for the 
IADB whitelist still seems either ridiculous, or outright suspect:


-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
  [199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-0.0 RCVD_IN_IADB_LISTED    RBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DK    RBL: IADB: Sender publishes Domain Keys 
record

-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender


It really raises some very uncomfortable questions regarding the 
impartiality of SA and/or its anti-spam capabilities. And by the way, 
this message is definitely unsolicited, and in now way we gave any 
sort of permission or consent to this company or its "affiliates" to 
email us - so the whole "All mailing list mail is opt-in" is nonsense.


And why have "Sender has reverse DNS record" and "Sender publishes SPF 
record" as separate IADB rules - when SA itself already checks for 
these? Isn't this just a glaring way of pumping up SA scores for the 
IADB subscribers?


Once in a while, even the best senders can get a bad customer of theirs 
that obtained email addresses by a violation of their terms and conditions.


Just block that sender with a local "blacklist_from *@example.com" entry 
and report it to SpamCop.  If the message headers have any abuse 
reporting information then send the headers there too.  They should do 
their own internal investigation and shutdown that bad customer of theirs.


That is still beside the point. There is simply no reason in the 
interest of SA as an antispam solution to publish all those rules. One 
or two rules would be more than enough. I know I can block this and that 
in SA, and tweak rules all the time - but I am concerned when the 
default settings in SA effectively facilitate marketing companies to 
stuff my Inbox full of junk. In that case you would achieve better 
results not using SA at all. As to reporting bad senders and "internal 
investigation" - my experience shows that doesn't get very far with any 
providers.

Re: IADB whitelist - again

[David Jones]

On 03/02/2018 02:54 AM, Sebastian Arcus wrote:


On 01/03/18 19:50, David Jones wrote:

On 03/01/2018 12:29 PM, Sebastian Arcus wrote:
I know I have brought up this issue on this list before, and sorry 
for the persistence, but having 7 different rules adding scores for 
the IADB whitelist still seems either ridiculous, or outright suspect:


-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
  [199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-0.0 RCVD_IN_IADB_LISTED    RBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DK    RBL: IADB: Sender publishes Domain Keys 
record

-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender


It really raises some very uncomfortable questions regarding the 
impartiality of SA and/or its anti-spam capabilities. And by the way, 
this message is definitely unsolicited, and in now way we gave any 
sort of permission or consent to this company or its "affiliates" to 
email us - so the whole "All mailing list mail is opt-in" is nonsense.


And why have "Sender has reverse DNS record" and "Sender publishes 
SPF record" as separate IADB rules - when SA itself already checks 
for these? Isn't this just a glaring way of pumping up SA scores for 
the IADB subscribers?


Once in a while, even the best senders can get a bad customer of 
theirs that obtained email addresses by a violation of their terms and 
conditions.


Just block that sender with a local "blacklist_from *@example.com" 
entry and report it to SpamCop.  If the message headers have any abuse 
reporting information then send the headers there too.  They should do 
their own internal investigation and shutdown that bad customer of 
theirs.


That is still beside the point. There is simply no reason in the 
interest of SA as an antispam solution to publish all those rules. One 
or two rules would be more than enough. I know I can block this and that 
in SA, and tweak rules all the time - but I am concerned when the 
default settings in SA effectively facilitate marketing companies to 
stuff my Inbox full of junk. In that case you would achieve better 
results not using SA at all. As to reporting bad senders and "internal 
investigation" - my experience shows that doesn't get very far with any 
providers.


Look at the IADB rules at http://ruleqa.spamassassin.org.

They are very indicative of ham, so much so that I bump the scores up on 
them and shortcircuit a few of them as ham.


If you want to score all of them at zero in your local.cf, go ahead. 
That's your choice.  Just because you get unwanted email in your inbox 
doesn't make it spam.  If it has a legit unsubscribe link then simply 
unsubscribe from it.  If you want to help the community, then report it 
to Spamcop.


--
David Jones

Re: Spammers, IPv6 addresses, and dnsbls

[Axb]

On 03/02/2018 12:54 PM, Daniele Duca wrote:

Hello list,

apologies if this is not directly SA related. "Lately" I've started to 
notice that some (not saying names) VPS providers, when offering v6 
connectivity, sometimes tends to not follow the best practice of giving 
a /64 to their customer, routing to them much smaller v6 subnets, while 
still giving to them the usual /30 or /29 v4 subnets.




If you are in a similar situation I would like very much to discuss what 
would be the best approach to balance spam detection while avoiding fps


This is not related to SA = Off-Topic
There are more adequate lists for this kind of discussion
(Mailop  list, for example)

Re: Spammers, IPv6 addresses, and dnsbls

[Matus UHLAR - fantomas]

On 02.03.18 09:58, Leandro wrote:

Hi Danilele! Our DNSBL works with individual /128 IPv6 addresses:

http://spfbl.net/en/dnsbl/

Even if the provider is offering less then /64 to customers, our DNSBL can
list IPv6 of each one.


how/who do you list when spammer starts rotating IPs in assigned /64 range? 


But do not use our DNSBL to reject messages. Use only for SA punctuation,
higher points to 127.0.0.2.



2018-03-02 8:54 GMT-03:00 Daniele Duca :

apologies if this is not directly SA related. "Lately" I've started to
notice that some (not saying names) VPS providers, when offering v6
connectivity, sometimes tends to not follow the best practice of giving a
/64 to their customer, routing to them much smaller v6 subnets, while still
giving to them the usual /30 or /29 v4 subnets.

What It's happening is that whenever a spammer buys a VPS with those
providers and get blacklisted, most of the time the dnsbls list the whole
v6 /64, while still listing only the single ipv4 address. This makes some
senses, as it would be enormously resource intensive to track each of the
18,446,744,073,709,551,616 addresses in the /64, but unfortunately not
respecting basic v6 subnetting rules causes reputation problems also for
the other customers that have the bad luck of living in the same /64 and
are using their VPS as an outgoing mail server.

While I'm not judging the reasons why VPS providers are doing this type of
useless v6 subnetting (micronetting?), I've started to deploy some
countermeasures to avoid FPs. Specifically I wrote a rule that identifies
if the last untrusted relay is a v6 address, and then is subsequently used
in other meta rules that subtract some points in dnsbl tests that check the
-lastexternal ip address on v6-aware lists.

I know that probably is not the best solution, but I've started to see
real FPs that worried me. I've even pondered if it could have sense to go
back to v4 only connectivity for my inbound mtas.

If you are in a similar situation I would like very much to discuss what
would be the best approach to balance spam detection while avoiding fps


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol. 

Re: Spammers, IPv6 addresses, and dnsbls

[Leandro]

2018-03-02 10:08 GMT-03:00 Matus UHLAR - fantomas :

> On 02.03.18 09:58, Leandro wrote:
>
>> Hi Danilele! Our DNSBL works with individual /128 IPv6 addresses:
>>
>> http://spfbl.net/en/dnsbl/
>>
>> Even if the provider is offering less then /64 to customers, our DNSBL can
>> list IPv6 of each one.
>>
>
> how/who do you list when spammer starts rotating IPs in assigned /64
> range?
>


If the spammer uses the same domain at rDNS, when rotating IPs, our system
will list each new IP at first DNSBL query.



> But do not use our DNSBL to reject messages. Use only for SA punctuation,
>> higher points to 127.0.0.2.
>>
>
>

Re: Spammers, IPv6 addresses, and dnsbls

[Leandro]

Hi Danilele! Our DNSBL works with individual /128 IPv6 addresses:

http://spfbl.net/en/dnsbl/

Even if the provider is offering less then /64 to customers, our DNSBL can
list IPv6 of each one.

But do not use our DNSBL to reject messages. Use only for SA punctuation,
higher points to 127.0.0.2.

Regards,

Leandro
SPFBL.net

2018-03-02 8:54 GMT-03:00 Daniele Duca :

> Hello list,
>
> apologies if this is not directly SA related. "Lately" I've started to
> notice that some (not saying names) VPS providers, when offering v6
> connectivity, sometimes tends to not follow the best practice of giving a
> /64 to their customer, routing to them much smaller v6 subnets, while still
> giving to them the usual /30 or /29 v4 subnets.
>
> What It's happening is that whenever a spammer buys a VPS with those
> providers and get blacklisted, most of the time the dnsbls list the whole
> v6 /64, while still listing only the single ipv4 address. This makes some
> senses, as it would be enormously resource intensive to track each of the
> 18,446,744,073,709,551,616 addresses in the /64, but unfortunately not
> respecting basic v6 subnetting rules causes reputation problems also for
> the other customers that have the bad luck of living in the same /64 and
> are using their VPS as an outgoing mail server.
>
> While I'm not judging the reasons why VPS providers are doing this type of
> useless v6 subnetting (micronetting?), I've started to deploy some
> countermeasures to avoid FPs. Specifically I wrote a rule that identifies
> if the last untrusted relay is a v6 address, and then is subsequently used
> in other meta rules that subtract some points in dnsbl tests that check the
> -lastexternal ip address on v6-aware lists.
>
> I know that probably is not the best solution, but I've started to see
> real FPs that worried me. I've even pondered if it could have sense to go
> back to v4 only connectivity for my inbound mtas.
>
> If you are in a similar situation I would like very much to discuss what
> would be the best approach to balance spam detection while avoiding fps
>
> Regards
>
> Daniele Duca
>
>

Spammers, IPv6 addresses, and dnsbls

[Daniele Duca]

Hello list,

apologies if this is not directly SA related. "Lately" I've started to 
notice that some (not saying names) VPS providers, when offering v6 
connectivity, sometimes tends to not follow the best practice of giving 
a /64 to their customer, routing to them much smaller v6 subnets, while 
still giving to them the usual /30 or /29 v4 subnets.


What It's happening is that whenever a spammer buys a VPS with those 
providers and get blacklisted, most of the time the dnsbls list the 
whole v6 /64, while still listing only the single ipv4 address. This 
makes some senses, as it would be enormously resource intensive to track 
each of the 18,446,744,073,709,551,616 addresses in the /64, but 
unfortunately not respecting basic v6 subnetting rules causes reputation 
problems also for the other customers that have the bad luck of living 
in the same /64 and are using their VPS as an outgoing mail server.


While I'm not judging the reasons why VPS providers are doing this type 
of useless v6 subnetting (micronetting?), I've started to deploy some 
countermeasures to avoid FPs. Specifically I wrote a rule that 
identifies if the last untrusted relay is a v6 address, and then is 
subsequently used in other meta rules that subtract some points in dnsbl 
tests that check the -lastexternal ip address on v6-aware lists.


I know that probably is not the best solution, but I've started to see 
real FPs that worried me. I've even pondered if it could have sense to 
go back to v4 only connectivity for my inbound mtas.


If you are in a similar situation I would like very much to discuss what 
would be the best approach to balance spam detection while avoiding fps


Regards

Daniele Duca