On Fri, Jun 28, 2024 at 9:24 AM James Hoddinott via mailop < mailop@mailop.org> wrote:
> Your main issue is that Transip sure do like to let spammers make use of > many IPs within the /24 that you're in, we'll just need to flag yours as > separate to prevent this from reoccurring. > > Wouldn't you expect to see 37.97.176.137 listed in several public RBLs and have a low sender score if this were the case? If Cloudmark (or any other anti-spam system) is just blocking the whole /17 or ASN - wouldn't it be just a simple fix to look specifically for 37.97.176.137 and see how much spam 37.97.176.137 has sent? Or when the last time 37.97.176.137 sent spam or attempted to send out any mail? And exclude 37.97.176.137 from this block (I don't like the term whitelist here, but if you want to use whitelist you can use it here) so that mail from 37.97.176.137 can go through when this specific issue is raised? This is what kind of creates mistrust with all of these too-big-to-fail email and anti-spam providers. They block an IP but don't provide any information for remediation and take days or weeks to get an issue cleared up. There's seemingly little evidence to show that blocking the IP is validated. Where would one go to learn of this situation prior to sending an email to a random email service provider that utilizes Cloudmark (or insert whatever anti-spam system) so that the situation could be handled proactively and timely? There needs to be something publicly available that would point to IP addresses - such as 37.97.176.137 - being red flagged or to suggest that there may be issues sending from these IPs. But instead the system teeters on providers being able to block IPs simply because they can.
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
