Re: IADB whitelist - again

[Noel Butler]

On 06/03/2018 14:18, Dave Warren wrote:

> On 2018-03-04 05:46, David Jones wrote: 
> 
>> That's great.  It means you know what you are doing when you change the 
>> default threshold to less than 5.0.  In that case you need to change a lot 
>> of other scores down too including RCVD_IN_IADB_* and the KAM.cf rules 
>> probably score way too high for you as well.
> 
> Maybe this is just me, but I'm a firm believer that if you change the 
> thresholds, you don't get to complain about the scores of any rules. The 
> rules are all balanced against the target threshold of 5.0, and if you set 
> your threshold differently it is quite likely that some rules will be scored 
> too highly or two low for your needs.

or maybe its because the default rules were allowing way too much spam
into users inboxes, setting teh threshold lower, our users needs were
met -  less spam.

-- 
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

[Noel Butler]

On 06/03/2018 04:42, Luis E. Muñoz wrote:

> I would argue that the current scores work very well for default installs.

My experience shows otherwise 

>> That would be acceptable :)
> 
> I disagree. Knee-jerk changes to rule scores based on a single report that 
> contradicts what others are seeing is detrimental to the stability of SA. I'm 
> either responsible or consult for filters that process ~10 million messages 
> per day at a few corporate organizations where SA is used extensively in

only 10 million a day? thats not much, my experience is with large
national ISP's, wjhere we have to cater for  all types, techies, nerds,
mums and dads, and grandparents who do nothing more than send email or
skype, as well as businesses, hosting servers run teh same rules
residential systems use, these have been refined over a great number of
years. 

> both the inbound and outbound. Not a particularly large number nor more than 
> a few samples. Yet in all those cases I keep the default IADB scores in place 
> as they work well with our rule sets. The only message that was marked as 
> spam and triggered one of the IADB rules in my archive was sent by an 
> ex-customer of the IADB.
> 
> Based on my data, I'm seeing more false positives from other rules -- yet I'm 
> not proposing to change the default SA configuration because of this. I 
> understand that factors such as geography or my user base change 
> effectiveness.

false positives from bad guys scoring is one thing, being over reaching
with whitelisting scoring is another,  trust can only be earned, who I
trust will differ from who you trust, and so on, its why we score 0 many
common whitelist rules 

-- 
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

[Noel Butler]

On 04/03/2018 22:46, David Jones wrote:

>> Some us have very fine tuned SA's, and use less than 5.0 which was 
>> acceptable 10 years ago, but not in recent times, so a few .1's can mean 
>> user gets spam, V user doesnt get spam - I know what I prefer.
> 
> That's great.  It means you know what you are doing when you change the 
> default threshold to less than 5.0.  In that case you need to change a lot of 
> other scores down too including RCVD_IN_IADB_* and the KAM.cf rules probably 
> score way too high for you as well.

They do, we have a largish list of custom scores, as most admins who
know what they are doing would have, since SA never can cater for all
sites in any default configuration, thus allowing us to fine tune scores
to suite our own regions. 

> From what I have seen on this mailing list recommended for most SA admins is 
> to leave the default threshold of 5.0 and bump up the BAYES scores once you 
> have a well-trained Bayes DB.  Augment default scores with meta rules that 
> combine rule hits to "amplify" some scores a bit based on your mail flow and 
> current spam campaigns.

The default is exactly that, a default, it doesnt mean its the be all
and end all, its just a fall back average for those who dont want to
fine tune their systems.

-- 
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

[Dave Warren]

On 2018-03-04 05:46, David Jones wrote:
That's great.  It means you know what you are doing when you change the 
default threshold to less than 5.0.  In that case you need to change a 
lot of other scores down too including RCVD_IN_IADB_* and the KAM.cf 
rules probably score way too high for you as well.


Maybe this is just me, but I'm a firm believer that if you change the 
thresholds, you don't get to complain about the scores of any rules. The 
rules are all balanced against the target threshold of 5.0, and if you 
set your threshold differently it is quite likely that some rules will 
be scored too highly or two low for your needs.

Re: IADB whitelist - again

[Luis E. Muñoz]

On 3 Mar 2018, at 3:54, Noel Butler wrote:


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


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.


I would argue that the current scores work very well for default 
installs. Likely, many users of SA lack the skills and data required to 
optimize their setups, so they benefit from receiving an install that 
will work well enough out of the box.



That would be acceptable :)


I disagree. Knee-jerk changes to rule scores based on a single report 
that contradicts what others are seeing is detrimental to the stability 
of SA. I'm either responsible or consult for filters that process ~10 
million messages per day at a few corporate organizations where SA is 
used extensively in both the inbound and outbound. Not a particularly 
large number nor more than a few samples. Yet in all those cases I keep 
the default IADB scores in place as they work well with our rule sets. 
The only message that was marked as spam and triggered one of the IADB 
rules in my archive was sent by an ex-customer of the IADB.


Based on my data, I'm seeing more false positives from other rules -- 
yet I'm not proposing to change the default SA configuration because of 
this. I understand that factors such as geography or my user base change 
effectiveness.


Some rules are more or less effective due to bias 
https://esmtp.email/blog/2017/09/06/blacklist-bias/


