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

Reply via email to