Having finished the work to migrate the UKFSN email service to a new server and re-implement the email filtering service I have just finished setting up the webmail service so customers can gain secure access to email from anywhere via https://mail.ukfsn.org/
There is still some work to do before I’ll be completely happy with the service but all the core capabilities are in place and everything else is a “nice to have” so I’m happy enough for now.
Some time ago the email filtering service at UKFSN ran into serious problems and I had no choice but to disable it until I could completely rebuild the filtering platform. This resulted in all UKFSN email customers – and me! – getting to see what unfiltered email is like these days. Not a good thing.
Today I have completed the work to build and integrate a new email filtering service for UKFSN. The first stage of deployment is to have a standard set of filtering rules apply to all accounts. These rules will result in spam emails being marked but still delivered (any email containing a virus will be deleted and never delivered).
Later I will extend the service to enable customers to reconfigure the filtering options so that spam can be automatically deleted and the trigger levels can be customised by each customer.
For now I hope the work I’ve done makes it easier to use your UKFSN email.
A problem developed on the email server today that caused it to bounce some email.
The problem was that the internal email delivery agent for email destined to our server stopped doing DNS lookups properly and so could not resolve destination domains. I’m not sure exactly what caused this to happen however I have found the necessary configuration options for postfix to force the name resolution to do what it needs to and things are now fixed.
The fix for this is to set:
smtp_host_lookup = dns, native
lmtp_host_lookup = dns, native
Unfortunately the email that was bounced as a result of this will have been “returned to sender”.
There was a brief outage on the mail server this morning caused by a software upgrade that went slightly wrong. The issue was corrected within a couple of minutes and service restored. No email was lost.
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.
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.
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”.