|Posted by Usuário:Nad on 16 abril 2018 at 17:49|
|Codero in the US to the Dutch hosting company Abelohost. Apart from a few small email glitches, the move went very smoothly. The US has been stamping out liberties like there's no tomorrow, and Internet privacy is one of the worst hit areas with abominations like the CLOUD act being signed in. This along with the fact that Codero have never responded to requests I've been making to them for over three years to accept crypto-currencies as a payment option has finally prompted OD to leave and head for greener pastures. We chose the Netherlands as our new digital home because Dutch law takes privacy much more seriously than most other countries in the world, especially the US where the very concept of privacy has been rendered virtually non-existent now. Abelohost use the 100% Dutch Serverius data-center and they accept over fifty different Crypto currenies for payment :-)|
|Posted by Usuário:Nad on 17 novembro 2016 at 09:51|
|Nosso nome de domínio "organicdesign" é muito difícil para os Brasileiros, e também muito difícil para explicarmos esse endereço para outras pessoas. Por isso, eu comprei um novo domínio - agora o endereço do nosso blog é muito simples: od.blog.br. Oba!
Obs: Os outros domínios ainda funcionam, esse novo endereço é só para explicar para outras pessoas mais fácil.
|Posted by Usuário:Nad on 03 dezembro 2015 at 19:53|
|LetsEncrypt is a new Certificate Authority, it’s free, automated, and open! It went public at 18:00 UTC today, and we had our first certificate made within the hour, and documented the procedure here.
The procedure is far simpler than all the back-and-forth of signing and requests that is required with the "legacy" corporate method, you simply install the LetsEncrypt utility on your server and tell it to make all your sites secure! Simple as that! Although we do have a very complicated configuration so I decided to have it just make the certificates and let me adjust the configuration manually - but even that process was eazy peazy lemon squeezy :-)
Here's screenies of Chromium (right), Firefox and SSL labs responses to our fist test domain secured with a LetsEncrypt certificate.
|Posted by Usuário:Nad on 24 novembro 2015 at 15:37|
|A couple of years ago I configured the server to do the process of copying user's sent emails into the "Sent" mail folder on the server-side rather than the client having to do it since that effectively involves sending the whole message to the server twice. Not only does it have to be sent twice, but for some reason the Thunderbird email client tends to lock up during the copying to sent process for some reason. So I created this addition to our email configuration procedure which gets the server to do the job instead.
But there's one complication. The message that's copied doesn't have the Bcc header as it's been stripped by the time the message gets to the stage of being copied. It's very important that the messages in the "Sent" folder have their Bcc header because you want to know who the message was sent to, and you may also want to modify and re-send the message again.
So the Exim system-filter that copies the message also calls this copy-to-sent.pl Perl script which finds the message that was just copied to the "Sent" folder and then re-builds its Bcc header by getting all the recipients from the Exim $recipients variable and removing the ones found in the To or Cc headers of the message.
The only problem is that it hasn't worked properly ever since it was made two years ago! It's always added the Bcc header even if there wasn't one and put all the recipients in there including those from the To and Cc headers. I finally got around to adding detailed logging into the script so I could track down the problem - which turned out to be nothing more than a "+" symbol needing to be added into the regular expressions that extract the email addresses from the To and Cc headers.
|Posted by Usuário:Nad on 09 setembro 2015 at 18:02|
|Debian 8 has been the stable version since April, but I only just got round to upgrading the server today. Even then the main motivation was because of a sudden huge increase in spam which turned out to be due to two things. First we were being blocked from using the domain black-lists, and second because our version of Debian was using version 3.3.2 of [SpamAssassin], but it needs to use at least version 3.4 to make full use of the domain black-lists. Here's an example X-Spam email header showing that we're being blocked:
The first problem was happening because the black-list services run over DNS, but they will block requests from DNS servers that use their free services too much. We were using our server host's DNS servers which were being blocked because they relay requests to the black-lists from thousands of their clients, but they don't pay for the black-list services. This issue is easily fixed though, we simply needed to set up our own caching DNS server so that when SpamAssassin requests information form the black-lists they're going through our own server that makes only a minimal amount of requests. See Configure mail server for more details.
The best way to fix the second problem was to upgrade the OS because Debian 8 uses SpamAssassin version 3.4.0 which is modern enough to properly support the black lists. Here's an example of what the X-Spam headers are looking like now :-)
Another thing that's much more up to date in the new Debian version is our web-server, Nginx. This was only on version 1.2 before but now has gone all the way up to 1.6! This is good news because versions prior to 1.3 had no support for WebSockets, so now our page comments no longer need to use Ajax-polling which is very unresponsive and wasteful.