simply secure

A great new initiative has recently been launched, Simply Secure.

This site is trying to campaign to make security easier and more accessible to “common people”. As they call it “Usable secure technologies”.

Of course, the first thing I do is to check what newsletter system they use, and to no surprise, it is Mailchimp.

In the last few weeks phpList and team have been working hard to make sure that the site and clients are all protected with security. We’re very close to having it all in place. That’s a team of three people.

Which then of course was a surprise to notice that the many million company of Mailchimp is not capable of making sure that it is all in order, which is demonstrated with this image:

Simply maybe not as secure as it could be

Simply maybe not as secure as it should be

A bit similar to Return-Path managing their newsletter subscriptions, when you make a claim to be the best at something, you need to demonstrate by doing it perfectly yourself.


Changing the registered dropbox email address

Whenever I sign up to some website or service, I always register with the email address [myname]-[service]@[mydomain].

For example, here on wordpress I am registered as “”, where of course “me” and “” are different values.

I have done that for over 10 years, if I remember well. The nice thing about it is that you can track down the source of emails you receive, and you can verify that this is correct use of the email that was registered. The drawback of it is that many mailing list systems block your postings, because when you write to it with your real email (which is without the -wordpress for example) they say you are not a member of the list (which technically is true).

Now quite some time ago, and I could have written about this before, I started receiving proper spam emails at “”. Now that is rather strange. So I contact Dropbox and they admitted they had had a security breach in which many email addresses had been harvested. They pointed me to a post on their site explaining about it.

My spam filters work fine, and I haven’t had too much trouble (another post some day), but today I decided to update my email address with Dropbox, so that I can set up a filter with the old address to wipe anything.

To my surprise, this worked differently than I thought it would. I updated my address to be “”. Strangely enough, I received a notification at my new address that my address had changed. In my case the emails all end up in the same place, but shouldn’t I have received it at my old address? Then it can be a safety feature to ensure that an account is not being hijacked. For that to work, the old address needs to be notified of the change, not the new one.




optimising css and javascript, csstidy, jsmin

A common trick for websites to optimise pages is to “minify” the CSS and Javascript files used in the site.

There are many tools around that do this. Most of them are websites where you have to upload your content to get the compressed version back. I was looking for a commandline version. A popular one seems to be the Yuicompressor.

So I investigated doing this for phpList. I wanted something that would make it easy to work on the CSS and Javascript, and then wrap it up with a single command into the minified versions.

I found an interesting project that seems highly under-exposed: Mince. With mince, you can set a config file once and then all you need to do to update the minified versions is run “mince”.

Mince uses two external utilities, jsmin and csstidy. To get JSMin, clone and run “gcc jsmin.c -o jsmin”. Then you may want to add it to your PATH.

On my Ubuntu 12.10 system, csstidy comes as a package. csstidy 1.4-3. This is the C version of csstidy and I found that using it did not correctly parse and minify the CSS Level 3 code.

So, instead of installing this version, get the PHP version of CSSTidy

The PHP version does not come with a commandline version, but by using the following code, it works great with Mince, and the minimised versions of the CSS Level 3 validate correctly.

Write this as “csstidy” and put it in your PATH.

#!/usr/bin/env php

