Aug 052020
 

Some people make fun of my plain-text emails, but really, I think it’s time we re-consider our desire for colours, hyperlinks and inline images in email messages, especially for those who use web-based email clients as their primary email interface.

The problem basically boils down to this: HTML gives too much opportunity for mischief by a malicious party. In most cases, HTML isn’t even necessary to convey the information required. Tables are about the only real “feature” that is hard to replicate in plain text, for everything else there’s reasonable de-facto standards already in existence.

Misleading hyperlinks

HTML has a feature where a link to a remote page can take on any descriptive text the author desires, including images and other valid URIs. For example, the following piece of HTML code is perfectly valid:

<a href="http://www.google.com.malicious.website.example.com/">
   http://www.google.com
</a>

There are many cases where this feature is “useful”, however in an email, it can be used to disguise phishing attempts. In the above example, the link is claiming to be to Google’s search website, however would otherwise re-direct that user to some other, likely malicious, website.

Granted, not every user can read a URI to determine if it is safe. There are adults who “grew up with the Internet”, that have never typed a URI in an address bar ever, instead relying on tools like search engines to locate websites of interest.

However, it would seem disingenuous to say that because a proportion of the community cannot read a URI, we should hide any and all links from everybody. For that small portion, showing the links won’t make a difference, but it will at least make it easier to avoid such traps.

Media exploits

Media decoders are written by humans, and humans are imperfect, thus it is fair to say there are media decoders that contain bugs, some of which could be disastrous for computer security.

Microsoft had such a problem in their GDI+ JPEG decoder back in 2004. More recently, there was a kernel-level security vulnerability in their TrueType font parser.

Modern HTML allows embedding of all this, and more. Most email clients will also allow you to “preview” an email without opening it. If an email embeds inline media which exploits vulnerabilities such as the one above, just previewing it will be sufficient to gain access.

Details are scarce, but it would appear it was a vulnerability along these lines that allowed unauthorised access into the Australian National University back in 2018.

Scripting

Modern web standards allow all kinds of means for embedding scripts, that is, small pieces of interpreted code which runs client-side in the HTML renderer. ECMAScript (JavaScript) can be embedded:

  • in <script> tags (the traditional way)
  • inside a hyperlink using a javascript: URI
  • HTC and XBL features in Internet Explorer and Mozilla Firefox, respectively.

Probably lots more ways I haven’t thought about.

Web-based email clients

Now, a stand-alone email client such as Microsoft Outlook, Eudora or Mozilla Thunderbird can simply not implement the scripting features, however the problem is highly acute where web-based email clients are used.

Here, you’re viewing an email in a HTML engine that has complete media and scripting capabilities. There’s dozens of ways to embed both forms of content into a blob of HTML, and you are entirely at the mercy of your web-based email client’s ability to sanitise the HTML before it dumps it inside the DOM tree that represents your email client.

As far as the web browser is concerned, the “email” is just another web page, and will not hesitate to execute embedded scripts or render inline media, whether the user wishes it to or not.

It’s not known what ANU uses for their email infrastructure, but many universities are big fans of web-based email since it means they don’t have to explain to end users how to configure their email clients, and provides portability for their users.

Putting users at risk

Despite the above, it would appear there are lots of organisations that are completely oblivious to this problem, and insist on forcing people to render their emails as HTML, putting their customers/users at risk of security breach.

The purpose of multiple formats in the same email is to provide alternate formats of the same content. Not to provide totally different emails because you can’t be stuffed!

For example, my workplace’s hosting provider, recently sent us an email, which when viewed as plain text, read as follows:

Hello Client,
 
Unfortunately your email client is outdated and does not support HTML emails, our system uses HTML emails as standard. You will NOT be able to read this email.
 
HOW DO I READ THIS EMAIL?
 
To read this email please login to your domain manager https://hostingprovider.example.com/login/ and click on Notifications to see a list of all sent emails.
 
Thank You
 
Customer Support

The suggestion that an email client configured to read emails as plain text, counts as it being “outdated” is naïve in the extreme, and I’d expect a hosting provider to know better. I’m thankful I personally don’t purchase services from them!

Then there’s financial service providers. One share registry’s handling of the situation is downright abusive:

Link Market Services sent numerous emails that looked exactly like this.

Yeah, rather than just omitting the text/plain component and letting the email client at this end try to render the HTML as plain text (which works reasonably well in many cases), in this case, they just sent an empty text/plain body:

