I noticed this story recently:

The Metropolitan Police has apologised to victims of the Westminster "honeytrap" scandal after it accidentally sent an email which named all of them.

…

the sender, a detective sergeant in the Met’s Diplomatic and Parliamentary Protection unit, included the recipients’ names in the CC section of the email, rather than BCC, which would have concealed their identities.

Met Police apologises to honeytrap victims over email

It's a nightmare that I'm sure we've all had. Back in 2016, a similar issue occurred at a medical clinic:

A London HIV clinic that leaked data on 781 of its patients has been fined £180,000.

56 Dean Street, based in London's Soho, sent an email newsletter with all patient email addresses in the 'To' field, rather than the 'Bcc' field.

London HIV clinic fined £180,000 for 'serious' data breach

It's worth reading The Information Commissioner's Office report into the issue.

The use of BCC harks back to RFC 680 which was published in April 1975.

BCC: This field contains the identity of the tertiary receivers of the message. This field should not be made available to the primary and secondary receivers, but it may be recorded to provide information for access control.

So BCC has been standard on email systems for at least fifty fucking years and is still a source of confusion.

Interestingly, the 1975 standard doesn't mention what CC or BCC stand for. It is just assumed these are acronyms with which everyone is au fait. Perhaps not surprising since they were in common usage since the mid-twentieth century

When was the last time you used carbon paper to make a copy? Have you ever dictated to your secretary who a memorandum should be blind-copied to?

Email and its tooling are unsuitable to the modern world. Search any social network at any time of the year and you'll find people kvetching about its inadequacies.

Friendly reminder to use literally anything other than email if you need to have a conversation between multiple people that you have any hope in following.

— Emily (@emilyshepherd.me) 2024-12-07T00:46:28.290Z

This isn't a new sport, of course. Twenty years ago, people were complaining about how bad email was:

Email is getting out of hand and people use it in suboptimal ways. They write back and forth, sending documents over and over again, with the end result that nobody knows whether they are working on the correct version of a document and everyone has lost track of where they stand and what the last resolution was on a particular issue on a particular discussion point.

[…]

It's becoming counterproductive and it's not an appropriate medium for many types of communication, so we need to find a way of replacing email.

Dark Blogs: The Use of Blogs in Business 2005

That was written when blogs were in their ascendency. Nowadays, most modern organisations use collaborative documents. A single living document which can be continually updated or commented on. Of course, discussion about the document still often takes place over email or instant messaging or - heaven forbid! - in person.

This, of course, leads to another issue.

@ElenLeFoll@fediscience.org

Elen Le Foll 🇫🇷 🇬🇧 🇩🇪