At some point I did consider using the IADB rules as part of a metarule, 
but that proved not more useful than leaving the rules as they were, so 
I chalked that as a learning exercise and moved on.



(I usually disable all whitelists anyway, especially those scoring
influentially)


And this is sound advice to anyone with the skills to tune their SA 
installation according to their specific needs. However this is probably 
not so true for people that installs SA and leaves the default 
configuration in place. Be it the one that SA ships or the one their 
preferred linux distribution provides.


Best regards

-lem

Re: IADB whitelist - again

[David Jones]

On 03/03/2018 06:26 PM, Noel Butler wrote:

On 03/03/2018 23:45, David Jones wrote:


On 03/03/2018 05:54 AM, Noel Butler wrote:

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


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


If you have properly tuned SA for your mail flow and added local 
rules/plugins, these default IADB scores should not cause real spam to 
score under the default 5.0 threshold.



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


That would be acceptable :)


Some us have very fine tuned SA's, and use less than 5.0 which was 
acceptable 10 years ago, but not in recent times, so a few .1's can mean 
user gets spam, V user doesnt get spam - I know what I prefer.




That's great.  It means you know what you are doing when you change the 
default threshold to less than 5.0.  In that case you need to change a 
lot of other scores down too including RCVD_IN_IADB_* and the KAM.cf 
rules probably score way too high for you as well.


From what I have seen on this mailing list recommended for most SA 
admins is to leave the default threshold of 5.0 and bump up the BAYES 
scores once you have a well-trained Bayes DB.  Augment default scores 
with meta rules that combine rule hits to "amplify" some scores a bit 
based on your mail flow and current spam campaigns.


--
David Jones

Re: IADB whitelist - again

[Noel Butler]

On 03/03/2018 23:45, David Jones wrote:

> On 03/03/2018 05:54 AM, Noel Butler wrote: On 03/03/2018 11:40, John Hardin 
> wrote:
> 
> 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 
If you have properly tuned SA for your mail flow and added local
rules/plugins, these default IADB scores should not cause real spam to
score under the default 5.0 threshold.

>> -0.001 surely... 0 = disabled = breaks dependencies.
> That would be acceptable :)

Some us have very fine tuned SA's, and use less than 5.0 which was
acceptable 10 years ago, but not in recent times, so a few .1's can mean
user gets spam, V user doesnt get spam - I know what I prefer. 

-- 
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

[David Jones]

On 03/03/2018 05:54 AM, Noel Butler wrote:

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


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




If you have properly tuned SA for your mail flow and added local 
rules/plugins, these default IADB scores should not cause real spam to 
score under the default 5.0 threshold.



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


That would be acceptable :)


--
David Jones

Re: IADB whitelist - again

[Noel Butler]

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

> 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.

That would be acceptable :)  

(I usually disable all whitelists anyway, especially those scoring
influentially) 

-- 
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