From: …redacted… <comms@linkmarketservices.com.au>
To: …redacted…
Reply-To: donotreply@linkmarketservices.com.au
Date: Wed, 29 Jul 2020 04:42:30 +0000
Subject: …redacted… Funds Attribution Managed Investment Trust Member Annual
 Statement
Content-Type: multipart/alternative;
 boundary=--boundary_55327_8fbc43bd-48f3-4aa1-9ab7-9046df02b853
ZMID: 9f485235-9848-49cf-9a66-62c215ea86ba-1
Message-ID: <0100017398e10334-d45a0a83-ff4d-4b83-8d19-146b100017f6-000000@us-east-1.amazonses.com>
X-SES-Outgoing: 2020.07.29-54.240.9.110
Feedback-ID: 1.us-east-1.oB/l4dCmGdzC38jjMLirCbscajeK9vK6xBjWQPPJrkA=:AmazonSES


----boundary_55327_8fbc43bd-48f3-4aa1-9ab7-9046df02b853
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"


----boundary_55327_8fbc43bd-48f3-4aa1-9ab7-9046df02b853
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"

PCFET0NUWVBFIGh0bWw+Cgo8aHRtbCBsYW5nPSJlbiI+CjxoZWFkPgo8bWV0YSBjaGFyc2V0PSJ1
dGYtOCI+CjxtZXRhIGNvbnRlbnQ9IndpZHRoPWRldmljZS13aWR0aCwgaW5pdGlhbC1zY2FsZT0x
IiBuYW1lPSJ2aWV3cG9ydCI+CjxtZXRhIGNvbnRlbnQ9IklFPWVkZ2UiIGh0dHAtZXF1aXY9Ilgt

Ohh yeah, I’m so fluent in BASE64! I’ve since told them to send it via snail mail. Ensuring they don’t burn down forests posting blank sheets of A4 paper will be their problem.

The alternative: wiki-style mark-up

So, our biggest problem is that HTML does “too much”, so much that it becomes a liability from a security perspective. HTML wasn’t the first attempt at rich text in email… some older email clients used enriched text.

Before enriched text and HTML, we made do with various formatting marks, for instance, *bold text might be surrounded by asterisks*, and /italics indicated with forwardslashes/. _Underlining_ could be done too.

No there was no colour or font size options, but then again this was from a time when teletype terminals were not uncommon. The terminals of that time only understood one fixed-size font, and most did not do colour.

More recently, Wikis have built on this to allow for some basic mark-up features, whilst still allowing the plain text to be human readable. Modern takes of this include reStructured Text and Markdown, the latter being the native format for Wikis on Github.

Both these formats allow for embedding images inline and for tables (Markdown itself doesn’t do tables, but extensions of it do).

In email clients such images should be replaced with place-holders until the user clicks a button to reveal the images (which they should only click if they trust the sender).