I am only now realising that some (many?) undergrads do not understand the concept of sending a file via e-mail because they are so used to files being saved in clouds. It's the first time I've had to explain that, if I send you a file, then you now *own* that file and, if you modify it and then (accidentally) delete it, your version of that file is gone (or in the trash, if you're lucky). #GettingOld

---

Perhaps we're on the cusp of obliterating email? Will the youth of today see sending an email as ridiculously old-fashioned as a paper telegram or a landline?

There are, I'll admit, some advantages to email. The most prominent being that the receiver can permanently store a copy. Notwithstanding inept attempts to recall an email (which often highlights its sensitivity) an email delivered is an email stored. That is undoubtedly useful for the recipient.

But it is hard to escape the conclusion that email is an analogue process in a digital world.

So, redecentralise!

I installed phpList which is an open source email campaign tool. My webhost - Krystal - had a one-click install option. But, phpList isn't quite one-click for sending out a regular blog newsletter. I found the set-up to be quite confusing, so here are the steps I took to turn an RSS feed into an Email Newsletter for free.

Install the plugins

1. Navigate to Config → Manage plugins
2. Enable "CommonPlugin"
3. Add the RSS Feed Plugin using the Plugin package URL https://github.com/bramley/phplist-plugin-rssfeed/archive/master.zip

Configure the RSS Feed Plugin

1. Navigate to Config → Settings
2. Scroll down to the RSS Settings
3. Set both Minimum and Maximum number of items to 1
   
   That will ensure you only send the latest RSS item as your newsletter.
4. Set "Use the item summary content (the description or summary element) instead of the content element" to "No". This will allow the full text of the RSS item to be sent.

Edit config.php

For some reason, you need to manually edit this file in a text editor, rather than a GUI.

1. Set define('USE_REPETITION', 1); - this allows the newsletter to be sent whenever there is a new RSS item.
2. Set define('CLICKTRACK', 0); - this removes tracking links from your emails. I don't care who opens my emails or what they click on.

Add The Campaign

1. Go to Campaigns → Send a campaign.
2. Start a new campaign.

Tab 1

1. Campaign subject should be [RSSITEM:TITLE] - that will make the subject line the same as your post's title
2. Compose message should be [RSS] - that will ensure the contents come from your RSS feed.

Tab 2

1. Add your RSS feed's URl
2. Order items "Newest" first - to get the most recent item.
3. Add a custom HTML template. I used one from https://emailframe.work/

<div style="margin:0; padding:0; background-color:#F2F2F2;">
  <h1><a href="[URL]">[TITLE]</a></h1>
  <table width="100%" border="0" cellpadding="0" cellspacing="0" bgcolor="#F2F2F2">
      <tr>
          <td valign="top">
              [CONTENT]
          </td>
      </tr>
  </table>
</div>

Tab 3

1. Send as HTML

Tab 4

1. "Stop sending after" - choose the furthest date in the future possible.
2. "Repeat campaign every" - I chose "hour". That should check the RSS feed each hour.

Tab 5

1. "Lists" - pick the email list you want to send from.

Tab 6

1. You should be finished! It will tell you if there are any errors.
2. Place the campaign in the queue for processing.

WordPress Sign Up Form

You can either redirect users to your phpList subscription page, or put a form directly on your site.

<form method="post" action="/YourSubscribePage/?p=subscribe&id=1" name="subscribeform">
    <label for="email">Email address:</label>
    <input type="email" name="email" required="required" placeholder="" size="40" id="email">
    <input type="hidden" name="htmlemail" value="1">
    <input type="hidden" name="list[2]" value="signup">
    <input type="hidden" name="listname[2]" value="newsletter">
    <div style="display:none">
        <input type="text" name="VerificationCodeX" value="" size="20">
    </div>
    <input type="submit" name="subscribe" value="Subscribe">
</form>

Adjust the hidden parameters based on your list.

If in doubt, go to Config → Subscribe pages, and generate a new subscribe page. Then copy the form from that.

Cron Jobs

You need two cron jobs set up.

Update the RSS feed

I run this every hour:

/usr/bin/php /path/to/YourSubscribePage/admin/index.php -p get -m RssFeedPlugin -c /path/to/YourSubscribePage/config/config.php

Process the Queue

I run this a few minutes after the RSS feed is updated

/usr/bin/php -q /path/to/YourSubscribePage/admin/index.php -p processqueue -c /path/to/YourSubscribePage/config/config.php >/dev/null

And then...

That should be it. There are lots of options which you can fiddle around with. But the above should be enough to get your first newsletter out.

Huge thanks to Duncan Cameron for graciously answering my noddy questions and helping me out with the config.

The IAB's tech lab is working on a system called UID2. It's a more advanced way to track you no matter what you do and no matter what steps you take to avoid it.

UID2 is a framework that enables deterministic identity for advertising opportunities on the open internet for many participants across the advertising ecosystem. The UID2 framework enables logged-in experiences from publisher websites, mobile apps, and Connected TV (CTV) apps to monetize through programmatic workflows.

Basically, they tie your email address to everything you do. Signed in to watch a TV show? Better sell that info to the advertisers so when you sign in to a different site they can send you targetted messages. Yuck.

One of the ways privacy conscious users normally avoid this is by subtly altering their email addresses for each service they use. For example, GMail ignores any dots in your username. So if you are Han.Solo@gmail.com you can also use H.ansolo@gmail.com or ha.ns.ol.o@gmail.com. A user might sign up to a service and use a specifically "dotted" email address. If they later start receiving spam to that address, they know the service has leaked or sold their info.

You can go one step further and use plus addressing. For example han.solo+amazon@gmail.com and han.solo+github@gmail.com. They both will appear in your normal inbox, but are unique for every service you use. Again, this is great for making sure that someone hasn't sold your email address to spammers.

The IAB hates this.

As part of the UID2 API they specifically describe how an advertiser must "normalise" their users' email addresses.

This means h.a.n.solo+iab@gmail.com becomes plain old hansolo@gmail.com

I think this is pretty shitty behaviour. If someone has deliberately set their email address in this form it is because the user does not want their identities to be commingled.

Last year, I asked them to respect users' privacy and reverse this change. They finally responded:

Thank you for your input, we thought long about this update and ultimately as it stands today it is not a change we would like to add.

So, there you have it. If you want to take even the smallest step to preserve your privacy - tough. If you want to track which IAB members are using your data - tough. If you want to track users even if they don't want to be tracked - the IAB is happy to help.

If you want to opt out of this - and you trust the IAB to handle your data safely - you can submit your email address and phone number to https://transparentadvertising.org/.

Personally, I recommend installing the uBlock advert blocker on all devices which support it.

We don't have any kids, thankfully - and are not having any in the future. My wife was literally recovering from a sterilisation procedure when the email arrived. So it seemed a bit weird that they'd send her a message like that.

My wife has never booked a child's fare. She's done nothing to indicate to them that she has spawned. They know that she's married and female, because she set her title to "Mrs". They got her date of birth from the ID checks they carried out - we think.

As far as we can tell, they've unilaterally decided that all married women of a certain age must have kids. Or, perhaps, they just lazily sent the message to all women?

So, she spoke to them, to ask why this specific piece of guff had been sent to her. All they'd say was the rather nebulous statement that the emails was a "targeted email sent to a number of passengers [...] When passengers use our services we're able to use this data to help us target communications effectively."

Not really answering the question. But they decided to bung us £20 of M&S vouchers for the "upset".

Even the most modest of interactions with a company will be data-mined for trivial details in the vague hope of getting you to spend more money.

Here are a few tips if you want to avoid getting microtargetted like this:

• Consider using a gender neutral title like Mx - or earn yourself a doctorate.
• Use an initial rather than a first name. Names can be used to determine likely age.
• Don't answer any demographic questions which aren't necessary to the provision of the service, or have a legal/regulatory basis.
• You generally can't unsubscribe from service emails, but you can close your account once you've finished your transaction. Digital hygiene is essential!

Of course, if you complain about a mistargeted email, that's another data-point they have about you!

I don't deal with people's personal information often. So I was surprised to receive an email with a multi-megabyte spreadsheet called "Pay and Bonuses 2020". The email contained this doozy of a sentence:

“Due to GDPR the attached file is password protected, I will send the password in a separate email”

I shit you not.

I checked the sender. They didn't work for my organisation, or any related organisation. We had exchanged emails before, so I suspect email autocomplete had got a bit confused and autofilled "Terence Eden" rather than "Tegan Jovanka" or something.

Two minutes after receiving the email - and before I'd had a chance to inform the sender of their mistake - I received another email.

The password is "03022020" - no quotes

Yup, today's date. Fiendishly difficult to crack...

What are you trying to prevent?

I'm trying to understand the thought process going on here. I think it's based on some faulty comparison to the regular post service. If someone randomly snatches an email, they are unlikely to also randomly get the password.

But that's not the threat we're facing here. If someone is listening to the network - they'll have both emails. If someone gets access to my inbox - they'll have both emails. If you've sent the email to the wrong person - they'll have both emails.

The only thing this prevents is someone accidentally forwarding a single email.

How to solve this?

Sending an encrypted document through email is fine.

But the password should be sent through an independent channel - preferably one you can authenticate.

In this case, here's the process I would recommend:

1. Send the document via email
2. Call the intended recipient
3. Verify you're speaking to the right person
4. Confirm that they have received the email
5. Tell them the password

Hopefully they'll store it somewhere secure, rather than write it on a Post-It note.

There are alternatives, of course.

• Send a link and have someone sign in with the correct credentials.
• Call the recipient and tell them how to access the document.
• Text them the password
• I'm sure you can think of more.

But, please, whatever you do - think about the threats you are trying to defend against.

I clicked dial, and this is what filled my screen:

An absurdly long phone number. Bemused, I went to inspect the link I'd clicked. This is what it showed:

The tel: URl scheme is brilliant. You can write something like:

<a href="tel:07700 900123">Call Me!</a>

And when you click on Call Me! your phone dialler will pick up the phone number and offer to place the call. Nifty!

In this case, the crappy marketing system is adding Urchin Tracking Module parameters to every link. Including the phone numbers.

tel:02083178830?utm_medium=ecrm
&utm_source=email
&utm_campaign=TRAN
&utm_content=UK_TRAN_01_0_ORDER-CONFIRMATION_E_V01
&campaign=TRAN
&adgroup=UK_TRAN_01_0_ORDER-CONFIRMATION_E_V01
&utm_term=restaurant_phone_3_3

To be clear - this is useless. The user clicks on the phone number, the device passes the URl directly to the phone dialler. An HTTP request is never made and those parameters are never sent to a server.

Now, in fairness, perhaps my Android dialler should probably be smart enough to recognise the cruft at the end of a phone number and discard it. This is Postel's Law in action.

Except... My reading of the RFC says that the dialler is handling things correctly.

If the reserved characters "+", ";", "=", and "?" are used as delimiters between components of the "tel" URI, they MUST NOT be percent encoded. These characters MUST be percent encoded if they appear in tel URI parameter values.

For example, if I wanted to dial +447... I should use tel:%2B447...

The dialler sees the unencoded ? and treats it as a delimiter. It then sees utm and assumes the letters are part of the phone number. Just like you can dial 1-800-FLOWERS, you can write tel:1-800-FLOWERS and have it go through to 1-800-356-9377.

utm medium on a telephone keypad is 886633486 - which is exactly what appeared on my phone screen.

So, if you're writing link tracking software, please make sure only to add parameter to URls where it makes sense.

In the time it took me to write this post, my meal got delivered and it was delicious!

Just Eat UK

@JustEatUK

Replying to @edent@edent Thanks for getting in touch and sharing this feedback with us Terence, we appreciate it and we'll be sure to bring this to our tech team's attention. ^EM

---

We both want to see the bills, and we don't want to rely on the other forwarding us an email, or sticking the PDF into a shared folder.

Terence Eden is on Mastodon

@edent

Couples of Twitter! How do you handle emails for "joint" things?

Like utility bills, hotel reservations, and other domestic accounts.

📊

---

Email comes to only one: (240)
240
Joint email address: (46)
46
Something more complex: (26)
26

---

Moving house gave us the opportunity to change all our joint billing accounts. Here's our slightly convoluted setup.

1. We bought a new domain name. As all good projects start.
2. I set up an auto-forward catch-all address. So "anything @example.xyz" is immediately forwarded to my email and my wife's email.
3. We use BitWarden password manager - that lets us share passwords with each other.
4. One of us signs up to a new service as servicename-2019@example.xyz, generates and securely shares a new password, and we both receive the confirmation email.

Why are we doing this?

• One of us could die. It would be extremely annoying to be locked out of an account during a period of bereavement.
• We're jointly responsible for most of these things. It seems silly to split accounts arbitrarily.
• If my phone breaks while we're on holiday, my wife still has a copy of the hotel reservation.
• Neither of us want yet another email account to check.

Reasons not to do this

• If the domain gets hacked / breaks / is blocked or disabled - we'll have lost access to everything.
• We might get divorced. Decoupling things could be harder. Or one of us could lock the other out.
• Surprises and presents are still done on our personal accounts.
• Hard to send from a joint email without setting it up specifically.
• It makes us look like one of those weird old couples who have a joint Facebook account.

What other people do (A.K.A. Market Research)

Caroline Jarrett

@cjforms

Replying to @edent@edent I've answered for me, but my parents only have one email address so they go with 'joint email address'.

---

Carrie Kleiner (Barclay)

@ThisIsCarrie

Replying to @edent@edent Cc or forwarding. But like many others we don’t always share bills-related emails, we just deal with them and mention it if it’s relevant or important.

---

Samathy Barratt

@Samathy_Barratt

Replying to @edent@edent Comes to one address - if its a thing we both need to care about(Travel plans, mostly), the receiver forwards it to the other person.

We don't really consider bills emails to need the attention of both of us. We'd tell each other if an email does.

---

Carol ⭐️

@CarolSaysThings

Replying to @edent@edent Poorly is the unhelpful answer. Most bills/utilities go to my email, but for trips we split the admin. So Thom books the hotel, I do train etc.

Can’t think of how to make it better other than a joint email, as when we’ve given people both addresses, they still always email me.

---

How do you handle this?

Leave a comment in the box. One comment per couple, please :-)

