gnarlymarley

You can also use a meta rule that combines other rules with "and" (&&), "or" (||), and "not" (!) tests. meta LOCAL_GMAIL2 LOCAL_GMAILAPI && LOCAL_GMAIL3 && ( __LOCAL_RULE6 || __LOCAL_RULE7 ) && ! __LOCAL_GOOD_RULE The double underscore allows you to make hidden rules that won't show up on the email, but can be used with meta groups. If you use this, you only need to add the score as in our example on the rule LOCAL_GMAIL2.

That is what I usually do too to fix it.

Probably try looking up the blocked IP as 1.2.3.4 as follows: nslookup -type=any 4.3.2.1.vote.drbl.gremlin.ru to see if it might offer other contact emails. Or you can try this and replace the vote.drbl with the list where your IP was found.

Keep in mind that spam usually will hit multiple rules and you wouldn't want to block non-spam email. I would probably put the following into spamassassin/local.cf: header LOCAL_SPAMMY_FROM_GMAIL From =~ /gmail.com/i describe LOCAL_SPAMMY_FROM_GMAIL spammy google domain tflags LOCAL_SPAMMY_FROM_GMAIL net reuse LOCAL_SPAMMY_FROM_GMAIL score LOCAL_SPAMMY_FROM_GMAIL 1.558 Now if you are feeling adventurous you may want to try something like a score of 6, but with multiple rules usually triggering you could also block legitimate email. header LOCAL_EMAIL_GMAIL Received =~ /google.com/i You can also use Received instead of From in your rule if you want to trigger on the Received headers. Keep in mind, that the default is anything above a 5 will temporary block. Anything above a 12 will permanently block.

I have found a few hacked cameras and routers. And sometimes the business doesn't believe the spam came from their camera. Once the find it and fix it, it is better for us all.

When I revisit your tracking original tracking URL, I still see the RFC6598 problem. Once the programmers can fix it, revisiting this URL should show properly. My guess is you happened to have hit a different internal address and it just worked. If you get an email with a RFC6598, you may still see the problem.

per the following, email deputies[at]admin.spamcop.net.

The problem with links in the body is that they can be added by a malicious spammer. The only item that you can trust as coming from the spammer is the IP address they used to contact your border email server. Everything else in the email could be intentionally added to damage a third party.

They may have acquired your special secret submit.xxxxxx@spam.spamcop.net address, which doesn't need a password. You may want to contact the deputies to and have them track where they came from.

My understanding is that RFC6598 addresses are supposed to be treated exactly like RFC1918 addresses. SpamCop probably needs to update their code. After reading your tracking URL, it seems that there may a disconnect between the two Received lines. I don't know how it gets from "p28-mailgateway-smtp-5c9bd88869-f6mrw" to "unknown". Received: from unknown (unknown [100.106.114.12]) by .... Received: from pv33p00im-smtpin013.me.com by p28-mailgateway-smtp-5c9bd88869-f6mrw (mailgateway 2209B259)

I have not seen any issues with reporting. Could be held mail in someone's queue.

I prefer to use the spamassassin defaults when ever possible because years ago, I had signed up for an online game emails and their server showed up on the SCBL. Some people report things through SpamCop that they forgot they signed up for. That said, it would be probably better to change the score of the SpamCop rule in spamassassin. score RCVD_IN_BL_SPAMCOP_NET 0 1.246 0 1.347 # n=0 n=2 The score temporarily rejects at 5.0. It permanently rejects at 12.0. The reason why spamcop is low around 1.246, is because it will add with other rules for a total count to trigger the rejects. I would suggest keeping this below 5 because you could have email you want be caught by this rule.

My third party box would disappear when I would run out of fuel. Adding more fuel would bring it back.

The score is smaller than the blocking and you usually have multiple items add up to the trigger point. You can adjust these scores in the spamassassin/local.cf file so upgrading doesn't lose your settings. I did find the following talking about the plugin too.

I remember something about it years ago when there was a place you could put your submit.xxxx@spam.spamcop.net address. Looks like they have a plugin for it: https://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Plugin_SpamCop.html

That address is coming from the whois at ripe. Because Europeans tend to do that lately, they tried to limit what can be seen by a query. I would prefer they use an abuse@ address too.

I made my own blacklist and use the DNS wildcard. such as *.c.b.a.dnsbl.example.com. I even did a few that go to the class B /16.

Might be good to get something that can parse the spam during the smtp connection such as spamassassin. Then you can have your mail server reject the email and you are not the one sending the bounce.

In the IPv4 world, the bottom, 0, should be the network address and the top, 255, is the broadcast address. It is using a devnull, but seems like it may be a trap.

I would get that if they report comes from my ISP that I have configured on mailhosts. They I would go to my ISP with the abuse and let them know they need to deal with a spammer. Now Mariano, if you pull up the tracking URL while being logged out, all the vital parts of the spam should be munged. No personal data should be visible. If you feel comfortable with how it munged, you can post the link here.

When they would do that to me I would report all 23. They soon realized the only way to stop the reports was to stop spamming me. At times I have temporarily abandoned some accounts, but I still have most of my accounts so I can report the one spam each account gets every week.

I wonder if this was a Brave search to URL redirect such as the "I feel lucky" button that google used to have. I tried five browsers with your link and all of them either couldn't the 。 as a valid part of the hostname or else they took me to their related search page thinking it was a search term. I suspect SpamCop is ignoring it because 。 is not a valid hostname as per the RFCs.

That is one of the reasons why I built and host my own blocklist and added some ISP's entire range. If they don't send me any valid email, then it might get blocked.

That is part of the reason I use a block list and a firewall. If their ISP doesn't want to play nice, then I sometimes block the whole range. (Of course, I try to figure out if there might be any legitimate email from those IPs before blocking.)

Maybe you can convince your hosting service to add some sort of filtering option. I have filtering turned on in my account and so far, I only get about one spam from serverion once every two months. Filtering such as SpamAssassin can work based on keywords in the body or headers, so even if they change IP address ranges, it can still be blocked. One thing I like about SpamAssassin is that if someone accidentally lists the wrong IP address on their block list, it could still make it through. Once SpamAssassin adds up multiple filters and gets to a limit, it will block it at the SMTP level (which means the server doesn't accept it and also doesn't sent a bounce later). Another filter option is similar to Yahoo or gmail's filter rules, which are based only on a keyword.