On the futility of using Microsoft as an email provider

My $DAYJOB, like many others, have a Office 365 subscription, using also services like Microsoft’s Outlook for email. While I have, at a previous job, had mixed experiences with Microsoft and their upside-down view on how email should work. After fighting with their abysmal Outlook software, and their even worse web interface, my previous employer eventually managed to get the company they had subcontracted for email services to open up IMAP, and that was the end of that. With my current employer, I have used IMAP from the start, first continuing to use the Opera Mail client, despite it being out of support, and recently moving to its spiritual successor in Vivaldi.

This was working fine, I could mostly ignore Outlook and its idiosyncrasies. Until 2022-11-01, that is.

The powers that be at Microsoft were rolling out several changes, one was to remove support for password log-in, instead forcing everyone to use a web browser for logging in (fortunately, that was postponed a bit), but the other was some kind of update to the IMAP servers that failed horribly. Since it was the email client that started complaining, I first thought it was a bug in Vivaldi. And posted about it there. After researching it, I did find that Vivaldi was speaking IMAP correctly, but the servers didn’t understand it. I was pointed to a thread at Microsoft’s support forum, where I was far from the only one to have the problem, across different accounts and mail clients.

One would think that a company that provides a paid-for email hosting service that in an update breaks the support for a standardized network protocol would be quick to fix it. But, no. I am writing this at the end of January 2023, and it is still broken. I guess now that the tech oligopoly of Microsoft and Google has embraced and twisted email into whatever they want it to mean, they can do what they want and not care about end-users, without much recourse.

A sad state of affairs.

Anything can be imported to WordPress

A neighborhood association I am involved in has a web site for local news that grew out of some hand-made PHP scripts from 20 years ago. They have really shown their age, but the work involved in updating it is enormous as each page is its own PHP script with partial HTML, and parts in various templates. It has over a thousand news articles that are worth keeping. What do do, in 2022, to get it manageable?

Well, it seems WordPress is the One True System™ for easy publishing these days, so import it there, then? But as I said, this is a home-grown system with over a thousand PHP pages with hand-edited code.

Perl to the rescue. Fortunately, there were two index files, one with “modern” articles (from after the initial scripting broke down) and one with “archived” pages (from before, where the page display quality was rather low), so at least I had a list of all the pages to import. Right? Well, not really, some had chained links to sub-pages (picture carousels and such), so I had to add that. And making something to parse a thousand “almost similar” PHP documents does require some work, but after several hours of work I have managed to get the tool to read the indices, insert the missing pages where they belong, read the pages and parse their contents and meta-data (headers, dates), and spit out a WordPress-compatible 3 megabyte large XML for import.

Thanks to WP Sandbox, I have managed to test the XML (and iteratively fix the bugs in it) so that I now have one XML file that imports all the articles (minus one that no matter what I do end up being identified as a duplicate of another article, but I will cut my losses and lose that one, it was just a link to another site anyway). Of course I have none of the images and other pages on the sandbox, so I cannot really test that everything works out as expected, that will have to be done on the target site.

Oh, and, of course, I did make the script generate a giant .htaccess file with Redirect directives to map the old self-publish URLs to the new WordPress URLs. We can’t have old links become invalid, can we?

Since this is obviously never ever going to be useful for anyone else, as this is a unique home-grown system, I have published the script over at GitHub.

Displaying EML attachments in Vivaldi on Linux

Until recently, I have been using the old Opera Mail client for my work email. Opera Mail 12 was released in 2013. Being almost ten years old by now, it is starting to show its age with lack of support for newer standards. Since I really like the way the Opera Mail client works, I was really looking forward to the work done by the amazing Vivaldi team (where a lot of my old colleagues from Opera Software ended up, together with a lot of other amazing people), on their Vivaldi Mail client.

As my $DAYJOB uses Microsoft 365 for their email, we have several Outlook users in the house, and sometimes I happen upon a forwarded email sent in .eml format, and while Vivaldi actually uses this format to store email internally, it cannot display an attachment in this format (at least not as of October 2022). An eml file is basically just a bare email message, so it should be easy to read, right? Apparently, not so much. Googling around mostly recommended installing Thunderbird and import it there. That question did have an interesting answer recommending mhonarc, using it to convert to HTML. I ended up expanding on that, writing a script that converts to HTML and then calls back to my stand-alone Vivaldi e-mail instance. I have this as /home/peter/bin/eml-viewer (if you’re using the main instance, remove the –user-data stuff, otherwise replace it with a path to your configuration directory):

