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

A Strange Passion for Security

I'm not a computer security expert, but it's been part of my work for many years, in different forms.  A very long time ago, a friend hired me to write up a primer for internet security, and ever since then it's been a theme that's sat in the background and pops up every now and then . But lately, it's started to feel like more than a theme, and but indeed a passion. You may consider computer and internet security to be a dry subject, or maybe you imagine feelings of smugness or righteousness, but "passion" is the right word for what I'm feeling. Here's google's definition: Passion: 1. a strong and barely controllable emotion. 2. the suffering and death of Jesus. Okay, let's just go with number 1. for now. If you followed my link above to other posts about security, you'll notice one from eight years ago where I mused on the possibility of the discovery of a flaw in how https works. Weirdly enough, a flaw in https was discovered shortly...

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