554 Message not allowed – Headers are not RFC compliant[291]

If you get this message when sending emails to Yahoo addresses from PHP, it’s quite possible the subject line is being duplicated and this is causing your email to be rejected.

PHP’s mail() function takes a Subject as a parameter. It also accepts a custom list of headers. The mail() function seems to always append a subject header irrespective of the contents of the custom list.

So, if you have the Subject already defined in your custom headers, PHP will add another. This is not RFC compliant, and Yahoo has a particularly strict checker for incoming emails (most other mail servers seem to ignore this, as far as I can see).

Take the Subject line out of your custom headers, make sure it’s in the mail() call itself, and the mail should send (assuming no other issues….)


A vulnerability has been found in the encryption library OpenSSL, used by a huge proportion of web and Internet services. This bug allows malicious users to access bits of memory on the server and potentially read enough information to render the encryption useless.

Worse, having obtained the right data, they could compromise the security of past and future communications allowing eavesdropping, impersonation and stealing of data.

The vulnerability, known as Heartbleed, was found by researchers at Google and Codenomicon. While publicly announced only yesterday (7 Apr), it seems the bug has been present since December 2011, and was part of a release in March 2012.

The various affected Linux distributions have been speedily updated and I updated our servers this morning. We must now wait and see how quickly the fixes will be applied to other servers and systems.

The effect of this bug is serious: it undermines the security protocols used throughout the Internet, and an attack is apparently undetectable in ordinary logs. This means that high-profile websites might be well-advised to renew their security certificates, so that any ‘exposed’ details cannot be used in a future attack.

Tracking Devices via Raspberry Pi (Part Two)

In the last post I described how it could be possible to build a simple tracking device using a Raspberry Pi acting as a wireless network access point. In this post, I try it out for real. This isn’t a detailed technical run-down, just the basics.


It seems to get this working you’ll need just a Raspberry Pi (Model B has extra USB + LAN so is easier to configure) and a USB Wireless dongle. I started off with the Nano-USB TP-Link WN725N but this isn’t supported by the default drivers. I managed to get it working thanks to this thread on the Pi forums, which describes recompiling direct from Realtek’s website.

However, it seems that the Realtek drivers don’t have the necessary hooks for responding to probe requests. My guess is this is usually handled at a lower level and hostapd merely makes use of callbacks to customise the handling of these requests. I didn’t really fancy rewriting large chunks of code to support it, so I opted for Plan B, which is an Edimax 7711USn (the big white thing in the picture).

The Edimax does seem to work with the default nl80211 drivers and sure enough, when I fired up debug mode, the probe requests came through.

By default, the probe requests only appear with some really high debug level (makes sense – they’re usually not that useful) and running in this mode would surely generate a whole load of debug messages I wouldn’t need. The second snag is that there is no timestamp with these messages.

So, next step was to recompile hostapd with some customisations. At this stage, I merely wanted proof-of-concept so I moved the probe request notifications up to INFO level and added a timestamp using some existing functions. I then ran the program for a little while et voila, the requests started coming in. The screenshot below shows the requests being made (MAC address partially obscured) and the timestamp (a second counter).


These requests will be coming from all sorts of wifi-enabled devices: my phone, my laptop, phones of passers-by. The key thing is that I did nothing to these devices to enable this – they automatically scan for wifi networks and this device is merely visualising it.

In little under forty minutes there were 1720 probe requests from sixteen separate devices. I’d call that a proven concept.

All in, the Raspberry Pi setup cost around thirty pounds. This is for a single device. My original plan was to see how this could be used for tracing paths through a space, such as a city or stadium. For this to work, one would need many more devices, both to triangulate the devices and to provide blanket wifi coverage.

The theory is: with enough of these devices in the right place it should be possible with reasonable accuracy to work out where people are, and where they go. At thirty quid* a pop, this needn’t be a hugely expensive task.

As it turns out, this is precisely the sort of work going on both in the commercial and development world:

CreepyDOL is a networked tracking tool – sniffs network traffic and tracks users. As the name suggests, the powers ‘in the wrong hands’ are creepy indeed.