#!/bin/bash
if [ ! -e “$1” ]; then
echo ’eml-viewer file.eml’
exit 1
fi
OUT=$(mktemp –suffix .html)
/bin/mhonarc -single “$1” > “$OUT”
/bin/vivaldi-stable –user-data-dir=/home/peter/.config/vivaldi-standalone “$OUT”

The next step is to connect this up to open .eml files. For this, we need to create a matching .local/share/applications/eml-viewer.desktop file:

[Desktop Entry]
Version=1.0
Name=EML Viwer
GenericName=EML Viewer
Comment=View Outlook EML file
Exec=/home/peter/bin/eml-viewer %U
StartupNotify=false
Terminal=false
Icon=mail-mark-unread
Type=Application
Categories=Viewer;
MimeType=message/rfc822;

And finally, make it the default application for opening eml files:

xdg-mime default eml-viewer.desktop message/rfc822

This will leave the temporary HTML files in your temporary directory, so take care about sensitive data if on a shared computer. Set $TMPDIR to somewhere private and clear it periodically.

Reading Icalendar (.ics) file from Outlook on Linux

At $DAYJOB, email is handled through Microsoft’s Office 365, and with that I occasionally get event invitations in Microsofts’s internal format. As I am using an IMAP-based e-mail client (since I cannot stand Outlook Web Access), actually reading those invites can be a bit difficult.

With the default settings, the invitations are presented as a link into the Outlook Web Access client, with only the subject of the event readable (as the email subject). Everything else is completely hidden from the user. Thunderbird does have some built-in code that downloads the calendaring information and displays it to the user, but I am using a different email client and only get the web link.

Entering Outlook Web Access and going into the settings, there is a setting to present invites as Icalendar files (MIME type text/calendar, extension .ics). Enabling this changes the emails so that the event text is presented in the message body, but all the important details, such as start time and location, are only present in the Icalendar file. And while the calendar is “readable” in the sense that it is a text file, it is not readable in the sense that it is easy to find out what it says.

I am running Linux on my desktop, and do not have any calendaring software installed, so nothing wants to pick up the .ics file. And reading it in a text editor isn’t easy. There are several timestamps, and it takes a while to figure out that it is the third DTSTART entry that contains the event start time:

$ grep DT attachment.ics
DTSTART:16010101T030000
DTSTART:16010101T020000
DTSTART;TZID=W. Europe Standard Time:20211103T100000
DTEND;TZID=W. Europe Standard Time:20211103T142500
DTSTAMP:20211102T150149Z

Trying to find software that will just view an ics file in a readable format isn’t easy. I don’t need calendaring software on my desktop (I do have a calendar app on my phone that I could use, though), but it would be nice to display it.

After some intense web searching, I found mutt-ics, a plug-in for the textual Mutt e-mail client. I am not using Mutt, but running the script on the ics file did produce readable output:

$ python ./mutt_ics/mutt_ics.py /tmp/attachment857.ics
[…]
Start: Wednesday, 03 November 2021, 10:00 CET
End: Wednesday, 03 November 2021, 14:25 CET

That’s a step forward. The next issue is that I am using a graphical e-mail client, and this is a text-mode script. The e-mail software runs “xdg-open” to open the file, so I had to create a few items to get it working. First, a script wrapper that runs the script and shows the output using “xmessage” (other software also works, I have not yet found out how to get xmessage to display UTF-8 text properly, so I might need to replace it eventually):

$ cat /home/peter/bin/view_ics
#!/bin/bash
python /home/peter/mutt-ics/mutt_ics/mutt_ics.py “$1” | iconv -c -f UTF-8 -t ISO8859-1 | xmessage -file –
exit 0

Next step was to make a .desktop file that defines the script as a handler for the text/calendar MIME type:

$ cat /home/peter/.local/share/applications/view-ics.desktop
[Desktop Entry]
Type=Application
Version=1.0
Name=View iCalendar
Exec=/home/peter/bin/view_ics
Terminal=false
MimeType=text/calendar;
StartypNotify=false

And to tie it all together, I have to register it as the default handler for text/calendar by running xdg-mime:

xdg-mime default view-ics.desktop text/calendar

There, now running “xdg-open file.ics” opens a xmessage dialog showing the calendar details in a new window. Managed to get it working just in time, the meeting starts in twenty minutes…

Watching the WWE Network on Linux: an update

