Web Server Woes

The UKFSN customer web server is currently down. I am working on fixing it and so wont be answering customer emails until I have done so.

Posted in Uncategorized

Reviewing SMTP authentication

Following my last post about having to cancel a small number of customer accounts due to spam being sent via our email service using those accounts I have been reviewing the approach UKFSN takes to providing an outbound email service and I am considering some changes.

There are a number of options I am evaluating, some of which are briefly detailed below

1. Keep the existing service as it is with customers able to send email via our servers if they are on a UKFSN broadband connection or if they authenticate the SMTP session with their account username and password. While this would have the benefit of not breaking anything for customers it would do nothing to address the problem of keeping the UKFSN email service secure when some customers fail to keep their account credentials secure.

2. Stop providing an outbound email service via SMTP for those who are not on a UKFSN broadband connection. If UKFSN no longer supports authenticated SMTP it cannot be abused. This approach would simplify my life significantly and would not impact those who use the UKFSN webmail service or send email from their broadband connection however it would remove a service that some customers rely upon. While I am loath to withdraw a service customers are using I am not willing to have the UKFSN email service abused to send spam or to continue paying the increasing cost of dealing with the fallout when a customer account is used to send it.

3. Continue to provide an outbound authenticated SMTP service but change the authentication mechanism to something other than account credentials so that those account credentials cannot be abused if a customer gets a virus or trojan on their PC. This would be disruptive to customers and might well require more technical ability that many customers have to use thus creating more demand for support in an area I am not happy to provide that support – there are too many different email clients for me to spend my time trying to learn how to configure them all.

I’m not sure which approach is best. Given that this service currently costs more to run than it generates in income I am not willing to spend too much effort or money on it.

Posted in Uncategorized | Tagged ,

You are a spammer and you don’t even know it!

Over the past several months I have been seeing an increase in the number of customer accounts being abused to relay spam via our server. In each case the customer account credentials have been used to authenticate to our SMTP service and spam.

Do I think these customers have decided to get into the “business” of sending spam? No.

I do, however, have to behave in pretty much the same way as if I did which means in each case the customer account is immediately terminated.

Previously I have tried other approaches. I have changes the password on the account (and on all associated accounts and email only accounts, etc) and contacted the customer to let them know and ask them to fix their security. The problem with this is that in almost all cases the customer denies that they are at fault or is incapable of fixing their security properly so the problem happens again fairly quickly with the same account.

It may seem that terminating the customer account is too harsh but reality is that when a customer account is abused in this way it damages the whole service. Other email servers refuse to accept any email from our server and that harms all customers. In order to remedy this I have to spend significant amounts of time cleaning up our email queues and working with other ISPs and blocklist operators to get the UKFSN outbound email service working again.

This weekend I had to terminate two customer accounts because of this. One begins “dab” and the other “chr”.

Posted in Email, SPAM

Outage Yesterday

Yesterday afternoon UKFSN suffered a serious outage our main servers. This knocked out all web servers, the main email servers and the RADIUS authentication service.

Broadband, Backup MX service and DNS services were not affected.

The loss of service started at approximated 4pm. Unfortunately I was offline at the time and did not discover the problem until nearly 7pm. Attempts to restore service remotely were not successful and ultimately it was necessary for an engineer at the Hetzner DC to physically power cycle equipment to get the servers back online which was done by about 9pm.

This brought the servers back online however it was still necessary to repair filesystems before services could be fully restored. Between 10:30pm and 11:30pm all services were brought back online.

Please accept my apology for any inconvenience this loss of service may have caused you.

Posted in Uncategorized

Filtered Internet Access

You may have seen an announcement today by David Cameron, the British Prime Minister, in which he states that all ISPs in the UK have agreed to block pornography (and other materials) by default with customers being required to deliberately state that they wish to access such materials in order to get them.

The announcement is essentially an enormous lie. Some ISPs may have agreed to do this but by no means all and moreover what the announcement claims will happen is simply not possible.

Certainly some of these materials can be blocked but the unfortunate truth is that no systems can block all of them and that any system that is successful to any significant degree in getting near to doing so will also end up blocking perfectly innocent sites.

UKFSN has no agreed to implement any such block. Unless it is absolutely required by specific legislation UKFSN will not implement any such block.

Posted in Uncategorized

Problems with AWBS on Debian Stable

Recently I moved the UKFSN services to a new platform which involved migrating everything to new servers. UKFSN runs on Debian Linux and had been running on an older version of the Debian stable distribution. The new servers are all running the latest version of Debian stable.

A significant consequence of this upgrade is that the version of PHP on our servers went up to 5.4 and that caused many problems. A particular problem arose with the software we use to give customers direct control of domain name registration and management which is called AWBS. This software package is written in PHP and it simply does not work with version 5.4 of PHP.

Version 5.4 of PHP was released on 1st March 2012. This release contained many changes but the really important ones were the removed of deprecated features. That means features the authors of PHP had stated a long time ago would be removed and should not be used. AWBS was dependant on one of those features to the extent that important bits of it simply stopped working.

After investigation I was able to identify the source of the problem and ascertain that it is not possible to fix it – I really should not be using software for UKFSN that is not released under a free software / open source license but there isn’t anything readily available under such a license that does what I need for UKFSN. In the short term the solution has been to downgrade the version of PHP to 5.3.

Long term the solution is to finish the work started some time ago to write a completely new ISP management for UKFSN and just get rid of AWBS.

Posted in Uncategorized

How to test sending email using MIME::Lite

Earlier this week I had to update a system that uses the MIME::Lite module to send email so that the emails it sends are properly UTF-8 encoded. The change to the code was very simple.

What was a little less simple was writing a test to verify that email is properly encoded. Note that I stated that I was writing a test. When developing software it is not enough to manually test that something does what is expected. We write tests so that we can repeatedly prove that our systems work as they are expected to and also so that we can identify if a later change breaks something.

Thankfully I was programming in Perl which means I had a flexible language to work with. The solution was to redefine MIME::Lite’s send method like so:

no warnings "redefine";
*MIME::Lite::send = *MIME::Lite::as_string;
use warnings "redefine";

What this does is firstly to turn off warnings for redefines. If you use warnings in your Perl programming you will get a runtime warning when you redefine a subroutine or method and we don’t want that warning as we fully intend to do this. Do note that the warnings on redefine are re-enabled immediately once we’re done though.

After we’ve ensured that Perl wont raise a warning we go ahead and redefine the send() method. In this case we redefine it to MIME::Lite’s own as_string method which simply returns the entire email, headers and body, as a single string. The code which calls send() captures the return value and sends it up the calling stack so we will get this back. Even though the code expects to be sending back true or false the fact that Perl doesn’t do strict variable typing means we can do this safely. You can redefine to anything. It’s fairly common to redefine to something as simple as sub { return $_[0] } but in this case MIME::Lite has as_string so we used that.

With this in place I was free to simply call higher level methods in the classes and objects which were in turn using MIME::Lite objects to send email and safely test the resulting emails.

Posted in Code, Email, Perl, Testing