[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

[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

[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

[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: 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

[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

[Luis E. Muñoz]

On 1 Mar 2018, at 10:29, 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:


(Disclaimer, I have inner visibility into IADB and its processes)

I'm sorry, but it only seems "ridiculous" if you don't know how IADB 
works. Hopefully the details below will be helpful to assuage your 
worries.



-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


It really raises some very uncomfortable questions regarding the 
impartiality of SA and/or its anti-spam capabilities.


IADB provides a number of "signals" associated with the (vetted) 
practices of senders participating in its certification program. The 
purpose of the DNS data is to allow receivers to use those signals to 
augment their local anti-spam systems or to tweak the rules that are 
applied for filtering.


Claiming that IADB is an "anti-spam" resource is inaccurate, as this is 
not its intended purpose.


Rather, IADB allows for more precise filtering. Something that is also 
indirectly achieved, is that complaints sent to IADB's administration 
are escalated, researched and tracked until resolution, which can (and 
has!) include termination of the accreditation in the IADB.


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.


Then by all means, include ab...@isipp.com in your complaint -- They'll 
follow up with their customer and if applicable revoke their IADB 
membership. This is no different from an ESP sending to an "imported" 
email address. A complaint would be more helpful than this posting, as 
it would provide for more data to track the actual campaign that caused 
the issue, again, much like in the case of an ESP.


From memory, I haven't seen a single complaint against the organization 
199.127.240.84 is accredited under in more than two years.


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?


In this case the IADB is confirming that at the time of their customer's 
accreditation, he claimed that his IP address should always have a valid 
rDNS and be covered by a valid SPF record. I happen to know of receivers 
that use lack of SPF/rDNS + these IADB records to bounce email.


As I'm sure it was mentioned before, the default scores are (or try to 
be) a balance useful for general cases. I've been running with defaults 
for these particular rules for years with no ill effect.


Best regards

-lem

Re: IADB whitelist - again

[David Jones]

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.


--
David Jones

Re: IADB whitelist - again

[Anne P. Mitchell Esq.]

 
> 
> 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_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
>> 
>> 
>> 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.
> 
> 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").
> 
> The scores appear hardcoded (50_scores.cf) vs. from masscheck (72_scores.cf) 
> so they may be *very* stale.

The IADB codes were designed in conjunction with Craig Hughes, who at the time 
was very involved with SA, for the specific purpose of allowing SA, and other 
systems like SA, to take advantage of the very granular nature of the codes 
for, as John observes, local (and very fine) tuning.   It is not up to us to 
tell receivers what email they should and should not choose to deliver - it is 
up to us to give receivers as much *useful* information as possible.Some 
receivers actually want to deliver single opt-in mail so long as they can 
confirm enough other data points about the email and the sender themselves.

In fact, many of our data response codes were developed at the request of 
receivers such as SA, Spamcop, and others.

One of the reasons that we receive the scores that we do is because we are a 
trusted source of data (for which we are very proud)  - because I came out of 
MAPS (I was their in-house counsel), and any email person in our org comes from 
the anti-spam side as well - we all view our first responsibility as being to 
the receivers who use our data, not the senders who are certified with us.  
Too, folks in the receiving industries know that we take abuse reports (we 
don't receive many, but of course we do receive some) *very* seriously, and 
have no problem firing a sender if they stray to the dark - or heck, even gray 
or slightly soiled white - side. (It helps that we have no contract, and no 
sender pays us very much, so it's very easy to fire them and there is no 
financial incentive to keep any particular sender on. ;-) ) 

We make sure that our senders are - and stay - white hat.  We are unique in 
that way, and that was the promise when we worked with SA in the beginning, and 
we have kept that promise.

Anyone applying for certification with us has to pass a stringent, exhaustive 
background check in terms of their mailing practices, their email reputation, 
etc..

Relatedly, and somewhat humourously, if you look at our codes, they include 
codes such as:

127.3.100.2 Accepts unverified sign-ups such as through web page
127.3.100.3 Accepts unverified sign-ups, gives chance to opt out

Of *course* we would *never* certify anyone to whom those codes would apply, 
but *they* don't know that - those codes are there as 'trick questions', if you 
will.  Anyone applying for certification who checks those boxes doesn't even 
get in the door, let alone through our background check.

P.S.  You will probably have noted in my .sig that I authored part of CAN-SPAM. 
 While CAN-SPAM is essentially a joke for the most part, I'm actually very 
proud of the work I did on Section 6* - it's one of the few aspects of CAN-SPAM 
with teeth - 

Re: IADB whitelist - again

[John Hardin]

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_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


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.


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").


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



--
 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
---
  ...to announce there must be no criticism of the President or to
  stand by the President right or wrong is not only unpatriotic and
  servile, but is morally treasonous to the American public.
  -- Theodore Roosevelt, 1918
---
 12 days until Albert Einstein's 139th Birthday

IADB whitelist - again

[Sebastian Arcus]

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


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?

Re: IADB whitelist

[Bill Cole]

On 26 Dec 2017, at 15:04 (-0500), Anne P. Mitchell Esq. wrote:

Bill, thank you for this excellent explanation, and for the kind 
words!


I'm glad you didn't find anything glaringly incorrect or derogatory 
about my external-view explanation. And of course I stand by every kind 
word.


[...]
However, the different responses from IADB are VERY nuanced and the 
two strongest rules you listed (RCVD_IN_IADB_OPTIN and 
RCVD_IN_IADB_VOUCHED) are essentially "good intentions" markers.
Due to unfortunate terminology choices by ISIPP and a willingness to 
engage in nuance and estimate intentions, those aren't really as 
worthwhile as they might seem.


Hey Bill - can you please elaborate on the terminology choices which 
you see as unfortunate?


You know I'm a bomb-throwing radical... :)

I don't like calling unconfirmed opt-in simply "opt-in" because without 
a confirmation exchange, it can be de facto opt-out. It is hard for 
people who haven't been the target of massive subscription bombings to 
appreciate how pernicious the lack of confirmation can be.


We are *always* open to input.  Where we say "opt-in" we mean exactly 
that - single opt-in;  if someone didn't ask for the email not only 
would we call that "opt-out", but we would not certify that sender's 
email.


[Skipping a pointless tirade on the obfuscatory "single" vs. "double" 
jargon: that battle is long lost.]


The problem: unconfirmed opt-in mail is usually mostly opt-in but is 
definitely occasionally de facto opt-out. "100% opt-in" asserts a 
certainty that isn't possible without a confirmation step. You know 
this, or you wouldn't differentiate between unconfirmed and confirmed 
opt-in.


And if one of our senders is sending spam where they claim that all of 
their mailings are 100% opt-in (at least) we want to know, 
because...whack!


Side-stepping the eternal "define spam" trap, I have no doubt that you 
are willing to whack spammers. That's why I have never reported the 
chronic MailChimp & SendGrid (both shown as SuretyMail customers on the 
website) spamming of addresses that absolutely, positively, NEVER opted 
in to anything. Their business models force them to trust customers to 
some degree about address provenance and gullible customers may not 
grasp that they cannot buy "opt-in" lists. I'm pretty sure that some of 
the folks who spammed my unpublished, never-opted-in former work address 
(plus a small fixed set of my colleagues) via those ESP's had no idea 
that they were in possession of a list generated by spyware or pure 
guesswork. I'd guess that the original creator of that list claimed it 
was a 100% safe-to-mail opt-in list of qualified IT management sales 
leads and sold it on that false premise.


Should SendGrid or MailChimp have had their ISIPP SuretyMail accounts 
whacked because each had multiple gullible customers who trusted a list 
vendor? I think the answer is "no" because in all of those cases, the 
evidence implies that the ESPs were acting quickly and effectively on 
spam reports. Would you kick the ESPs out if I'd reported them? Probably 
not after 1 incident but maybe after a few dozen in a quarter. The IADB 
responses for the MailChimp IP that started this thread seem accurate to 
the extent possible given the epistemology of consent and provenance. I 
think that sort of policy & practice transparency is a good thing. It is 
a good thing that a nuanced and trustworthy description of their policy 
& practice is available, even if it requires an understanding of the 
limits of what an ESP can actually know about a list they did not 
generate.


Seriously, we are always open to feedback, and if a change in 
terminology is warranted we have no problem doing that (we also are 
happy to create a custom zone based on whatever the receiver wants for 
those who would like zones with highly specific profiles of the IPs 
therein - some receivers do that because they can't take advantage of 
the granularity of the data in our zones (although that is not the 
case for SA...in fact our data response codes were *specifically* 
created for SA because SA *can* take advantage of that level of 
granularity)).


As much as I dislike the single/double wording and the use of '100% 
opt-in' for mechanisms that are highly fallible, I am not sure that 
switching to better wording would be a good idea at this point. The 
sunset for establishing more precisely correct jargon for email consent 
was probably in 2003 or so.



--
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: IADB whitelist

[Anne P. Mitchell Esq.]

 
> 
> My sense is that ESPs engage ISIPP thinking they are getting an advocate and 
> ambassador to mailbox providers when in fact they get a teacher/evangelist 
> for sender best practices.

ITYM 'schooled in best practices. ;-) ;-)

Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Attorney at Law / Legislative Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Member, Board of Directors, Asilomar Microcomputer Workshop
Member, Advisory Board, Cause for Awareness
Member, Elevations Credit Union Member Council
Former Chair, Asilomar Microcomputer Workshop
Ret. Professor of Law, Lincoln Law School of San Jose

Available for consultations by special arrangement.
amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell

Re: IADB whitelist

[Bill Cole]

On 26 Dec 2017, at 9:46 (-0500), Sebastian Arcus wrote:

So you will excuse me if I take any whitelist which helps marketing 
emailing lists "improve deliverability" with a very big dollop of 
salt.


Of course. I don't give significant ham weight to any of the default 
IADB rules other than RCVD_IN_IADB_ML_DOPTIN, RCVD_IN_IADB_DOPTIN, and 
RCVD_IN_IADB_OOO.


IADB helps improve deliverability in part by having that myriad of 
responses which each mean something different, which both lets receivers 
know sender practice in fine detail AND provides (in theory) an 
incentive for the sender to do better. My sense is that ESPs engage 
ISIPP thinking they are getting an advocate and ambassador to mailbox 
providers when in fact they get a teacher/evangelist for sender best 
practices.


--
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: IADB whitelist

[John Hardin]

On Tue, 26 Dec 2017, Anne P. Mitchell Esq. wrote:


What do you call *verified* opt-in (what the marketers call "double opt-in"), 
where the recipient needs to comfirm that they gave permission for contact via that email 
address before receiving any content, in order to avoid unwanted third-party 
subscriptions?


Confirmed opt-in, which is what it was called back at MAPS and when we launched 
SuretyMail.

Even there we have granular breakdowns, such as:

127.3.100.8 All mailing list mail is at least opt-in, and has a confirmed 
(double) opt-in mechanism available, used less than 50% of the time
127.3.100.9 All mailing list mail is at least opt-in, and has a confirmed 
(double) opt-in mechanism available, used more than 50% of the time
127.3.100.10All mailing list mail is confirmed (double) opt-in


Beautiful, thanks!


---

(Note that we include the 'double' term (even though I feel I have to shower 
after typing it)


likewise. :)


--
 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
---
  The question of whether people should be allowed to harm themselves
  is simple. They *must*.   -- Charles Murray
---
 271 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: IADB whitelist

[Anne P. Mitchell Esq.]

 
> 
> What do you call *verified* opt-in (what the marketers call "double opt-in"), 
> where the recipient needs to comfirm that they gave permission for contact 
> via that email address before receiving any content, in order to avoid 
> unwanted third-party subscriptions?

Confirmed opt-in, which is what it was called back at MAPS and when we launched 
SuretyMail.

Even there we have granular breakdowns, such as:

127.3.100.8 All mailing list mail is at least opt-in, and has a confirmed 
(double) opt-in mechanism available, used less than 50% of the time
127.3.100.9 All mailing list mail is at least opt-in, and has a confirmed 
(double) opt-in mechanism available, used more than 50% of the time
127.3.100.10All mailing list mail is confirmed (double) opt-in

---

(Note that we include the 'double' term (even though I feel I have to shower 
after typing it) because that is the vernacular with which more senders are 
familiar.

Also note that there are data response codes that we would, in fact, almost 
never (if ever) use, but which are *great* for applicant screening - so for 
example if an applicant says:

"Accepts unverified sign-ups such as through web page" (which is one of our 
codes)

...they are never actually going to get certified (unless we can educate them 
and they actually change their wicked ways).


You can see the full list of codes here:

http://www.isipp.com/email-accreditation/about-the-codes/list-of-codes/

Anne

Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Attorney at Law / Legislative Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Member, Board of Directors, Asilomar Microcomputer Workshop
Member, Advisory Board, Cause for Awareness
Member, Elevations Credit Union Member Council
Former Chair, Asilomar Microcomputer Workshop
Ret. Professor of Law, Lincoln Law School of San Jose

Available for consultations by special arrangement.
amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell

Re: IADB whitelist

[John Hardin]

On Tue, 26 Dec 2017, Anne P. Mitchell Esq. wrote:

Where we say "opt-in" we mean exactly that - single opt-in;  if someone 
didn't ask for the email not only would we call that "opt-out", but we 
would not certify that sender's email.


What do you call *verified* opt-in (what the marketers call "double 
opt-in"), where the recipient needs to comfirm that they gave permission 
for contact via that email address before receiving any content, in order 
to avoid unwanted third-party subscriptions?


--
 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
---
  If you ask amateurs to act as front-line security personnel,
  you shouldn't be surprised when you get amateur security.
-- Bruce Schneier
---
 271 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: IADB whitelist

[Anne P. Mitchell Esq.]

 
> 
> 'magically' re-subscribe after a while, or simply get around rules by 
> creating a new list and re-subscribing everybody who unsubscribed.

Just so you know, that behavior is specifically made illegal by CAN-SPAM.  And 
Sebastian, I see that you are in the UK, which already has tighter laws.

Anne

Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Attorney at Law / Legislative Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Member, Board of Directors, Asilomar Microcomputer Workshop
Member, Advisory Board, Cause for Awareness
Member, Elevations Credit Union Member Council
Former Chair, Asilomar Microcomputer Workshop
Ret. Professor of Law, Lincoln Law School of San Jose

Available for consultations by special arrangement.
amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell

Re: IADB whitelist

[Anne P. Mitchell Esq.]

Bill, thank you for this excellent explanation, and for the kind words!

For those of you who don't know us, or me, I came out of MAPS;  I was in-house 
counsel for MAPS during the first rash of lawsuits against MAPS brought by 
spammers.  To say that I am rabidly anti-spam would be an understatement.

ISIPP, and our SuretyMail service, were founded by me a year and a bit after I 
left MAPS.  As such, our priority has always been, and remains, first and 
foremost, to the *receivers* - ISPs, spam filters, and any receiver who is 
using our data/zones.

It is true that the senders are our paying customers, however by design the 
amount of monies we receive from any given customer is small enough that the 
pleasure of whacking a spammer far outweighs any downside of giving a paying 
customer the boot if they are not doing The Right Thing.  Plus, we have a very 
extensive background check that we put a potential customer (sender) through 
before we will certify them.  We reject plenty of applicants.

> However, the different responses from IADB are VERY nuanced and the two 
> strongest rules you listed (RCVD_IN_IADB_OPTIN and RCVD_IN_IADB_VOUCHED) are 
> essentially "good intentions" markers.
> Due to unfortunate terminology choices by ISIPP and a willingness to engage 
> in nuance and estimate intentions, those aren't really as worthwhile as they 
> might seem. 

Hey Bill - can you please elaborate on the terminology choices which you see as 
unfortunate? We are *always* open to input.  Where we say "opt-in" we mean 
exactly that - single opt-in;  if someone didn't ask for the email not only 
would we call that "opt-out", but we would not certify that sender's email.  
And if one of our senders is sending spam where they claim that all of their 
mailings are 100% opt-in (at least) we want to know, because...whack!

Seriously, we are always open to feedback, and if a change in terminology is 
warranted we have no problem doing that (we also are happy to create a custom 
zone based on whatever the receiver wants for those who would like zones with 
highly specific profiles of the IPs therein - some receivers do that because 
they can't take advantage of the granularity of the data in our zones (although 
that is not the case for SA...in fact our data response codes were 
*specifically* created for SA because SA *can* take advantage of that level of 
granularity)).

Anne

Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Attorney at Law / Legislative Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Member, Board of Directors, Asilomar Microcomputer Workshop
Member, Advisory Board, Cause for Awareness
Member, Elevations Credit Union Member Council
Former Chair, Asilomar Microcomputer Workshop
Ret. Professor of Law, Lincoln Law School of San Jose

Available for consultations by special arrangement.
amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell

Re: DMARC and mailing lists (was Re: IADB whitelist)

[Matus UHLAR - fantomas]

Matus UHLAR - fantomas skrev den 2017-12-26 18:49:


have you never been subscribed to spammers' blacklist without your
permission?


On 26.12.17 19:01, Benny Pedersen wrote:

hopefully apache.org does know how to handle spam


you did not narrow your sentence on apache mailing lists, perhaps you
should.

--
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.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]

Re: DMARC and mailing lists (was Re: IADB whitelist)

[Benny Pedersen]

Matus UHLAR - fantomas skrev den 2017-12-26 18:49:


have you never been subscribed to spammers' blacklist without your
permission?


hopefully apache.org does know how to handle spam

Re: DMARC and mailing lists (was Re: IADB whitelist)

[Matus UHLAR - fantomas]

RW skrev den 2017-12-26 18:05:

I didn't receive any posts in "IADB whitelist" thread from the OP
because they all failed DMARC with a reject policy. I found the posts
on gmane.


On 26.12.17 18:21, Benny Pedersen wrote:

stop reject maillists no matter if dmarc fails


have you never been subscribed to spammers' blacklist without your
permission?

--
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.
Microsoft dick is soft to do no harm

Re: DMARC and mailing lists (was Re: IADB whitelist)

[Benny Pedersen]

RW skrev den 2017-12-26 18:05:

I didn't receive any posts in "IADB whitelist" thread from the OP
because they all failed DMARC with a reject policy. I found the posts
on gmane.


stop reject maillists no matter if dmarc fails


Posting to mailing lists with a domain using a strict DMARC policy is
inherently risky because you are losing the redundancy of an aligned 
SPF

pass and there's a lot that can go wrong with DKIM.


policy reject is safe on spamassaasin maillist just like it is on 
postfix maillist, but you report a diffrent problem that does not help 
it



In this case the open-t.co.uk DKIM signature signed "reply-to" and a
lot of "list-*" headers that are added by the list. This guaranteed a
DKIM fail downstream of the list servers.


this is the error, sadly systems try to sign all headers without 
understanding what happend with this



I thought it as worth pointing this out to avoid others making similar
mistakes. However, DMARC problems could generally be mitigated by the
listservers adding ARC headers.


makw apache.org reject dmarc fails, possible ?, opendkim can test unsafe 
header signed


for maillist members add hermes.apache.org to opendkim AND opendmarc 
trusted sender ip


arc is basicly help make it worse :(

note signed headers on my post here, its default in opendkim, if more 
headers is signed it dmarc unsafe

DMARC and mailing lists (was Re: IADB whitelist)

[RW]

I didn't receive any posts in "IADB whitelist" thread from the OP
because they all failed DMARC with a reject policy. I found the posts
on gmane.

Posting to mailing lists with a domain using a strict DMARC policy is
inherently risky because you are losing the redundancy of an aligned SPF
pass and there's a lot that can go wrong with DKIM.

In this case the open-t.co.uk DKIM signature signed "reply-to" and a
lot of "list-*" headers that are added by the list. This guaranteed a
DKIM fail downstream of the list servers.

I thought it as worth pointing this out to avoid others making similar
mistakes. However, DMARC problems could generally be mitigated by the
listservers adding ARC headers.




 

Re: IADB whitelist

[Sebastian Arcus]

On 25/12/17 23:57, Bill Cole wrote:

On 25 Dec 2017, at 3:28 (-0500), Sebastian Arcus wrote:

Also, any idea why are there 6 different rules associated with this 
particular whitelist?


IADB has many independent return codes that each have distinct meaning. 
See 
http://www.isipp.com/email-accreditation/about-the-codes/list-of-codes/ 
for details.


If you get mail from an IADB-listed sender that you are 100% sure is 
spam (i.e. not "I would never ask for such mail" but "the recipient 
absolutely did not consent to receiving this mail.") then you should 
report that to ISIPP. "ab...@suretymail.com" is the reporting address 
listed on their website and while I've not had cause to use it, people I 
trust with no reason to lie say that reports to that address do actually 
work to either change sender behavior or eliminate listings. Anne 
Mitchell (head of ISIPP) is an ex-coworker of mine whose integrity and 
dedication to the anti-spam fight (which is dependent on keeping 
*wanted* mail deliverable) I can personally vouch for.


However, the different responses from IADB are VERY nuanced and the two 
strongest rules you listed (RCVD_IN_IADB_OPTIN and RCVD_IN_IADB_VOUCHED) 
are essentially "good intentions" markers. Due to unfortunate 
terminology choices by ISIPP and a willingness to engage in nuance and 
estimate intentions, those aren't really as worthwhile as they might 
seem. The IADB definition of "All mailing list mail is opt-in" is 
(effectively) "we believe that this ESP believes in good faith that 
every recipient has chosen to receive this mail." Their "vouching" for a 
record is an assertion that either the ESP is personally known to ISIPP 
staff as competent and honest OR has maintained stable positive listings 
for >6 months. I'm pretty sure I don't want ANY score for a non-vouched 
record and unlike ISIPP (and some valuable SA contributors!) I really 
don't care much about ESPs' intentions or responsiveness to complaints, 
only about actual spamming behavior. So I have made substantial 
modification on my own system to how IADB results are scored, but those 
specific adjustments are probably not fit for most other sites.


Thank you for a detailed reply. Like you as well, I don't put much 
weight on what ESP's say they do or intend to do. I'm afraid the email 
marketing industry is rather murky and the line between legitimate 
marketing and spamming is often pretty much non-existent - with 
apologies to those few operators who actually run an honest operation. I 
see daily examples of supposedly legit operators who don't actually act 
on unsubscribe requests, or 'magically' re-subscribe after a while, or 
simply get around rules by creating a new list and re-subscribing 
everybody who unsubscribed. And frankly, the whole issue of consent is 
blurred beyond any usefulness. If you have ever made the mistake of 
leaving the tick box selected for "receive offers from our carefully 
selected partners", it is virtually impossible to take that consent 
back, as your email address gets passed from database to database, never 
to be removed again. Besides, with most people purchasing things from so 
many different sources, and creating accounts on so many websites, how 
many would actually be able to say for sure (and prove it) that they 
never gave consent to be emailed by "carefully selected partners"? So 
you will excuse me if I take any whitelist which helps marketing 
emailing lists "improve deliverability" with a very big dollop of salt.

Re: IADB whitelist

[Bill Cole]

On 25 Dec 2017, at 3:28 (-0500), Sebastian Arcus wrote:

Also, any idea why are there 6 different rules associated with this 
particular whitelist?


IADB has many independent return codes that each have distinct meaning. 
See 
http://www.isipp.com/email-accreditation/about-the-codes/list-of-codes/ 
for details.


If you get mail from an IADB-listed sender that you are 100% sure is 
spam (i.e. not "I would never ask for such mail" but "the recipient 
absolutely did not consent to receiving this mail.") then you should 
report that to ISIPP. "ab...@suretymail.com" is the reporting address 
listed on their website and while I've not had cause to use it, people I 
trust with no reason to lie say that reports to that address do actually 
work to either change sender behavior or eliminate listings. Anne 
Mitchell (head of ISIPP) is an ex-coworker of mine whose integrity and 
dedication to the anti-spam fight (which is dependent on keeping 
*wanted* mail deliverable) I can personally vouch for.


However, the different responses from IADB are VERY nuanced and the two 
strongest rules you listed (RCVD_IN_IADB_OPTIN and RCVD_IN_IADB_VOUCHED) 
are essentially "good intentions" markers. Due to unfortunate 
terminology choices by ISIPP and a willingness to engage in nuance and 
estimate intentions, those aren't really as worthwhile as they might 
seem. The IADB definition of "All mailing list mail is opt-in" is 
(effectively) "we believe that this ESP believes in good faith that 
every recipient has chosen to receive this mail." Their "vouching" for a 
record is an assertion that either the ESP is personally known to ISIPP 
staff as competent and honest OR has maintained stable positive listings 
for >6 months. I'm pretty sure I don't want ANY score for a non-vouched 
record and unlike ISIPP (and some valuable SA contributors!) I really 
don't care much about ESPs' intentions or responsiveness to complaints, 
only about actual spamming behavior. So I have made substantial 
modification on my own system to how IADB results are scored, but those 
specific adjustments are probably not fit for most other sites.


--
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: IADB whitelist

[Sebastian Arcus]

On 25/12/17 10:45, Reindl Harald wrote:



Am 25.12.2017 um 09:28 schrieb Sebastian Arcus:

On 23/12/17 10:01, Kevin A. McGrail wrote:
The 1st step is that a representaive of the rbl asks us to consider 
for inclusion.


Thank you. If enough people receive spam sanctioned by a particular 
whitelist, will the minus scores associated with their rule(s) be 
reduced over time?


maybe, but why not just override the score in local.cf

/etc/mail/spamassassin/local-*.cf
score RCVD_IN_IADB_DK -0.3
score RCVD_IN_IADB_DOPTIN -1.0
score RCVD_IN_IADB_DOPTIN_GT50 -0.5
score RCVD_IN_IADB_DOPTIN_LT50 -0.1
score RCVD_IN_IADB_LISTED -0.001
score RCVD_IN_IADB_ML_DOPTIN -2.5
score RCVD_IN_IADB_OPTIN -0.05
score RCVD_IN_IADB_OPTIN_GT50 -0.2
score RCVD_IN_IADB_OPTIN_LT50 -0.1
score RCVD_IN_IADB_RDNS -0.05
score RCVD_IN_IADB_SENDERID -0.5
score RCVD_IN_IADB_SPF -0.1
score RCVD_IN_IADB_VOUCHED -2.0


I know I can override the scores for all sorts of things in local.cf. 
The reason I was raising the question is because I was wondering if 
whitelists can be used by unscrupulous marketing organisations to 
effectively undo what is one of the main functions of SA - to reduce or 
stop unsolicited email.




Also, any idea why are there 6 different rules associated with this 
particular whitelist?


these are 6 different lists, just read the description you even posted 
on the right side of the score


Well, they might be technically 6 different lists, but IADB is one 
single entity, and including 6 different whitelists from them only looks 
like a way to reduce the SA score for email from their "certified" 
senders further. After all SA already checks separately for things like 
RDNS, DKIM, SPF.







On December 23, 2017 3:03:26 AM EST, Sebastian Arcus 
 wrote:


    What is the process of including whitelists in SA default 
configs? It is

    not the first time I see pretty obvious mailing list spam which has
    quite high minus scores from 2-3 whitelists included in SA:

    -1.5 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is 
opt-in
   [205.201.128.83 
  listed iniadb.isipp.com 
]
    -0.1 RCVD_IN_IADB_DK    RBL: IADB: Sender publishes Domain 
Keys record

    -0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
    -0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID 
record
    -2.2 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for 
sender

    -0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
    -0.0 RCVD_IN_IADB_LISTED    RBL: Participates in the IADB system
    -0.0 RCVD_IN_IADB_OPTIN_GT50 RBL: IADB: Opt-in used more than 50% 
of the

    time


    For the same message, Pyzor has a high score - which is correct:

    2.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
   [cf: 100]
    2.5 RAZOR2_CHECK   Listed in Razor2 (http://razor.sf.net/)

Re: IADB whitelist

[Kevin A. McGrail]

I certainly look at all fns and fps and make changes to try and fix things in 
the overall ecosystem.  

If you have evidence of such problems, throw it in pastebin.

Beyond that I don't usually focus on one rule and you can always override 
scores / disable rules in your own cf file.

I don't remember about iadb but I know isipp is open to input.  You should ask 
them about the 6 rules.
Merry Christmas,
KAM

On December 25, 2017 3:28:11 AM EST, Sebastian Arcus  
wrote:
>On 23/12/17 10:01, Kevin A. McGrail wrote:
>> The 1st step is that a representaive of the rbl asks us to consider
>for 
>> inclusion.
>
>Thank you. If enough people receive spam sanctioned by a particular 
>whitelist, will the minus scores associated with their rule(s) be 
>reduced over time? Also, any idea why are there 6 different rules 
>associated with this particular whitelist?
>
>
>
>> Regards,
>> KAM
>> 
>> On December 23, 2017 3:03:26 AM EST, Sebastian Arcus 
>>  wrote:
>> 
>> What is the process of including whitelists in SA default
>configs? It is
>> not the first time I see pretty obvious mailing list spam which
>has
>> quite high minus scores from 2-3 whitelists included in SA:
>> 
>> -1.5 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is
>opt-in
>>[205.201.128.83
>  listed iniadb.isipp.com
>]
>> -0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain
>Keys record
>> -0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS
>record
>> -0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID
>record
>> -2.2 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for
>sender
>> -0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF
>record
>> -0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
>> -0.0 RCVD_IN_IADB_OPTIN_GT50 RBL: IADB: Opt-in used more than 50%
>of the
>> time
>> 
>> 
>> For the same message, Pyzor has a high score - which is correct:
>> 
>> 2.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above
>50%
>>[cf: 100]
>> 2.5 RAZOR2_CHECK   Listed in Razor2
>(http://razor.sf.net/)
>> 

Re: IADB whitelist

[Sebastian Arcus]

On 23/12/17 10:01, Kevin A. McGrail wrote:
The 1st step is that a representaive of the rbl asks us to consider for 
inclusion.


Thank you. If enough people receive spam sanctioned by a particular 
whitelist, will the minus scores associated with their rule(s) be 
reduced over time? Also, any idea why are there 6 different rules 
associated with this particular whitelist?





Regards,
KAM

On December 23, 2017 3:03:26 AM EST, Sebastian Arcus 
 wrote:


What is the process of including whitelists in SA default configs? It is
not the first time I see pretty obvious mailing list spam which has
quite high minus scores from 2-3 whitelists included in SA:

-1.5 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
   [205.201.128.83   listed 
iniadb.isipp.com ]
-0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record
-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-2.2 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
-0.0 RCVD_IN_IADB_OPTIN_GT50 RBL: IADB: Opt-in used more than 50% of the
time


For the same message, Pyzor has a high score - which is correct:

2.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
   [cf: 100]
2.5 RAZOR2_CHECK   Listed in Razor2 (http://razor.sf.net/)

Re: IADB whitelist

[Kevin A. McGrail]

The 1st step is that a representaive of the rbl asks us to consider for 
inclusion. 
Regards,
KAM

On December 23, 2017 3:03:26 AM EST, Sebastian Arcus  
wrote:
>What is the process of including whitelists in SA default configs? It
>is 
>not the first time I see pretty obvious mailing list spam which has 
>quite high minus scores from 2-3 whitelists included in SA:
>
>-1.5 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
>  [205.201.128.83 listed in iadb.isipp.com]
>-0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys
>record
>-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
>-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID
>record
>-2.2 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender
>-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
>-0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
>-0.0 RCVD_IN_IADB_OPTIN_GT50 RBL: IADB: Opt-in used more than 50% of
>the 
>time
>
>
>For the same message, Pyzor has a high score - which is correct:
>
>2.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
>  [cf: 100]
>2.5 RAZOR2_CHECK   Listed in Razor2 (http://razor.sf.net/)

IADB whitelist

[Sebastian Arcus]

What is the process of including whitelists in SA default configs? It is 
not the first time I see pretty obvious mailing list spam which has 
quite high minus scores from 2-3 whitelists included in SA:


-1.5 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
 [205.201.128.83 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record
-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-2.2 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
-0.0 RCVD_IN_IADB_OPTIN_GT50 RBL: IADB: Opt-in used more than 50% of the 
time



For the same message, Pyzor has a high score - which is correct:

2.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
 [cf: 100]
2.5 RAZOR2_CHECK   Listed in Razor2 (http://razor.sf.net/)