Anti-virus warning – 1 attachment contains a virus or blocked file. Downloading this attachment is disabled.

Google, in its efforts to protect me from myself, have retroactively blocked certain filetypes from being downloaded.

If you try to forward the mail somewhere else, you get this error.

For security reasons, Gmail does not allow you to use this type of file as it violates Google policy for executables and archives.

Here's how to circumvent their block.

1. Open up the message.
2. Click on the ⋮ on the top right of the message
3. Select "Show Original"
4. Select "Download original"
5. This will download a file called message.eml (Or whatever the subject of your email was).
6. Install the munpack tool using sudo apt install mpack (Or whatever arcane commands your OS uses).
7. Run munpack message.eml
8. Ta-Da! you will now see a message like AttachmentName.apk (application/vnd.android.package-archive) the blocked file is now downloaded.

I suppose it makes sense for your mail admin to block potentially harmful files. It's just annoying when I file I wrote myself, which I emailed myself, can't be retrieved by myself.

I signed up for a trial of Join.me back in 2012(!) and as far as I'm aware, never used it again. Checking my records, this piece of spam is the first email I've received to that address in 7 years. The email address in question does not appear in the Have I Been Pwned breach database.

I sent a snarky tweet and was impressed when LogMeIn contacted me directly (my public contact details are on Twitter).