A few years back, I wrote about how I had to set up WINE to be able to watch the WWE Network from Linux, as they are using an incompatible DRM (Digital Restrictions Management) system, which is not supported on Linux. I have been using the set up pretty much unchanged since, while updating various components.

At one point I had to stop upgrading Firefox, as it started using features from newer versions of Windows that were not supported under WINE. I had configured WINE to make Firefox think it was running under Windows XP, and Firefox had since dropped XP support. If I try to claim a newer version of Windows, Firefox failed to connect to the Internet. The version I stopped at is version 53.0, which means that I am running an old, vulnerable Firefox version for this. This means do not use this browser for anything but watching WWE Network! Doing so may trigger an invulnerability somewhere.

I did keep my Flash Player up-to-date, but the latest Adobe Flash Player update (version 32) failed to run under WINE. Why I do not know, perhaps they also started using APIs that WINE does not support. I upgraded my WINE installation to the latest stable version (4.0), but to no avail. It was still hanging.

The only solution I have found so far has been to downgrade to Adobe Flash Player version 31. I had to dig a bit to find the download page for archived versions of Flash Player, and from there I ran the uninstaller and then downloaded the 31.0.0.153 archive. From that archive I installed the NPAPI Flash Player (31_0_r0_153/flashplayer31_0r0_153_win.exe) and now I have a working setup again.

So, an up-to-date WINE version, but an ancient Firefox and Flash Player. I hope WWE update their web site soon to something a bit more modern that work from Linux as well, but nothing has happened for the last five years, so I am not holding my breath…

Gemini PDA first impressions

I loved the Psion range of PDAs back in the late 1990s and early 2000s, for a while I had a Revo which was perfect for keeping a calendar and such on-the-go, but it eventually broke down and was replaced by smartphones.

My first smartphone was the Sony Ericsson P800; the OS was Symbian, the successor to the EPOC OS of the Psions, but now with just a touch screen and no keyboard. The follow-up units in the P series all had keyboards, and so did my first Android phone, Sony Ericsson’s X10 Mini Pro. But after that it has been touchscreen only. Nice for watching movies and reading web sites, but a nightmare to write longer texts, like this, on.

Enter the Gemini. Launched as a crowdfunding project on Indiegogo in February of 2017, I fell in love with the idea immediately. With the same form factor as the Psion 5mx, with an almost-full keyboard just large enough to type on with more than two fingers, and designed by ex-Psion folks, it looked like the device I had been missing since the Revo died.

Sometimes a laptop is just too big, and the netbooks from a few years ago were simply just too cheaply done, but this form factor is just perfect for typing on the go, like onboard a bus like I am just now.

I got my device earlier this week, and already it has replaced my laptop on several occasions. There is room for improvements, sure, the keyboard is not quite perfect yet and Android might not be the best fit. I have not had time to install the Linux dualboot image just yet, but I expect to spend most time there, as long as the 4G data works there.

All in all, I am very happy with the device. I backed it immediately after reading about it in The Register, as number 10. There are now over 5000 backers, so there seems to be a market for a device that has been missing from the market for 15 years.

Running memtest86 on a Mac Mini

At $DAYJOB, we are having issues with a Mac Mini that is acting up. It crashed on boot, and re-installing macOS didn’t help as it complained about the file system being damaged, no matter if I reformat (“erased” in Apple-speak) or repartition the disk. The built-in Apple Diagnostics tool crashed after about 16 minutes, so I thought I’d run memtest86+ on the machine. But without a working OS boot, I was unable to get it up and running, and googling for information didn’t help.

To get it running, I had to create a bootable USB stick, for which I had to find a Windows machine and run their USB Key installer. However, the disk did not show up in the list of boot options when booting the Mac Mini pressing the Option key. To find it, I had to install rEFInd on a second USB stick (they have a USB flash image ready for download, so no Windows machine needed).

With both USB sticks in the Mac, booting with the Option key let me select the rEFInd USB stick, which in turn found the memtest86+ stick as a “Legacy Windows” image. Now the test started fine.

Sound output from the wrong jack

Debian recently released an update to their stable release, version 8.7, and with it an update to slightly more recent Linux kernel version (up to 3.16 from 3.2). Well, that would be nice to have I thought, and updated my office workstation and rebooted. Everything looked fine, it even picked up and updated the Nvidia graphics driver that I always have problems with. But then, when I tried to play radio over the Internet, the sound suddenly started blaring out from a speaker inside the chassis that I didn’t even know it had, instead of my connected proper speakers.

