Musings from a small IPP

I’ve just had an e-mail arrive in my SPAM folder that looks extremely dangerous.

It purports to be from the British Red Cross appealing for Japan, but

• The Red Cross were on the radio yesterday explaining that their priority is currently the Libyan refugee crisis.
• The email originated in China.
• The payment method was Moneybookers (an alarm bell all by itself)
• The payee was a personal account
• The Payee should have been the Red Cross
• No off-line donation methods listed, such as bank transfers, telephone with credit card, or local collections.

We are tagging these as SPAM, but do watch out

As one might imagine, we are long-term exponents of open-source.  We don’t use Microsoft product, so it’s quite amusing to be Phoned up out of the blue to be told we have a windows virus.   Really rather difficult on UNIX systems 😀

To be fair to the gentleman introducing himself as Michael Narona he did call my private line, and thought he was talking to a domestic consumer, but he did have my name which is annoying.  As it was immediately clear to me this was a scam I decided to see what information I might get to pass on to the police.   Enjoy the audio recording

You’ll notice he introduces himself as being from

“The online technical support department of your computer”

and absolutely will not give me a company name, and is extremely reluctant to give me a number on which he can be called back.  The incoming call had CLI suppressed.

If nothing else I kept him from scamming others for 6 minutes.

The base standard for email RFC822 is close to 30 years old.  You’ld think by now that people would be capable of adhering to it, and that deviations would be jumped on by every anti-spam tool in existence.

Take for instance the requirement to have a message-Id.  A Message-Id has a very specific format: it starts with a ‘<‘ character, then a unique string often based on the date, time and how many messages the system has processed today, then ‘@’, then the fully qualified domain name (FQDN) of the originating system, and finally the closing ‘>’ character.

The message-Id is designed to trace a message through the e-mail infrastructure.  It should only be added by the starting MTA, and subsequent systems, in these SPAM aware times, should refuse to handle messages without a valid one, rather than adding one as they did in the past.

The Message-Id is intended for computer use, not human interpretation, so the FQDN should be that — a domain name that can be checked in the DNS, not europe3.mybigcompany, nor missing entirely.

This is even worse when the company in question sells SPAM and Virus detection software, or reliable communications.  Congratulations NORTON – Symantec, congratulations Blackberry, come up and take a bow.

Dear Blackberry/ Research in Motion,

I am not prepared to pay you to tell you your systems are misconfigured.  When I send you a note to let you know that you are generating message-ids that are not standards compliant for your customer’s outbound mails, and that you might like to look into it, I expect a polite “Thank you’ not: an invitation to buy a support ticket before you will open my email.

Your reply:

Thank you for contacting BlackBerry Technical Support. The email you submitted has not been delivered. Please find many alternative support options below.

is just rude, and worse I suspect it was generated by the group that handle your consumer devices who wouldn’t comprehend what I was writing about, rather than the infrastructure group that need the information.

Since forever the conventional way of dealing with ever growing log files has been to move the old file aside into an ‘n’ deep push-down stack, so that for logfile ‘log’ the most recent backup will be ‘log.1,’ the next older ‘log.2′ and so on.   It’s a simple scheme and makes it easy to identify the more recent files.

The disadvantage is that every time the logfiles rotate all the files in that stack change, and need to be backed up.

It’s possible to massively reduce this storage churn by arranging to not use the numeric sequence, but rather datestamp the archive files.  The standard  utility used for this logrotate has the facility built in.  just add 2 lines to your global configuration file:

• ‘dateext’
• ‘notifempty’

Now why is that not the default?

Being on the internet is risky.  It used to be that a new PC connected to the net would be taken over in under 20 minutes unless protective measures were taken.  Fortunately this is no longer the case, but it does not stop the attempts.  When one is running servers there is little option of switching off services.

In particular one needs remote access programs such as ssh, and one’s customers need ftp to manage their websites.  There are however patterns which lead one to realise when an attempt is being made to obtain illegal access.

It’s particularly annoying when you have someone trying to steal telephone service by logging their IP phone onto your Asterisk PBX, as they are trying passwords at around 40-50 per second, and chewing your bandwidth fairly well.  And of course if they succeed you’re up for a lot of telephony cost. (The rest of this article is for unix system admins) (continue reading…)

I’ld like to send some feedback to Daniel Olfelt author of the ics calendar plugin for WordPress.  Kudos to him!

Trouble is his website contact form has a captcha plug in  which is not generating an image, so I can’t offer him the code to work round a bug in the Mac iCal generated ics files which creates notionally invisible TRNS:TRANSPARENT false events, but which his code displays, or for adding %url% to the elements that get generated in custom expansions.

All very simple stuff, but I hate fixing things and not being able to feed back changes, so that no-one else needs to fix it.

It’s a very sad milestone.  As of this week we mark over 98% of the messages we are offered as SPAM.  The press has some catching up to do — they report 92% — a figure we were at back in February.

This does include a very small percentage of messages which we later re-classify as ‘ham,’ and the slightly larger set that we have mistakenly believed to be legitimate, but the percentage is scary.  Handling it would require 1 processor per 750 mailboxes running flat out (on average — the peaks and troughs are of course rather fractal), meaning that a large multi-processor system is required in practice.

So less than 1 message in 50 is legitimate.

When I look at this figure, I realise we do something really worthwhile for our customers.

Sometimes you have to give up, and take the hit of extra SPAM.  For me personally, one of the more valuable features of ASSP’s SPF checks was to apply the check to incoming addresses that are otherwise whitelisted, so that no-one can hijack a genuine contact’s email address to send one spam.

But there is always the wilfully ignorant customer of one’s customers who refuses to believe that their IT provider has not authorised the way they are sending mail.  “Lots of other places receive my mail”  — well yes but they’re not checking, “Well it must be your fault, and no I can’t talk to my IT department, you fix it” — phone slams down.

When the person who will not listen is controlling a significant spend some form of smiling compliance is forced.

We still have a list of domains where we force SPF checks, and let’s say a big “THANK YOU’ to HSBC, PayPal and RBS who actually care enough for their customers to protect them from phishing with SPF.

In contrast one ought to hold up to ridicule Barclays, NatWest, Santander, Bank of Scotland, Lloyds, Halifax etc who (as of today) still leave their customers open to attack.