After giving them the details, they replied:

We have completed our analysis and confirmed there is nothing suspicious in our environment. Additionally, we have a proactive Digital Risk Protection in place to monitor our domains.

Well, that's a good start. But it still doesn't explain where it came from. They also said:

We have identified that your email ID was part of several third party breaches (mostly related to marketing vendors). Link to the finding - https://dehashed.com/search?query=em.nioj.2102@shkspr.mobi

I wasn't aware of the "Dehashed" service. It's sort of like HaveIBeenPwned but less accurate. If you type in a completely new email address - it will report a false positive if any email on your domain has ever been compromised. Try it yourself.

I reported that back to LogMeIn and am yet to get a response.

As far as I can tell, there are four possibilities.

1. A spammer guessed my unique email address.
2. Join.me gave my email address to someone when I shared my screen with them. That user has leaked my address.
3. Join.me has been breached.
4. Join.me has sold my email address.

I think it is unlikely that a spammer would be bothered to guess email addresses, and even less likely they'd guess which service I had an account with.

I don't remember actively using Join.Me, nor what their privacy policy was half-a-decade ago. It is possible they shared email addresses back then. But that would be an odd design decision.

So I'm left with the conclusion that - somehow - my email address has leaked directly from Join.Me.

LogMeIn suffered a breach in 2012 - but didn't acquire Join.me until 2018.

All very curious. If you have received spam to a Join.me unique email address, please let them know.

The original Android phone - HTC Dream - had 192MB of RAM. The latest Android phones tend to have 6GB. A 32 times increase in a decade. Laptops have also leapt forwards in speed and memory. Sadly, no one on the Gmail team has noticed.

It's 2019, and Gmail app users are still seeing the dreaded "[Message Clipped] View entire message" error.

It's just as bad on the web version of Gmail - even on Desktop Chrome.

Google don't even do fancy AI magic to truncate these messages. You'd think they'd truncate at the end of a word. Or even in the middle of a word. They don't.

Nope, just slam straight through that HTML. YOLO!

What causes this? For unknown reasons, Gmail truncates messages at 102KB. That's about half the storage space of a floppy disk.

I'm talking 🖬, not 💾!

This is annoying for people sending newsletters - even the mighty MailChimp can do no more than offer some tips to shrink your latest newsletter.

Worse still, marketing emails know that if they pad out their messages, they can hide the unsubscribe link!

