Skip to main content

What not to do about spam

Another example of how not to run a business.

My hosting provider has a problem. They've automated their systems to the point where bad actors are using them to do bad things, there's not enough human interaction to spot the bad actors.

This part isn't a surprise, it's a universal problem of technology and the demands of making money in scale.

My provider has chosen to try to mitigate this problem with more automated systems, and chose an 'anti-spam' system called Vade to monitor traffic over their network and shut down ports that are identified as sources of spam.

Pretty clever sounding, and maybe it works for corporations, but it's failing in my experience of being a hosting client.

Specifically, my servers keep getting blocked, all false positives, and the only recourse is an onerous process for me to "prove" each time that I'm not sending spam.

Now, I get that systems can have errors, and I did my best to work with my provider to help them overcome the limitations of their automation, but:

1. The support staff can only seem to follow the instructions of the anti-spam provider, which asks for an example .eml file from a list of message id's that it spits out in order to undo the block.

2. My emails are being generated as mass mails, so I'm (sensibly) not keeping copies of all outgoing mails (most of which are multiply-duplicated anyway).

3. The staff can't accept a copy of what went out, then insist that they need the eml file of a specific example.

4. So now I need to go into my blocked queue, find one of the examples, convert it into the eml format they are asking for, and post it to a ticket system. 

And then wait.

Note that this happens on Friday afternoons and typically the whole process takes about two hours (but only now that I've figured out a sensible way to extract an example, after many hours of failed attempts, and of trying to convince them that there must be better ways to fix their system).

Some ways that I tried to convince them that I wasn't sending out spam, which they apparently had no way of processing are:

1. My use of a responsible mass mailer.

2. An ip reputation of 98.

3. Not being listed on any spam blocking mechanisms.

4. A history of them blocking my ip due to false positives.

So here I am, every couple of weeks, getting my clients' mail blocked due to false-positives and having to scramble around on their ticketing system and my server and some custom scripts to extract what they say they need in order to unblock the server port.

I haven't mentioned how much time I've wasted trying to communicate with them to explain why their system is not acceptable and that I'd be happy to talk with someone about a better way of fixing their issue.

To really add insult to injury, the support staff insist on following their protocol of advising me how to avoid being labelled as spam (hint: I'm already following all the advice, this is not my time at the rodeo). The first time was irritating, but now it's just galling.

The only answer I get back from them about the bigger issue is "there's nothing we can do".

Which of course, is why we should be afraid of AI and big tech, because it's turning us into compliant tools of those that control the levers, and the gap between those that are controlling the levers, and those who experience the outcomes, keeps growing.

OVH: please help your support staff understand problems before being asked to follow instructions that have no relationship to the problem. I am happy to help you understand why your system is broken in my particular case and make it better. I'm really tired of wasting all our time going around in circles following pointless protocol.

 

 

 

Popular posts from this blog

The Tyee: Bricolage and Drupal Integration

The Tyee is a site I've been involved with since 2006 when I wrote the first, 4.7 version of a Drupal module to integrate Drupal content into a static site that was being generated from bricolage. About a year ago, I met with Dawn Buie and Phillip Smith and we mapped out a number of ways to improve the Drupal integration on the site, including upgrading the Drupal to version 5 from 4.7. Various parts of that grand plan have been slowly incorporated into the site, but as of next week, there'll be a big leap forward that coincides with a new design [implemented in Bricolage by David Wheeler who wrote and maintains Bricolage] as well as a new Drupal release of the Bricolage integration module . Plans Application integration is tricky, and my first time round had quite a few issues. Here's a list of the improvements in the latest version: File space separation. Before, Drupal was installed in the apache document root, which is where bricolage was publishing it's co...

IATS and CiviCRM

Update, Nov 2009: I've just discovered and fixed a bug I introduced in the 2.2 branch for the IATS plugin. The bug was introduced when i updated the API files from IATS and failed to notice that the legacy method for C$ one-time donations was no longer supported. If you're using a version greater than or equal to 2.2.7, and are using IATS for C$, non-recurring donations, then you're affected . To fix it edit the file : CRM/Core/Payment/IATS.php, and remove the line that looks like this: $canDollar = ($params['currencyID'] == 'CAD'); //define currency type The full fix removes a conditional branch based on that value a little further on, but by removing this line, it'll never actually use that branch. Drop me a line if you have any questions. Update, May 2009: This post is still getting quite a bit of traffic, which is great. Here are a few important things to note: The IATS plugin code is in CiviCRM, you don't need to add any code. Y...

Orchestrating Drupal + CiviCRM containers into a working site: describing the challenge

In my previous posts, I've provided my rationale for making use of Docker and the microservices model for a boutique-sized Drupal + CiviCRM hosting service. I've also described how to build and maintain images that could be used for the web server (micro) service part of such a service. The other essential microservice for a Drupal + CiviCRM website is a database, and fortunately, that's reasonably standard. Here's a project that minimally tweaks the canonical Mariadb container by adding some small configuration bits:  https://github.com/BlackflySolutions/mariadb That leaves us now with the problem of "orchestration", i.e. how would you launch a collection of such containers that would serve a bunch of Drupal + CiviCRM sites. More interestingly, can we serve them in the real world, over time, in a way that is sustainable? i.e. handle code updates, OS updates, backups, monitoring, etc? Not to mention the various crons that need to run, and how about things ...