Category Archives: email

On the futility of using Microsoft as an email provider

by

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.

Displaying EML attachments in Vivaldi on Linux

by

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

by

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):

#!/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…