Oh, and as a bonus, if you click on "View entire message" - you get the old version of Gmail and Google's logo.

Google updated their logo in 2015. You'd think in the last four years, someone on the Gmail team would have received a long email and then filed a bug report. But no.

We can argue about whether emails should be chonkie-bois or not. But they are. People want full styling, images, and fancy features - not just ASCII text and the occasional uuencoded attachment. That's the world we're in now.

What can be done? There's literally no point me taking this up with Google. People have been complaining about this for over a decade and nothing has been done to fix it.

"User-focussed" my shiny metal arse.

So, here's a whinging blog post which - if I'm very lucky - won't make Google lock me out of my account again.

Bill Gates probably didn't say 640KB ought to be enough for anyone - but someone in the bowels of Google sure as hell believes 102KB ought to be enough for any email.

The EU has announced that it is providing funding for bug bounties on critical open source projects. They've split the programme between HackerOne and Intigriti.

I signed up to Intigriti, and instantly received a confirmation email.

Can you guess where you go if you click the big "Activate Account" button?

I think that's the first time I've ever seen a .lu domain in the wild. Hardly surprising as there's fewer than 90,000 of them.

This looks like a phishing URl. It doesn't use https, it's a random string of gibberish characters, and an obscure domain.

It is happens, the site is legitimate. MailJet - an email marketing firm - use it as a redirector. I assume that Intigriti use them as a mailing service, and want to track every single click you make on their emails.

Why are their statistics more important than your privacy and security?

Why is this bad?

Links to http sites are not secure. That means your visit to that URl can be seen by your ISP and anyone else between you and your destination.

A user clicking on that insecure URl risks having their request intercepted. While an attacker can't log in using the data they've captured, they would be able to redirect the user and phish their details.

Why use a 3rd party?

Basically, if Mailjet gets hacked, or goes rogue, they can start phishing all of Intigriti's customers.

Thankfully, Intigriti had the good sense to not use this tracking on their password reset emails. Indeed, I must commend them on their general security, and their swift responsiveness to this minor security issue.

This isn't the hack of the century - this is low-hanging fruit. I've reported identical issues to CloudFlare, Udacity, and several others.

PLEASE STOP TRACKING EVERY LINK IN YOUR EMAILS!

Or, if you really have to - make sure your tracking server supports https, is controlled by you, and doesn't have a daft domain name.

Timeline

• 2018-12-31 - responsibly disclosed.
• A few hours later - confirmed fixed and bounty offered. Filled in my IBAN details.
• 2019-01-02 - £90 deposited in my account.
• 2019-01-04 - permission given to publish.

When you click a link on a webpage or an email, your browser opens up that link and sends the newly visited webpage a Referer Header. (The misspelling is a historical artefact.)

This says "Hello new site, I was referred here by this previous website." This has some privacy implications - the administrator of a web site can see which website you were on. Usually this is fairly benign, but it can leak sensitive information, as I shall demonstrate.

On my website's referral logs, I noticed these links:

They are caused by users receiving an email from a MailChip mailing list. You'll notice each link is unique. If you visit the links, you can see the newsletter that was sent out.

That's not much of a privacy issue, unless the title was particularly salacious, but the next part is a problem.

The link goes to the web version of a specific user's copy of the email. Which means, at the bottom, there are links to change their email address.

What happens if you visit the update email address link?

Foiled! Unless it is a very specific email, you won't be able to recover any information. D*****.T****@w*********.gov might be revealing, for example.

But it's when you visit the unsubscribe link at the bottom of the update email page that things go wrong:

The user's full email address is visible.