So, first I thought the driver was broken, so I rebooted back to the old kernel. Still wrong, then I turned power off and back on and started the old kernel, still the wrong output. Strange.

I have a HP Z220 Workstation (from 2013) at the office, with an “Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)” audio controller, with a Realtek ALC221 chip (as per output from lspci -v and /proc/asound/card0/codec#0). It took me an hour of intense googling to find the correct set of keywords to find something, but apparently most English-language threads use “jack” for the outputs. I should have known that.

I eventually stumbled on this ArchLinux thread from 2014 which mentioned a tool called hdajackretask that can be used to rearrange the outputs from the HDA cards. Debian distributes this utility in the alsa-tools-gui package. After installing the package and changing the output type I managed to get sound playing through my speakers again.

hdajackretask screenshot, setting "Green Line Out, Rear side" to "Line out (back)"

Screenshot from hdajackretask, used to select output devices from an HDA audio card

Now to actually get some work done. That is Mondays for you.

The futility of OSX parental control and web browsers

I have kids. Two of them, the youngest is five and the oldest is about to turn eight years old. Since they see me and my wife use a computer regularly, they of course also want to use it. The oldest has access to computers at school, and if they are going to be proficient with computers, they need to start using them at an early age. I have a MacBook Pro that they both have accounts on, both set up with OSX’s default “Parental Control” feature.

That works fairly well when they use the local application (Photo Booth is a favourite, if I hadn’t blocked it their little clips would probably have ended up on YouTube if the knew how to upload them). Well, before getting to the applications, there are all these little pesky pieces of software that phone home on every start-up, under the guise of doing software updates. No matter how many times I block “Google Software Update” or “Paragon Updater” and the like, every time they log in to their accounts, they get a message that they cannot run them. Well, they learn to click “OK” and go on with their life. Using a web browser is a lot more hassle, though.

I had initially set up a whilelist in the Parental Control settings, to only allow them to access certain web sites. That doesn’t work, since every site in the universe now include stuff from other places, either be it CDNs, Google’s web tracking stuff or a JavaScript library that they are too bored to copy to their own domain. I can live with that, a lot of it can be blocked with Ghostery or similar, but that is if you can even get to it.

Trying to even run a web browser on an account that has Parental Control enabled is a chapter in itself. First it is the phone-home auto-update stuff that kicks in every few moments. Then there are the pre-installed shortcuts (at least in Opera) that wants to download screenshots to display inside the Speed Dial screen (why can’t they just ship with default images?). Then even trying to type a web address keeps trying to send every single keystroke to Google, requiring having to close a dialog after every single letter in the URL. In Google Chrome, it seems utterly and completely impossible to disable this behavior. Opera has it, hidden deep inside its configuration options, but I then I have to enter a magic key combination to remove the Search field. And fight the blocked URL pop-ups to remove the pre-installed Speed Dials.

I need to try out Vivaldi for the kids’ accounts. I know it can be configured to be less intrusive, and it doesn’t send all keystrokes to the search engine. When I set up the account for my oldest daughter there wasn’t a stable version around, but it should be fine now.

End of an era

The day had to come, I knew it, I just postponed it for as long as possible. But now it is time to move on, it is time to close down my Fidonet system for good, over twenty years after setting up my first system. My Fidonet history has been going through a lot of different setups, starting out with reading off BBSes using Blue Wave, through a simple point setup with Terminate on MS-DOS, moving on to an OS/2-based system using SquishMail using timEd and Fleet Street as readers, even serving as the Swedish shareware registration agent for Fleet Street for a few years at the Fidonet peak in the late 1990s.

I then moved to a Linux-based system using CrashMail II (for a while, running timEd through an MS-DOS emulator under Linux, before GoldEd was ported to Linux), and lately using a Usenet News reader and the JAMNNTPd software. During my tenure as a Debian developer, I had a lot of this stuff packaged for Debian, but I haven’t checked if they are still there. I have just been using the stuff I compiled several years ago, but lately it has simply stopped working. Maybe my message bases have broken completely, I don’t know, and considering how seldom I read them, I figured now was the time to shut the system down for good.

It is still a bit sad, I remember the peak around 1996–1998, when I moderated a chat area and had enforce a limit of 50 posts per day per author, else it would overflow completely (remember, this was at the time where it could take a day or three for the messages to propagate). Now I don’t know how many years it has been since anyone even posted a single message in any of the derelict Swedish areas. There is some activity in the international areas,

Good-bye, Fidonet!