Wifi tracking of the kind I describe has been in use for a couple of years now, and it’s already used to track customers in supermarkets.

Sure enough, just as I was working on my project, The Register published an article about how Asda and EE in the UK are using wifi to achieve precisely this.


There are quite obvious privacy implications to all of this. MAC addresses are unique and, even if we can’t directly identify someone from them, it may be possible to get their identity from all the clues available (such as where they shop, where they dwell, and by sniffing wifi traffic). Privacy is a huge concern and any technique such as this – even if used with the best intentions and no direct logging – must still be dealt with with care. Last year, it was widely reported that wifi trackers were embedded in some of London’s bins. Officials ordered the company to stop amid privacy concerns, and – despite the company’s protestations that all is anonymous – it has clearly hit a nerve with privacy advocates. There may well be no attempt whatsoever to track individuals, but a poorly executed plan will be met with harsh criticism irrespective of the actual risks.

I have a couple more articles planned to follow up these points – any comments are most welcome.

* There are, of course, all kinds of additional costs: You probably want a case, decent power, and public liability insurance. The Raspberry Pi is also not likely to be a great choice in the long run, for reasons which I hope to pick up later.

Using Raspberry Pi Access Point to Track Devices

I’ve been looking recently at ways to measure population movements across a large outdoor area. There are various ways of doing this: we watch them, we ask them, or we infer. Watching is a popular option at stadia, city centres and large events. Automated footfall cameras can track movements and figure out how many people walk past a certain point in any period. Put enough cameras up and you can get a pretty good plan.

However, this merely measures numbers of people. There is no connectivity. 200 people walk past point A, 400 past point B. Does that mean 600 in total at two locations, or did some of those in point A also walk past point B?

This got me thinking about technical solutions (of course) and fairly quickly I got to wireless networks. Back in 2008, I wrote about a scheme in Portsmouth’s Gunwharf Quays to track mobile devices. At the time I think the company was using bluetooth but since then we’ve had an astounding growth in smartphone usage. Wifi is pretty much standard and – I would perhaps wager – more likely to be turned on.

Keen to see how this might be implemented, I did some research into how mobile phones discover wifi networks and found an interesting behaviour. Every few seconds or minutes, your phone will send out a signal “who’s there” to probe local wifi networks. Any active access points will respond accordingly with their network name “Hi I’m BtHub_12345”. This surprised me a little, as the device itself has to ask for wifi – I was expecting the access points to broadcast themselves and send out signals every few seconds. It seems this is to conserve battery.

Anyway, having established this, it seemed likely the device would be giving its MAC address away. To clarify, the MAC address is the hardware-level identifier for network devices. It’s a bit like a serial number, so when two devices talk to each other they address each other by their MAC address so they know who’s who. MAC addresses are supposed to be unique, so no two devices should ever have the same address.

Curious to see how easy this would be, I have started to build a Raspberry Pi device that is capable of this. It seems possible – hostapd allows the Pi to act as a wifi network access point. This forms the basis for tools such as Karma (which achieves a lot more than I need) and clearly has the capability to show probe requests

There are also some privacy issues that need to be tackled. What are the legal aspects of tracking MAC addresses? It seems that, provided the addresses are not tied to individuals, we do not need disclosure. Indeed, my aim is to aggregate data from the start. Once a path has been created, any trackable information should likely be discarded. I’ll touch on these too.

More updates to come…


Resize partition to fit SD card [Raspberry Pi]

I often need this… originally from tomahhunt on the Arch Linux forums

The following commands resize the main partition of a new Arch Linux installation on a Raspberry Pi to fit the full disk.

Switch to root (sudo or su)
fdisk /dev/mmcblk0

Delete the second partition /dev/mmcblk0p2:
d > 2

Create a new primary partition and use default sizes prompted. This will then create a partition that fills the disk:
n > p > 2 > enter >enter

Save and exit fdisk:

Now reboot. Once rebooted:
resize2fs /dev/mmcblk0p2