if (!isset($argv[1]) || !is_file($argv[1])) {
  print "Usage: csstidy [file]\n";
if (isset($argv[2])) {
  $outfile = $argv[2];

$css_code = file_get_contents($argv[1]);

$css = new csstidy();



if (empty($outfile)) {
  echo $css->print->plain();
} else {

Instant removal with SafeUnsubscribe™

Constant Contact is quite a large newsletter provider. Their emails always have the footer text “Instant removal with SafeUnsubscribe™. I particularly like the TM, indicating a registered trademark that has been requested, but not yet granted. According to the records this trademark was requested in 2002 and abandoned in 2003. They still use it like that, 10 years later. Seems a rather big oversight, but not such a big deal.

However, I do object to the words “instant removal”. This is incorrect. I have been receiving spam recently from Constant Contact clients (yes, it happens to all of us newsletter providers), and I clicked the link. However, I was not instantly removed. Instead, I had to enter my email address. In many cases, I may not know the address I have been subscribed with. Not only that, as I pointed out in previous posts, having to do another action is not instant, and takes too much of my time. Instead, I mark it spam, and hope that my filters learn to get rid of these messages next time.

Instead, the phpList option “Jump Off” will indeed instantly remove the subscriber from the database. It is quite debatable whether that’s a good thing or not. From a recipient of spam point of view, it’s brilliant. Just the one click, and you’re out. However, as recently discussed on the ECF mailinglist this may cause undesired unsubscribes. For example, if a subscriber forwards the message to someone else, and the colleague clicks the unsubscribe link. That one can be avoided by using the “Forward” feature of phpList (and presumably other systems), which will not include the unsubscribe link. The other one would be when the message (accidentally) is posted on some website, and a Search Engine Crawler follows it. The best way to avoid that, is to either ensure the message is not posted, or to add a “nofollow” tag to the link.

In any case, phpList will send one final message to inform about the unsubscription. The idea here is that there is a final human verification that the unsubscription was really intentional.

linked-in broken record

I’m not sure the term “broken record” is still in use, but linked-in is currently stuck on one. They are sending me the same email every week. It looks like their “auto-responder” or newsletter system is not working very well.

Here’s a screenshot of my Trash folder. As you can see, they are sending me the same email every week. And every week I delete it.

I guess a lack of action on the message makes them think they can try again. I block images, so they are not registering me reading it, and I don’t click it either, so there’s no trace of me ever having received it.

As far as I’m concerned this is spam. I am not interested to have Spanish Ads, and I won’t be in the future either. It may well be possible they have some clever options on their site where I can tell them I don’t want to receive these emails any longer, but I don’t care, and I don’t want to waste my time trying to find out. At the same time, I value linked-in, and I don’t want to block them entirely. So, I end up having to receive their spam, and delete it. They should try a few times, and when there is no response on an address, they should stop sending messages.

And, by the way, shouldn’t an Ad announcing Spanish Ads be in Spanish?

clearing obstacles to unsubscribe

When you finally have managed to build up a list of people who want to receive your newsletter, there often seems to be some desire to hold on to them, no matter what. With this little anecdote, I will explain why this is not a good idea, and how a working unsubscribe link can be crucial to the quality of your newsletter.

All kinds of newsletters I receive are often caused by former clients for whom I installed phpList and/or the Webbler and where I entered my email address. Generally I did that to test it all worked as expected. In quite a few cases, I did that multiple times.

Occasionally I receive emails from these organisations, and in some cases they have moved to some new system. That’s understandable, on the internet things move on and requirements for systems change.

But then I notice that sometimes these systems are a regression on functionality.

With phpList, an important part of the functionality is that the URL to unsubscribe from the newsletter is personalised, so that there can be no confusion on what email needs to be removed from the database. So, a subscriber receiving a message can click the link and they will be removed.

Just now, I received an email from a former client, “Forced Entertainment”. The unsubscribe URL is as follows:

You have received this email because you are subscribed to our mailing list.
 Select this link to Unsubscribe.

The link to unsubscribe is:

It’s a bit unnecessary that the tracking code for the Unsubscribe is duplicated, but there is nothing personal about this URL and when I land on the page, I have to enter my email address to unsubscribe. I use many different addresses, so I do not necessarily know which one is used for this newsletter. In fact, in this case, I am subscribed with an email address that I no longer use, and that is forwarded to me.

But, to make things worse, I have to enter a CAPTCHA code as well. This makes it very complicated to unsubscribe, and I decide it’s a waste of my time, because it takes more than 5 seconds. As a result, I simply mark it spam, and make sure that any further mails from this domain are considered bad behaviour. Instead, a correctly working unsubscribe link, which works and saves the unsubscriber time will dramatically decrease the likeliness of your domain being blocked for spam.

With phpList (download) you can make sure the Unsubscribe link always works. As it is Open Source, it can also be changed to not work, but the intention (and default) is that it will. With phpList Hosted the unsubscribe link is enforced to be in the campaign, and we will make sure it always works.

blank emails in hotmail

Recently a lot of phpList Hosted clients have reported that some of their subscribers receive their campaigns as completely blank emails.

I tracked it down to be caused by pasting content from Word into phpList.

When pasting from Word, a lot of extraneous code is added at the top of the message. This code is made visible when clicking the “Source” button.

The code has several conditional statements in the markup for including styles based on some “MSO” version, like this:

<!–[if !mso]>  <![endif]–>

<!–[if gte mso 9]>  <![endif]–>

<!–[if gte mso 10]>   <![endif]–>

Obviously the MSO is some system versioning of some Microsoft rendering engine or something. But for some reason Microsoft’s own Hotmail is incapable of processing it. The mails all display fine in Yahoo, Gmail and any other email application I have tried. Seems rather ironic.

The solution is to remove the code. It won’t make a difference on the contents of the campaign. I’ll try to work on a way to do this in the application, but that may take some time to sort out properly. Another solution is not to use Word, or to save it as plain text before pasting it into phpList. A third option would be to mark hotmail subscribers to receive the text-only version in phpList. There is an option to “Always send text to” certain domains, but you would have to include all Hotmail like domains, like, and, which can be quite a few.

Considering the ubiquity of Word, this will be another one of those great examples of “coding around a Microsoft bug” that Open Source developers have become accustomed with in the last decade.