(I've spoken with Dan and he graciously agreed to let me share a screenshot of his email. You should check out his website http://newlocalmedia.com/)

So, there you have it. If you visit a link from a MailChimp newsletter, you risk having your email address and your reading habits broadcast to a site owner.

A Fix

MailChimp can easily fix this. It's possible for a website to tell a browser not to send referrer information. There are two main ways to do this.

Each link can be explicitly set not to provide a referrer: <a href="https://example.com/" rel="noreferrer">

Alternatively, the whole page can be set not to leak referral data: <meta name="referrer" content="none">

Response timeline

• Monday 4th December - I emailed whitehat (at) mailchimp.com as recommended by a MailChimp engineer. I informed them that I'd publish a month after notification.
• Tuesday 5th December - Confirmation from MailChimp that they would correct this flaw.
• Tuesday 3rd January - Asked for progress, due to the holidays they asked me to delay publication.
• Thursday 18th January - Published this post.

Terence Eden is on Mastodon

@edent

MailChimp leaks your email address shkspr.mobi/blog/2018/01/m… pic.x.com/3bhb3bfpol

---

Intuit Mailchimp

@Mailchimp

Replying to @edent@edent The issue has been fixed. We’re sorry for the delay, and we’re reviewing how we handle reported issues.

---

Discussion around the web

• InfoSecurity Magazine
• TripWire
• SecurityLab
• Security.nl
• Reddit's /r/netsec
• Graham Cluley

Early one morning, I received this email from someone I know (details redacted by me).

It came from his email, it has his signature at the bottom. This doesn't look like someone hijacking his email so far.

I don't put much stock by "Protected by Antivirus" claims - because they provide no proof that scanning has taken place.

I know you shouldn't open attachments. But it's a PDF and Google is showing a plausible looking preview. It was early in the morning, and I clicked on it.

*sigh* Last night I had factory reset my phone. I was slowly logging back in to all my services. So this screen wasn't unexpected for me. And, to be honest, I've got a bunch of Google accounts and always have to log in and out of them. OK, let's type in my email.... WAIT! WHAT?

A look at the URL bar shows accounts.googledrive.com.adge.gq. That's not a Google URl. Had they used something like login.accounts.googledrive.com... it would have been long enough for me not to see the phony adge.gq at the end. I'd almost certainly have clicked through.

The rest of the page is a pixel perfect recreation of the Google login page. With the exception of the "email provider" choice. If I'd have been less awake, I'm fairly sure I'd have fallen for this.

I put in a fake email just to see what would happen.

Asking for a password - thankfully, the scammers didn't use Gravatar to show the user a picture of themselves.

I put in a fake password - and got this extraordinary attempt to phish my details.

ARGH! Trying to steal yet more information. That's a realistic error message. I'm used to seeing asterisks blocking out my sensitive details.

If you fell for this, you've given up your email and password - no doubt used to send more spam - and opened yourself up to a barrage of scam phone calls claiming to be from your "email provider". If you reused your password with any other service - like your phone provider - your entire online identity is at risk of compromise.

I know what you're thinking. I should never have clicked on that link in the first place. I am usually quite security minded. In fact, before clicking on it, I long-pressed on the link so that Google could show me its destination.

Even a vigilant user gets no protection here from Gmail.

Today these criminals were unlucky. But they only have to be lucky once. Users will have to be lucky always.

This leads to an interesting question:

Marc Blank-Settle @bbcmarc on Threads

@MarcSettle

Is there an easy way to see what device an email is sent from? If I type the attached on an email on my PC, can the truth be shown easily? pic.x.com/i8impwkxlo

---

Because 2016 is maximum news, I'm sure there are some interesting stories based on email releases which have been missed. Metadata tells stories.

So, what metadata can we pick up from an email?

In GMail, it's quite easy to see all the raw data sent with an email as it travels through the Internet.

Let's take a look at some of the more interesting fields.

Here's an email that I've sent from my mobile - I've redacted some bits for my privacy.

Received: from [192.168.1.42] (oxfd.cable.virginm.net. [82.6.ZZZ.ZZZ])
 by smtp.gmail.com with ESMTPSA id l6sm9069017wmg.11.2016.10.08.09.37.57
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Sat, 08 Oct 2016 09:37:58 -0700 (PDT)

Well, first off we can see the sender's internal IP address. That gives us a little insight into their network topology. Of more interest is the sender's external IP address.

This can leak all sorts of interesting information. Location, service provider, connection speed - even ISP contract details in some cases.

Let's suppose someone sends an email which says "Sorry, at home with the flu today." You check the IP address and find that they're connected to the WiFi at Disney World. Isn't that interesting...

A little further down the headers, we find (again, redacted)

Message-ID: <yqwertyuigm4u5v.1471234534@com.syntomo.email>

Oh ho! What do we have here? The Message-ID is a unique string. Most email clients will choose a unique suffix.

This means, if you received this message from me, you could tell which email program I used and (possibly) which device.

So if I send you an email saying "sorry, my phone is broken" - you'll be able to tell if that's a lie.

There's another leak of client information at the multipart boundary

Content-Type: multipart/alternative; boundary="--_com.syntomo.email_596674815977850"

----_com.syntomo.email_596674815977850
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SGVyZSB3ZSBnbyEg

Much more

This brief blog post only scratches the surface of what can be found - and what you could do with the information.

Other "interesting" metadata includes:

• User's Timezone - not as accurate as an IP address, but if their phone says they're at GMT+2 but they claim to be at GMT-7, is that interesting?
• Reply threading - was this email originally a reply?
• What language their equipment is set to. Some email headers contain Accept-Language: and Content-Language: information. Why is your "Urgent email from the FBI" sent from computer that's set to Chinese?
• Software versions - do the sender's servers have known vulnerabilities?
• Operating System - is the sender's equipment up to date?

I'm sure there are several other pieces of information which could prove interesting.

Manipulation

This is not a cast iron investigative tool. It is possible for programs to mangle the metadata - either deliberately or not. Some people will take care to mask their email footprint, others will not.

Metadata is everywhere. While your emails are unlikely to get leaked to the press (I hope!) you should consider just how easy it is for a little white lie to be uncovered.

Sent from my iPhone.

A few years ago I got the Chinese domain name 莎士比亚.org. You can browse to it, link to it, and send email to it. Or can you?

When I tried two years ago, none of the major email providers supported sending to non-ASCII email addresses.

Today, I tried again with six of the big "Western" webmail providers. How did they do?

Show Me The Data!

I tested by trying to send an email to test@莎士比亚.org and the Punycode representation test@xn--jlq54w7ypemw.org

Winners!

Both Gmail and Outlook failed the last time I tried them - I'm very pleased to say that both of them now support sending to Chinese addresses.

One strange thing to note, when looking through Outlook's message details, I found this example of Mojibake.

Losers!

Yahoo

The biggest loser is Yahoo. Very strange considering Jerry Yang, their founder, is Taiwanese-American. Even stranger given Yahoo's continued dealings with China.

The Yahoo webmail portal simply wouldn't let me send to a Chinese domain name.

The Punycode representation appeared to send but immediately failed.

iCloud

Apple's much-vaunted "It Just Works" philosophy obviously doesn't extend to International email addresses. It accepted the Punycode but gave this delightful error message on the Chinese domain.

OWA

Microsoft's Outlook Web Access got very confused and tried to look up the email address in the local directory.

Errr?

⭐ FastMail

Lots of people recommended that I try Fastmail - it really didn't like the look of the Chinese domain and painted it with a red error colour. That said, it sent the email without further complaint.

What about a Chinese Local-Part?

Email is a venerable protocol. That's a polite way of saying it is old and outdated. The local-part of the email address (test@) is generally restricted to a handful of 7 Bit ASCII characters. None of the email providers I tried would let me sign up with a Chinese name. So no 你好@yahoo.com for me!

But what happens if you're foolish enough to try to send an email to 你好@莎士比亚.org?

Well you'll probably get this error message:

In 2012, RFC 6531 defined how International Email Addresses should work. Over four years later and support is still not widespread.

It's 2016 and the majority of the world can't send an email to their preferred name.

The Guardian is very hot on security. Many of their writers have PGP keys which they publicly advertise. In theory, that's great (complaints about PGP notwithstanding) - but the reality shows just how tricky it is to act in a security conscious manner.

Have a look at Alan's Twitter profile.

In the bio, we see a link - http://bit.ly/1g4S9WR which points to http://static.guim.co.uk/ni/1393869928289/Public-Key.asc.

Let's take a look at a few reasons why this is sub-optimal.

Control

Who controls bit.ly? Not Alan. Not the Guardian. How easy would it be for a rogue employee to subtly redirect that URL elsewhere?

Gone are the days of Libya exercising its control on the .ly space (you did know that's what .ly stood for, right?) But that doesn't mean you should trust a third party with directing people to sensitive information!

Bit.ly isn't accessible over HTTPS. A sufficiently determined attacker can see who is accessing the page - and possibly redirect the URL to a different site.

Information Leakage

Most bit.ly links allow you to append a "+" to the URL to see a page of statistics. I've written about this several times.

Off we go to http://bit.ly/1g4S9WR+

We can see when a cluster of people have visited the URL and what country they're in. Is this leaking the identity of a journalistic source? Not directly - but it could help narrow down the target.

Homographic Disambiguation

Bit.ly allows you to create your own custom URLs. Useful for pulling pranks - and extremely useful for redirecting people.

So, if someone hacked the Twitter account and replaced http://bit.ly/1g4S9WR with http://bit.ly/Ig4S9WR - how long would it be before someone noticed? The latter example uses an upper-case i rather than the numeral 1 - and points to my PGP key.

Final Destination

But, let's assume that no-one has monkeyed with the shortlink. We end up at http://static.guim.co.uk/ni/1393869928289/Public-Key.asc.

What is "guim.co.uk"? I guess it's a server used by the GUardian to serve IMages - but it doesn't quite carry the same trust as seeing the public key on TheGuardian.com

guim also suffers from security issues. It's not served over HTTPS - which means that it's possible to see who is accessing the page and, crucially, a man-in-the-middle could alter its contents.

Putting it all together

By exploiting one or all of these weaknesses, a malicious attacker could create quite a convincing forgery.

If a random Bit.ly link took you to GUlM.CO.UK (a lower case L) and served you a PGP key for alan@guardian-email.co.uk (not the real address) - would you be convinced that it was a legitimate key for the correct user?

Fixing It

This is a pretty simple fix.

• Use a direct link...
• ...to a trustworth site...
• ...served over HTTPS...
• ...
• That's it!

Security is, sadly, too hard for most people. I wrote about how freedom fighters in South Africa were unable to maintain security due to human weaknesses - nothing much has changed in the intervening years.

I've shared these tips directly with The Guardian's security people, and they are in the process of changing to a more robust system.

I've been reading "Think Like A Freak" by the authors of Freakonomics. In it, the authors ask us to start thinking more like maverick economists. It's a fine way to increase your cognative ability and get a fresh perspective on the world.

I'd like to ask you to think like a hacker. Find every weakness in the chain and work to eliminate it.

Get About A Minute as soon as each episode goes live. Stick this Podcast Feed into your podcatcher Or you can Subscribe on iTunes

Intro music "Gran Vals" performed by Brian Streckfus. Stopwatch Icon by Ilsur Aptukov from The Noun Project.

This podcast is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

It would be nice to think that all mistakes and errors we encounter are just the result of bone-headedness. Sadly, that's not the case. Quite often malicious people deliberately try to trick you into taking actions you would normally have ignored.

In usability, we call this a "Dark Pattern".

A Dark Pattern is a type of user interface that appears to have been carefully crafted to trick users into doing things, such as buying insurance with their purchase or signing up for recurring bills.

DarkPatterns.org

I came across a classic example of this when I signed up to speak at a conference recently:

Name redacted to protect the guilty.

The tick-boxes perform the opposite action to each other. One says "tick for no email" the other says "tick to receive email".

A casual reader is likely to see that the first box is "opt-out" and then naively assume that the second tick box performs the same action.

Recently, the department store John Lewis had to pay damages after they spammed a customer.

In their defence, they said:

“Mr Mansfield voluntarily gave us his email address, set up an account online and chose not to opt-out of marketing communications when that option was available to him.

(Emphasis added).

It is not enough to simply ask the customer to opt-out. Companies need to ensure that they only market to people who have actively chosen to opt-in.

In the EU, companies are governed by Article 13 of the Directive on Privacy and Electronic Communication, which states that companies...

...may use these electronic contact details for direct marketing of its own similar products or services provided that customers clearly and distinctly are given the opportunity to object, free of charge and in an easy manner, to such use of electronic contact details at the time of their collection and on the occasion of each message in case the customer has not initially refused such use.

(Emphasis added)

The UK interpretation of the law - The Privacy and Electronic Communications (EC Directive) Regulations 2003, section 22 - states that email marketing may only be sent when...

...the recipient has been given a simple means of refusing (free of charge except for the costs of the transmission of the refusal) the use of his contact details for the purposes of such direct marketing

(Emphasis added)

Looking at the above screenshot, I think it could certainly be argued that there wasn't a "simple" way to refuse to be contacted. It's not "easy" to quickly understand that the same action (ticking a box) can have radically different consequences.

Companies need to ensure that they're only pushing marketing to those people who have clearly stated that they want to receive it. Dark Patterns like this aren't just unethical - they're potentially illegal.

Getting my email account set up with my hosting provider was easy enough but it turned out to be quite tricky to send email to my account.

This is what happened when I tried to send an email from Gmail to test@莎士比亚.org:

Error The address "test@莎士比亚.org" in the "To" field was not recognised

A Quick Bit of History

The Internet was build and designed for English speaking people. At its core, many systems only understand the Latin alphabet. Not the fancy Latin alphabet with exotic accents and symbols, mind, just A-Z, 0-9, and a handful of punctuation marks. There simply isn't the capability to do "foreign" characters.

As non-English speakers began to use the Internet, they wanted methods to read and write addresses in their own languages - not an unreasonable desire!

Thus was born "Punycode" - a method to turn non-English characters into something the infrastructure could understand.

For example, 莎士比亚.org is rendered in Punycode as xn--jlq54w7ypemw.org. You don't have to understand how it works - just accept that it does :-)

I tried the four most popular free email providers to see if their interfaces would accept the following email addresses as valid destinations:

test@莎士比亚.org
test@xn--jlq54w7ypemw.org

The results were not encouraging.

Yahoo

Outlook

The recipient's address can only contain letters (a-z or A-Z), numbers (0-9) and specific symbols (such as @). Please try again.

iCloud

Apple's iCloud was curious. It marked both the IDN and Punycode version in red to indicate that they were invalid. Yet the mail was allowed to send. However, it immediately failed with this error

Reason: syntax error; address contains 8bit characters

Now What?

Internationalised Domain Names have existed since 2010. With billions of people accessing the web from non-English speaking countries, it's essential that web services adapt to accept to serve their needs.

It's simply inexcusable to alienate so many potential users.

...and you should Google for this, because I'm really not sure how to pronounce this. Is it shu-huk-spur? dot mobby?

Le sigh! It's a conversation I have most weeks when I'm on the phone to someone - usually a call centre - and they ask for my email address.

"Sierra Hotel Kilo Sierra Papa Romeo Dot Mike Oscar Bravo India"

Whereupon I am inevitably asked:

Is that dot com or dot co dot UK at the end, sir?

Yes! I have chosen an almost unpronounceable domain on an obscure TLD. Woe is me!

Originally, I thought this wouldn't be a problem. Typing in the domain is quick and easy. But a surprising number of organisations still insist on taking personal data over the phone. Which means more reading out the phonetic spelling.

Frustratingly, a large number of websites refuse to accept .mobi as a valid TLD for email addresses. The geniuses who coded them appeared to think that every email address must end with a 3 character (.com, .org, .net) or 2 character (.uk, .de, .io) sequence. Despite the fact that there are dozens of domains which don't fit in this restriction.

Doubling Down

Being the belligerent sod that I am, I refuse to give in to the tyranny of the spoken word! We live in an digital world and digital data should be communicated by digital means. I want to impart information like my email address over the wire - not over the phone.

Regular readers will know that I was thwarted in my quest to buy a .中国 domain - but I did manage to grab http://莎士比亚.org/.

I think I'm going to move my primary email to that domain. When I get some call-centre who won't let me fill in a form online to give them my details, I shall very politely say my email address is:

Eden - yes, like the garden - at Shā​shì​bǐ​yà... Oh, of course, the stroke order is... Well, no, it's a Mandarin Chinese domain... No... No... Fine, would you like the punycode representation? Hello?

I'll also refuse to do business when any organisation which doesn't recognise IDN email addresses. That'll show 'em!

Perhaps I'll also move this blog over to that domain as well. I wonder what impact speakability has on SEO?