You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Sebastian Arcus <s....@open-t.co.uk> on 2017/12/23 08:03:26 UTC
IADB whitelist
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_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
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
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 <s....@open-t.co.uk> 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
>> <s....@open-t.co.uk> 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
><http://205.201.128.83> listed iniadb.isipp.com
><http://iadb.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
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: IADB whitelist
Posted by John Hardin <jh...@impsec.org>.
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.10 All 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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
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
Posted by "Anne P. Mitchell Esq." <am...@isipp.com>.
>
> 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.10 All 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.
amitchell@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell | LinkedIn/in/annemitchell
Re: IADB whitelist
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
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
Posted by "Anne P. Mitchell Esq." <am...@isipp.com>.
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.
amitchell@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell | LinkedIn/in/annemitchell
Re: IADB whitelist
Posted by "Anne P. Mitchell Esq." <am...@isipp.com>.
>
> '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.
amitchell@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell | LinkedIn/in/annemitchell
Re: IADB whitelist
Posted by "Anne P. Mitchell Esq." <am...@isipp.com>.
>
> 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.
amitchell@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell | LinkedIn/in/annemitchell
Re: IADB whitelist
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: IADB whitelist
Posted by Sebastian Arcus <s....@open-t.co.uk>.
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. "abuse@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
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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. "abuse@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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: IADB whitelist
Posted by Sebastian Arcus <s....@open-t.co.uk>.
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
>>> <s....@open-t.co.uk> 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
>>> <http://205.201.128.83> listed iniadb.isipp.com
>>> <http://iadb.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
Posted by Sebastian Arcus <s....@open-t.co.uk>.
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
> <s....@open-t.co.uk> 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 <http://205.201.128.83> listed iniadb.isipp.com <http://iadb.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
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
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 <s....@open-t.co.uk> 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_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/)