Likewise, hyperlinks should be rendered in full, e.g. in a web-based client, the link [a cool website](http://example.com/) might be rendered as <a href="http://example.com">[a cool website](<code>http://www.example.com</code>)</a> — thus allowing for malicious links to be more easily detected. (It also makes them printable.) Only plain text should be permitted as a “label” for a hyperlink.

Use of such a mark-up format would have a number of benefits:

  • the format is minimal, meaning a much reduced attack surface for security vulnerabilities
  • whilst minimal, it would cover the vast majority of peoples’ use cases for HTML email
  • the mark-up is light-weight, reducing bandwidth for those on low-speed links or using lower-power devices

The downside might be for businesses, which rely on more advanced features in HTML to basically make an email look like their letter head. The business community might wish to consider the differences between a printed letter sent via the post, and an email sent electronically. They are different beasts, and trying to treat one as a substitute for the other will end in tears.

In any case, a simple letter head could be embedded as an inline image quite safely if such a feature was indeed required.

It is in our interests to curtail the features used in email communications if we intend to ensure communications remain safe and reliable.

Sep 022018
 

Update: Real life intervened and I didn’t get around to reconfiguring Postfix like I said I would. I am doing that now, any longlandclan.yi.org or vk4msl.yi.org will start bouncing now.

Originally, when I started down the path of running my own server, I was an unemployed student, so the servers were hand-me-down second hand affairs and the domains I used were freebie ones.  I started out with no-ip.com, and when they changed their policies, I switched to yi.org (in 2007).

yi.org have been fantastic.  Not only is the domain short, but they also allow many record types including TXT (needed for SPF rules), AAAA (IPv6), MX (for mail servers) and NS, yes they’ll even let you delegate a subdomain to DNS servers of your choosing.

That said, they did have a spot of unreliability a few years back (around 2015).  Given that I now have an income of my own, it no longer made sense to just go for free services, so I bought a couple of id.au domains.  My email client was configured so that in the event someone sent me an email to the old address, they would see the following in my reply:

Reply-To: user@longlandclan.id.au
Subject: Re: …
References: <…>
To: …
From: "Stuart Longland (OLD ADDRESS see reply-to)"
 <user@longlandclan.yi.org>

I’ve been doing this for a few years now.  The yi.org domains now only receive mail that comes into two categories:

  • people who still use the old email address not realising I’ve changed
  • spammers that have harvested the old email address

From October November this year, I’ll be bouncing emails sent to the old domain, with a link to this page.  From November this year In 2019, the MX records for the yi.org domains will disappear.  In short I will not be receiving email from any of the old yi.org addresses from November 2018!

If you see yi.org in an email address for one of us, now is the time to replace that with id.au.  If you see one ending in hopto.org, then you are really out of date.

Please note, I might be able to give you instructions on how to update the email address in your client, but I’ll assume your client works exactly the same as mine does to the pixel, my instructions will be something along the lines of “Go to the Tools menu, click Address Book, type ‘yi.org’ into Criteria, press ENTER, then for each contact you see with my old address in it, double-click on it, change the address and click OK”.

I provide 0 support for email clients I don’t use: I’ll assume you know how to use your system or know how to research the problem, it’s not up to me to teach you as life’s too short.

Jun 282018
 

So this evening, I got a bit of marketing from Telstra. This was to an email address I had used to register the SIM card that I’m trying out in the Kite. I naturally followed the same approach I have with other such suppliers as an anti-phishing tactic.

The email is not unsolicited, but it is a commercial email nonetheless. I figured I’d just quietly opt-out, no need to make a fuss. The email itself was legitimate, so no concern about boobytrapped unsubscribe links. Naturally, I copied the address from their email and paste it into the form on their webpage. I get told this:

Errm, excuse me? That is the email address that I wish to unsubscribe, and if it were invalid, I would not be trying to unsubscribe because I would not have gotten the email in the first place!

Okay, so I’ll need to go through a human to get this resolved, what joy. Navigate the labyrinth that is the Telstra support site (they really don’t want you to be able to make complaints), and I get to a complaints form. First thing I note, they forgot to close an <a> tag (end of line 154)…

<p>If you require immediate assistance with a complaint, <b>Consumer customers</b> can call us anytime on 132200 and say "complaint".<br><br>
If you are a <b>Business customer</b> and require immediate assistance with a complaint, you can call us anytime on 132000 and say "complaint".</p>
<b>Enterprise and Government customers:</b> please go to your specialised contact page <a href="https://www.telstra.com.au/business-enterprise/contact-us/make-a-complaint" target="_self">here</a>.
&nbsp;
<p>Further information on how we handle complaints can be found in our <a href="https://www.telstra.com.au/content/dam/tcom/personal/help/pdf/telstra-complaint-handling-process.pdf">complaints handling process document (PDF).</p></pre>
</div>
<div id="surveyMainDiv" class="main-background">
<div class="place-holder-div" id="surveyMainDivBannerDiv"></div>
<div id="surveyContentDiv" class="content-background">

As a result, Firefox thinks everything to the end of the form, is part of the link! They also close a tag that isn’t open: <pre>.

UPDATE 2018-07-07: This has now been fixed.

Right, so there’s two things. I persevere with the form, resorting to keyboard shortcuts since clicking on any form element brings up that PDF.

Happy that I’ve covered what I wanted to say, I hit the submit. Only to find out the same person who designed the last form, must have designed this one too.

Great, so that’s now three things to complain about.

What really saddens me with Telstra is that today their management tell us they “aspire to be a technology company”. The fact that years ago, Telecom Australia was very much a respected member of the ITU meant it pretty much was a technology company… and the fact they can’t get something as basic as email address validation or a simple web form right, really does show how far they have fallen.

I fully expect this will go back-and-forth while they ask for my browser details (irrelevant, this is broken HTML at their end), my OS (again irrelevant), and then the claim that: “Ohh, we don’t support that!” Which will hold about as much water as a tissue paper G-string.


So, an update. I had a reply back, basically they stated a few things:

  1. they claim to not have seen any marketing emails for the past two months sent to me. (how hard did they look?)
  2. they claim to have taken my name off the list (we’ll see)

They make no comment about fixing the forms. The complaints form now has its closing </a> tag back, so clicking on form elements no longer causes it to pop up with a PDF download. Great, 1 problem of 3 fixed.

I finally had a moment to reply, and did so. In their email, they give an address to send the reply to (because we’re to cool to set the Reply-To header or use the correct From address):

I got back an immediate response:

Delivery has failed to these recipients or distribution lists:

ComplaintResolutionCentre@team.telstra.com
The recipient’s e-mail address was not found in the recipient’s e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.


Sent by Microsoft Exchange Server 2007

Diagnostic information for administrators:

Generating server: srv.dir.telstra.com

ComplaintResolutionCentre@team.telstra.com
#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##

Original message headers:

Received: from ipani.tcif.telstra.com.au (10.97.216.198) by
 ties-smtp.in.telstra.com.au (172.49.40.197) with Microsoft SMTP Server id
 8.3.485.1; Sat, 7 Jul 2018 17:58:02 +1000
Received: from ipocni.tcif.telstra.com.au ([10.97.216.53])  by
 ipbani.tcif.telstra.com.au with ESMTP; 07 Jul 2018 17:58:02 +1000
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0GkBACJcUBb/+KwZZaFN5wRlRWBaTKBT?=
 =?us-ascii?q?YYSBgMCAgKGSwtCJwE8FYEggwqqCQUOgmyEHYUAgStDAWaJaIMgSYRqCAUFAQs?=
 =?us-ascii?q?IB1eCWYo0hF4Pg1eBKA6YUIQOgmt2imKIYIUYPYIxoUUCDRsDggU?=
X-IPAS-Result: =?us-ascii?q?A0GkBACJcUBb/+KwZZaFN5wRlRWBaTKBTYYSBgMCAgKGSwt?=
 =?us-ascii?q?CJwE8FYEggwqqCQUOgmyEHYUAgStDAWaJaIMgSYRqCAUFAQsIB1eCWYo0hF4Pg?=
 =?us-ascii?q?1eBKA6YUIQOgmt2imKIYIUYPYIxoUUCDRsDggU?=
X-IronPort-AV: E=Sophos;i="5.51,320,1526306400"; 
   d="png'150?scan'150,208,217,150";a="119258049"
X-Amp-Result: UNKNOWN
X-Amp-Original-Verdict: FILE UNKNOWN
X-Amp-File-Uploaded: False
X-SBRS: None
Received: from eth2015.qld.adsl.internode.on.net (HELO
 mail.longlandclan.id.au) ([150.101.176.226])  by ipxcno.tcif.telstra.com.au
 with ESMTP; 07 Jul 2018 17:57:59 +1000
Received: from [IPv6:2001:44b8:21ac:7053:a64e:31ff:fe53:99cc] (unknown
 [IPv6:2001:44b8:21ac:7053:a64e:31ff:fe53:99cc])	by mail.longlandclan.id.au
 (Postfix) with ESMTPSA id C159B51F720	for
 <ComplaintResolutionCentre@team.telstra.com>; Sat,  7 Jul 2018 17:57:56 +1000
 (EST)
Subject: [SR 1-1580842703975] Re: Follow Up-Your complaint with Telstra
References: <1e3d0bcc-a187-42cb-ac52-1e1ef0f4673b@wsmsg3704.srv.dir.telstra.com>
To: <ComplaintResolutionCentre@team.telstra.com>
From: Stuart Longland <me@mydomain.org>
Openpgp: id=77102FB21549FFDE5E13B83A0C7F53F4F359B8EF;
 url=https://stuartl.longlandclan.id.au/key.asc
Message-ID: <b5da1c9c-bc3d-8b2f-0f56-55361dc16503@longlandclan.id.au>
Date: Sat, 7 Jul 2018 17:57:51 +1000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <1e3d0bcc-a187-42cb-ac52-1e1ef0f4673b@wsmsg3704.srv.dir.telstra.com>
Content-Type: multipart/mixed;
	boundary="------------37DC9E91B74192D682B54693"
Content-Language: en-GB
Return-Path: me@mydomain.org
Reporting-MTA: dns;srv.dir.telstra.com
Received-From-MTA: dns;ipani.tcif.telstra.com.au
Arrival-Date: Sat, 7 Jul 2018 07:58:02 +0000

Final-Recipient: rfc822;ComplaintResolutionCentre@team.telstra.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found

Oops… so there’s another complaint:

I note there’s another address (with an ‘s’ on the end) in the footer of the email, and so I have sent them the following:

Hi,
It's taken a little while to get back to you on this as I've been flat
out, but here goes.

On 07/07/18 17:20, Telstra_Notifications wrote:
> Your complaint with Telstra
>
> Reference no: SR x-xxxxxxxxxxxxx
>
> Dear Mr Longland,
>
> Thank you for getting in touch with us on 28 June 2018 about a
> complaint relating to your Telstra account number xxxx xxxxx xxxx.
>
> I’m sorry that you’ve experienced an issue with your service, but
> I'm pleased to offer you the following resolution.

To be clear, the issue is not with the mobile service itself, that's
been fine for the purpose I've used it. The issue is in the marketing
that came with it, that was unwanted.

> You were concerned that:
>
> * You’d like to be removed from Telstra’s marketing list

Yes, this is correct. It might be polite to ask people when they sign
up whether they want to be on this marketing list or not.

In my case, the service is temporary: I have the loan of a prototype
mobile phone: iSquare Mobility Kite v1.

http://www.kiteboard.io/ is the device being trialled.

The manufacturer has loaned it so that I can trial the device on the
Australian mobile networks, and see how it performs in weak-signal
conditions. I have loan of it possibly for another month or so at most.

(So far, it performs *MUCH* better than the ZTE T83 I use, and holds its
own against the ZTE T84 which uses the same chipset as the Kite.)

I'd have used my own SIM card, but my card is too big to fit in this
phone (mine is a miniature SIM, this phone requires a micro-SIM), and
given its temporary custody, it made no sense to get my existing Telstra
service moved to a new SIM.

Thus for this purpose, I just activated a pre-paid service to be able to
try the device out. I also have a service activated with Optus as it's
a dual-SIM device.

Once iSquare Mobility ask for the return of the device, naturally I'll
have little use for the two pre-paid SIM cards that are presently in it,
and won't have any interest of any offers from Telstra (or Optus).

I have an old 3G phone I can possibly use up the remaining credit of the
Telstra SIM in, otherwise I'll just use my current phone service which
I've had since 2001.

> * Telstra should fix broken complaints form
>
> I've confirmed that:
>
> * We have checked your account and found no marketing emails sent to
> you for the past two months

Allow me to present exhibit A; sent Thu, 28 Jun 2018 00:39:53 -0700.
This is attached.

I'm a little surprised your list management software had trouble finding
it, unless of course, you didn't read the complaint message carefully to
see the address my account was *actually* registered under.

I see you don't mention the issues with the form. One issue makes the
form damn-near unusable for anyone due to malformed HTML causing the
entire form to act as a hyperlink to the complaints information PDF.

The other, prevented me from self-unsubscribing and was the reason for
the complaint in the first place.

Don't worry, the world already knows:
Telstra: another mob that didn’t get the RFC5233 memo
I see the missed tag on the complaint form has now been corrected. The original issue that started this, so far has not been corrected. I've attached screenshots for your reference. > We know you've been put out by this matter so we'd like to fix things > by: > > * Confirming the medium of marketing (SMS, Email, phone call, MMS, > face to face marketing, etc) and date you received it This is email marketing. There have not been any other forms of marketing. > * Removing your name and details from Telstra’s marketing list. > Please be advised that this is only applicable for Telstra marketing > calls. Yep, I understand this. This is a silent number, and a temporary one at that. By Christmas time, this service will be no-more, as it will be surplus to requirements. > If you’d like to talk more about this or accept this offer, please > contact me on 1800 241 787* PIN 5172 or email > ComplaintResolutionCentre@team.telstra.com quoting your Telstra > reference SR x-xxxxxxxxxxxxx number. I'm available Tuesday-Saturday, > 9am-5pm (AEST). For reference, ComplaintResolutionCentre@team.telstra.com bounces. I've attached the bounce message I received, and have also submitted it as SR x-xxxxxxxxxxxxx just in case this email doesn't get through. So that's now 4 issues in total, with 1 resolved so far. If you could fix up the broken email validation on the opt-out form and complaints form, and fix the broken email address in your reply messages then that will resolve the remaining issues. Thanks in advance. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
May 312018
 

So, recently I bit the bullet and decided to sign up for an account with AliExpress.

So far, what I’ve bought from there has been clothing (unbranded stuff, not counterfeit) … while there’s some very cheap electronics there, I’m leery about the quality of some of it, preferring instead to spend a little more to buy through a more reliable supplier.

Basically, it’s a supplier of last resort, if I can’t buy something anywhere else, I’ll look here.

So far the experience has been okay.  The sellers so far have been genuine, while the slow boat from China takes a while, it’s not that big a deal.

That said, it would appear the people who actually develop its back-end are a little clueless where it comes to matters on the Internet.

Naïve email address validation rules

Yes, they’re far from the first culprits, but it would seem perfectly compliant email addresses, such as foo+bar@gmail.com, are rejected as “invalid”.

News to you AliExpress, and to anyone else, You Can Put Plus Signs In Your Email Address!

Lots of SMTP servers and webmail providers support it, to quote Wikipedia:

Addresses of this form, using various separators between the base name and the tag, are supported by several email services, including Runbox (plus), Gmail (plus),[11] Yahoo! Mail Plus (hyphen),[12] Apple’s iCloud (plus), Outlook.com (plus),[13] ProtonMail (plus),[14] FastMail (plus and Subdomain Addressing),[15] MMDF (equals), Qmail and Courier Mail Server (hyphen).[16][17] Postfix allows configuring an arbitrary separator from the legal character set.[18]

You’ll note the ones that use other characters (e.g. MMDF, Yahoo, Qmail and Courier) are in the minority.  Postfix will let you pick nearly anything (within reason), all the others use the plus symbol.

Doing this means instead of using my regular email address, I can use user+secret@example.com — if I see a spoof email pretending to be from you sent to user@example.com, I know it is fake.  On the other hand, if I see someone else use user+secret@example.com, I know they got that email address from you.

Email validation is actually a lot more complex than most people realise… it’s gotten simpler with the advent of SMTP, but years ago …server1!server2!server3!me was legitimate in the days of UUCP.  During the transition, server1!server2!server3!user@somesmtpserver.example.com was not unheard of either.  Or maybe user%innnerhost@outerhost.net?  Again, within standards.

Protocol-relative URIs don’t work outside web browsers

This, I’ve reported to them before, but basically the crux of the issue is their message notification emails.  The following is a screenshot of an actual email received from AliExpress.

Now, it would not matter what the email client was.  In this case, it’s Thunderbird, but the same problem would exist for Eudora, Outlook, Windows Mail, Apple Mail, The Bat!, Pegasus Mail … or any other email client you care to name.  If it runs outside the browser, that URI is invalid.  Protocol-relative means you use the same protocol as the page the hyperlink exists on.

In this case, the “protocol” used to retrieve that “page” was imap; imap://msg.aliexpress.com is wrong.  So is pop3://msg.aliexpress.com.  The only place I see this working, is on webmail sites.

Clearly, someone needs a clue-by-four to realise that not everybody uses a web browser to browse email.

Weak password requirements

When I signed up, boy where they fussy about the password.  My standard passwords are gibberish with punctuation… something AliExpress did not like.  They do not allow anything except digits and letters, and you must choose between 6 and 20 characters.  Not even XKCD standards work here!

Again, they aren’t the only ones… Suncorp are another mob that come to mind (in fact, they’re even more “strict”, they only allow 8… this is for their Internet banking… in 2018).  Thankfully the one bank account I have Internet banking on, is a no-fee account that has bugger all cash in it… the one with my savings in it is a passbook account, and completely separate.  (To their credit though, they do allow + in an email address.  They at least got that right.)

I can understand the field having some limit… you don’t want to receive two blu-ray discs worth of “password” every time a user authenticates themselves… but geez… would it kill you to allow 50 characters?  Does your salted hashing algorithm (you are using salted hashes aren’t you?) really care what characters you use?  Should you be using it if it does?  Once hashed, the output is going to be a fixed width, ideal for a database, and Bobby Tables is going to be hard pushed to pick a password that will hash to “‘; drop table users; –“.

By requiting these silly rules, they’ve actually forced me to use a weaker password.  The passwords I would have used on each site, had I been given the opportunity to pick my own, would have featured a much richer choice of characters, and thus been harder to break.  Instead, you’ve hobbled your own security.  Go team!

Reporting website issues is more difficult than it needs to be

Reporting a website issue is neigh on impossible.  Hence the reason for this post.  Plenty is there if I want to pick a fight with a seller (I don’t), or if I think there’s an intellectual property issue (this isn’t).  I eventually did find a form, and maybe they’ll do something about it, but I’m not holding my breath.

Forget to whitelist a script, and you get sworn at, in Mandarin

This is a matter of “unhappy code paths” not receiving the attention that they need.  In fact, there are a few places where they haven’t really debugged their l10n support properly and so the untranslated Alibaba pops up.

Yeah, the way China is going with global domination, we might some day find ourselves having to brush up on our Mandarin, and maybe Cantonese too… but that day is not today.

Anyway, I think that more or less settles it for now.  I’ll probably find more to groan about, but I do need to get some sleep tonight and go to work tomorrow.

Jan 132018
 

Part of my day job involves being the technical contact for their website, which means we get lots of offers from people offering to put us on the “first page of Google”.

Hmm, last time I checked, the first page of Google was, strangely, Google.  Somehow, I don’t think they outsource their SEO strategy to get there… they wrote the bloody code!

These emails go straight to Spamcop generally… and they send nastygrams to the people hosting the email servers they used.  In some cases, I’ve taken the extraordinary step of blocking frequently abused hosts.

# Block Centrilogic and SmartMailer because they don't act on spam reports.
-A INPUT -s 173.240.14.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 199.43.203.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
# Block OVH because they don't act on spam reports.
# List taken from https://mxtoolbox.com/SuperTool.aspx?action=asn%3aAS16276&run=toolpage
-A INPUT -s 5.39.0.0/17 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 5.135.0.0/16 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 5.196.0.0/16 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.7.244.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.18.128.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.18.136.0/21 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.18.172.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.20.110.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.21.41.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.24.8.0/21 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.26.94.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.29.224.0/24 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.30.208.0/21 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 8.33.96.0/21 -p tcp --dport 25 -j REJECT --reject-with icmp-host-prohibited
…

That is not an exhaustive list.  Sorry to people who use OVH for hosting and were trying to contact VRT/CETA legitimately, but OVH have shown themselves to be grossly incompetent with regard to management of network abuse.  Centrilogic/SmartMailer are more recent additions.

Of course, they keep trying, and thankfully, it takes longer for them to write the email than it does for me to deal with it. This doesn’t stop them claiming little gems like this:

Note: We are not spammers and are against spamming of any kind. If you are not interested then you can reply with a simple “NO”.

Errm, hate to disagree (actually no, in this case, I love disagreement)… but a few points:

  1. Your sending me an unsolicited content…
  2. … without my consent… (no listing in domain registration or scraping from a website is not consent)
  3. … that is advertising a paid-for service or otherwise something you’re hoping to make money from…
  4. … by electronic messaging.

That by definition is an Unsolicited Commercial Email… aka SPAM.  If you claim to be an Australian business, you better have a look at this.  If your ISP is complaining that you are abusing their services by sending spam, then perhaps you need to realise the people you are contacting are not interested!  You have your NO.

Sep 132017
 

I have a virtual machine that I set up as a secondary DNS server which runs OpenBSD 6.1.  Today logging into it, I noticed system messages were piling up in /var/mail because I hadn’t configured the mail server to deliver those messages.  Setting up OpenSMTPD was no trouble, but then I had the old mail (thankfully not much) that was still to be delivered.

There are a couple of solutions out there, written in Perl, Python and PHP (urgh!).  I don’t have Python on this box, and the Perl one didn’t seem to work with the mailbox.  So I cooked up my own:

#!/bin/sh

for file in "$@"; do
        grep -n '^From ' ${file} | {
                prev=1
                while read line; do
                        cur=$( echo "${line}" | cut -f 1 -d: )
                        if [ "${prev}" != "${cur}" ]; then
                                sed -ne "${prev},$(( ${cur} - 1 )) p" ${file} > ${prev}.eml
                        fi
                        prev=${cur}
                done
        }
done

If there’s a line in your email body starting with “From “, it may get confused, but it was good enough for the messages that OpenBSD’s daemons send me. I was then able to pipe these individually into sendmail -t to send them on their way.