Re: IADB whitelist - again
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
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
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
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: Spammers, IPv6 addresses, and dnsbls
On 03/02/2018 12:54 PM, Daniele Duca wrote: Hello list, apologies if this is not directly SA related. "Lately" I've started to notice that some (not saying names) VPS providers, when offering v6 connectivity, sometimes tends to not follow the best practice of giving a /64 to their customer, routing to them much smaller v6 subnets, while still giving to them the usual /30 or /29 v4 subnets. If you are in a similar situation I would like very much to discuss what would be the best approach to balance spam detection while avoiding fps This is not related to SA = Off-Topic There are more adequate lists for this kind of discussion (Mailop list, for example)
Re: IADB whitelist - again
On 03/02/2018 02:54 AM, Sebastian Arcus wrote: On 01/03/18 19:50, David Jones wrote: On 03/01/2018 12:29 PM, Sebastian Arcus wrote: I know I have brought up this issue on this list before, and sorry for the persistence, but having 7 different rules adding scores for the IADB whitelist still seems either ridiculous, or outright suspect: -0.2 RCVD_IN_IADB_RDNS RBL: IADB: Sender has reverse DNS record [199.127.240.84 listed in iadb.isipp.com] -0.1 RCVD_IN_IADB_SPF RBL: IADB: Sender publishes SPF record -0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in -0.0 RCVD_IN_IADB_SENDERID RBL: IADB: Sender publishes Sender ID record -0.0 RCVD_IN_IADB_LISTED RBL: Participates in the IADB system -0.1 RCVD_IN_IADB_DK RBL: IADB: Sender publishes Domain Keys record -0.1 RCVD_IN_IADB_VOUCHED RBL: ISIPP IADB lists as vouched-for sender It really raises some very uncomfortable questions regarding the impartiality of SA and/or its anti-spam capabilities. And by the way, this message is definitely unsolicited, and in now way we gave any sort of permission or consent to this company or its "affiliates" to email us - so the whole "All mailing list mail is opt-in" is nonsense. And why have "Sender has reverse DNS record" and "Sender publishes SPF record" as separate IADB rules - when SA itself already checks for these? Isn't this just a glaring way of pumping up SA scores for the IADB subscribers? Once in a while, even the best senders can get a bad customer of theirs that obtained email addresses by a violation of their terms and conditions. Just block that sender with a local "blacklist_from *@example.com" entry and report it to SpamCop. If the message headers have any abuse reporting information then send the headers there too. They should do their own internal investigation and shutdown that bad customer of theirs. That is still beside the point. There is simply no reason in the interest of SA as an antispam solution to publish all those rules. One or two rules would be more than enough. I know I can block this and that in SA, and tweak rules all the time - but I am concerned when the default settings in SA effectively facilitate marketing companies to stuff my Inbox full of junk. In that case you would achieve better results not using SA at all. As to reporting bad senders and "internal investigation" - my experience shows that doesn't get very far with any providers. Look at the IADB rules at http://ruleqa.spamassassin.org. They are very indicative of ham, so much so that I bump the scores up on them and shortcircuit a few of them as ham. If you want to score all of them at zero in your local.cf, go ahead. That's your choice. Just because you get unwanted email in your inbox doesn't make it spam. If it has a legit unsubscribe link then simply unsubscribe from it. If you want to help the community, then report it to Spamcop. -- David Jones
Re: Spammers, IPv6 addresses, and dnsbls
2018-03-02 10:08 GMT-03:00 Matus UHLAR - fantomas: > On 02.03.18 09:58, Leandro wrote: > >> Hi Danilele! Our DNSBL works with individual /128 IPv6 addresses: >> >> http://spfbl.net/en/dnsbl/ >> >> Even if the provider is offering less then /64 to customers, our DNSBL can >> list IPv6 of each one. >> > > how/who do you list when spammer starts rotating IPs in assigned /64 > range? > If the spammer uses the same domain at rDNS, when rotating IPs, our system will list each new IP at first DNSBL query. > But do not use our DNSBL to reject messages. Use only for SA punctuation, >> higher points to 127.0.0.2. >> > >
Re: Spammers, IPv6 addresses, and dnsbls
On 02.03.18 09:58, Leandro wrote: Hi Danilele! Our DNSBL works with individual /128 IPv6 addresses: http://spfbl.net/en/dnsbl/ Even if the provider is offering less then /64 to customers, our DNSBL can list IPv6 of each one. how/who do you list when spammer starts rotating IPs in assigned /64 range? But do not use our DNSBL to reject messages. Use only for SA punctuation, higher points to 127.0.0.2. 2018-03-02 8:54 GMT-03:00 Daniele Duca: apologies if this is not directly SA related. "Lately" I've started to notice that some (not saying names) VPS providers, when offering v6 connectivity, sometimes tends to not follow the best practice of giving a /64 to their customer, routing to them much smaller v6 subnets, while still giving to them the usual /30 or /29 v4 subnets. What It's happening is that whenever a spammer buys a VPS with those providers and get blacklisted, most of the time the dnsbls list the whole v6 /64, while still listing only the single ipv4 address. This makes some senses, as it would be enormously resource intensive to track each of the 18,446,744,073,709,551,616 addresses in the /64, but unfortunately not respecting basic v6 subnetting rules causes reputation problems also for the other customers that have the bad luck of living in the same /64 and are using their VPS as an outgoing mail server. While I'm not judging the reasons why VPS providers are doing this type of useless v6 subnetting (micronetting?), I've started to deploy some countermeasures to avoid FPs. Specifically I wrote a rule that identifies if the last untrusted relay is a v6 address, and then is subsequently used in other meta rules that subtract some points in dnsbl tests that check the -lastexternal ip address on v6-aware lists. I know that probably is not the best solution, but I've started to see real FPs that worried me. I've even pondered if it could have sense to go back to v4 only connectivity for my inbound mtas. If you are in a similar situation I would like very much to discuss what would be the best approach to balance spam detection while avoiding fps -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I drive way too fast to worry about cholesterol.
Re: Spammers, IPv6 addresses, and dnsbls
Hi Danilele! Our DNSBL works with individual /128 IPv6 addresses: http://spfbl.net/en/dnsbl/ Even if the provider is offering less then /64 to customers, our DNSBL can list IPv6 of each one. But do not use our DNSBL to reject messages. Use only for SA punctuation, higher points to 127.0.0.2. Regards, Leandro SPFBL.net 2018-03-02 8:54 GMT-03:00 Daniele Duca: > Hello list, > > apologies if this is not directly SA related. "Lately" I've started to > notice that some (not saying names) VPS providers, when offering v6 > connectivity, sometimes tends to not follow the best practice of giving a > /64 to their customer, routing to them much smaller v6 subnets, while still > giving to them the usual /30 or /29 v4 subnets. > > What It's happening is that whenever a spammer buys a VPS with those > providers and get blacklisted, most of the time the dnsbls list the whole > v6 /64, while still listing only the single ipv4 address. This makes some > senses, as it would be enormously resource intensive to track each of the > 18,446,744,073,709,551,616 addresses in the /64, but unfortunately not > respecting basic v6 subnetting rules causes reputation problems also for > the other customers that have the bad luck of living in the same /64 and > are using their VPS as an outgoing mail server. > > While I'm not judging the reasons why VPS providers are doing this type of > useless v6 subnetting (micronetting?), I've started to deploy some > countermeasures to avoid FPs. Specifically I wrote a rule that identifies > if the last untrusted relay is a v6 address, and then is subsequently used > in other meta rules that subtract some points in dnsbl tests that check the > -lastexternal ip address on v6-aware lists. > > I know that probably is not the best solution, but I've started to see > real FPs that worried me. I've even pondered if it could have sense to go > back to v4 only connectivity for my inbound mtas. > > If you are in a similar situation I would like very much to discuss what > would be the best approach to balance spam detection while avoiding fps > > Regards > > Daniele Duca > >
Spammers, IPv6 addresses, and dnsbls
Hello list, apologies if this is not directly SA related. "Lately" I've started to notice that some (not saying names) VPS providers, when offering v6 connectivity, sometimes tends to not follow the best practice of giving a /64 to their customer, routing to them much smaller v6 subnets, while still giving to them the usual /30 or /29 v4 subnets. What It's happening is that whenever a spammer buys a VPS with those providers and get blacklisted, most of the time the dnsbls list the whole v6 /64, while still listing only the single ipv4 address. This makes some senses, as it would be enormously resource intensive to track each of the 18,446,744,073,709,551,616 addresses in the /64, but unfortunately not respecting basic v6 subnetting rules causes reputation problems also for the other customers that have the bad luck of living in the same /64 and are using their VPS as an outgoing mail server. While I'm not judging the reasons why VPS providers are doing this type of useless v6 subnetting (micronetting?), I've started to deploy some countermeasures to avoid FPs. Specifically I wrote a rule that identifies if the last untrusted relay is a v6 address, and then is subsequently used in other meta rules that subtract some points in dnsbl tests that check the -lastexternal ip address on v6-aware lists. I know that probably is not the best solution, but I've started to see real FPs that worried me. I've even pondered if it could have sense to go back to v4 only connectivity for my inbound mtas. If you are in a similar situation I would like very much to discuss what would be the best approach to balance spam detection while avoiding fps Regards Daniele Duca
Re: IADB whitelist - again
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
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