Welcome to email hell

I like emails. I know, shocker. The guy working on an email client¹ likes emails. Worse than that, I have formed some habits that I would call “best practice”, rather than a habit. Among these are the use of plaintext email, using maildir to always have a backup, and signing outgoing mails.

I even went so far as to call myself an “expert” in an article on how to make email less painful (article in German). Depending on one’s definition of the word “expert”, I probably don’t even remotely qualify for that label, but I certainly know more than the average Joe. Or at least I’d like to tell myself that I do.

To my intense displeasure, I am now working in an environment where the role of email admin would be better filled by a trained monkey or a toddler sucking its toes. Since I can now report on over a year of corporate mailing, I have now reached a bit of a breaking point where I just need to vent for a bit. If you find any of this inaccurate, feel free to enlighten me. Maybe I don’t know of an important consideration that goes into these decisions.

The good

The mail system has an uptime of about 100%. Awesome! Good job!

Also: mandatory and unannounced phishing drills. That’s quite a nice thing. Though it would be nice if the difficulty would exceed Nigerian prince levels.

The slightly annoying

Mail being mail, there are bound to be some annoyances. The favourite IMAP-extension isn’t available, or some configuration I disagree with. These issues are more differences of opinion or easy to work around.

No IMAP

Is IMAP the perfect protocol? Certainly not. With more extensions bolted to it than there are sand grains on the average beach, there is no shortage of potential sources for issues. So what’s the solution? Exactly: disabling IMAP entirely and only allowing Exchange access. Thanks to DavMail, this is at least easy to work around and makes me able to keep a maildir for bad times.

If I don’t split my head open by smashing it on the table at the abhorrent API “design”, the long-awaited OWA (Outlook Web Application) Worker for aerc could at least potentially alleviate the pain.

Mandatory top-posting

To give a famous example:

• A: Because it reverses the logical flow of conversation.
• Q: Why is top posting frowned upon?

If you want to learn how best to use something, it’s a great idea to ask people using a technology extensively. For email, this would probably be mailing lists. Thousands of mails make their way into mailing lists every day and over the decades a few patterns have emerged on how to do it best.

One thing that is omnipresent in these lists is what Wikipedia calls “interleaved style”. Here one would take the parts of the original message that are actually relevant for the reply and would quote them directly and reply directly. While the original mail would be something like:

• Q1: Do you like emails?
• Q2: Even in a corporate context?

The reply would be:

• > Q1: Do you like emails?
• A: Yes, very much. It’s a great way of communicating asynchronously!
• > Q2: Even in a corporate context?
• A: No, that is so shitty, it should get an entirely different name.

Top posting would make this into a very readable:

• A: Yes, very much. It’s a great way of communicating asynchronously!
• A: No, that is so shitty, it should get an entirely different name.
• > Q1: Do you like emails?
• > Q2: Even in a corporate context?

My german teacher would’ve had a good time with something like this. Just put a red line next to it, write “Structure?” and don’t even bother reading this mess.

Legally non-binding fluff

This mail may contain confdential bla bla bla. Aside from this disclaimer being annoying, it’s also legally not binding (not only according to German law^2&3, similar conclusions have been drawn in the US as well and other countries are probably also rather opposed to forcing one-sided obligations onto people without their consent)

I get that companies want to ensure that they are not liable, but this just isn’t the way.⁴ Apart from relying on a potentially uncooperative 3rd party to do your bidding, you also look like you don’t have a basic grasp on logic. Even if those disclaimers were worth the bits they are composed of, you should probably put them before the potentially confidential information. Otherwise it’s not much different from asking them to neuralise themselves.

Capitalised Localpart

Isn’t it lovely to have a capitalised localpart? Moritz@Poldrack.dev⁵ beautiful! To be honest, my word of choice would be: annoying. I don’t give a flying fuck what your address looks like. You can add a name to be displayed in the message list. Maybe use that? Capitalisation leads to problems, but it also adds the following benefits:

Don’t do it. The user doesn’t care, the recipient doesn’t care. Maybe a manager cares, but for that, might I refer you to my post on that topic?

The bad

From annoying and minor inconveniences, the transition to outright bad is flowing. Taken for themselves, these are no deal breakers. But adding them together these explain at least some of the bite-marks on my table.

No folders

While the notmuch users among us may tilt their heads, not having folders (or mailboxes, or whatever you want to call them) is a great way to get a messy inbox. While notmuch has this solved through what I would call “virtual” or “dynamic” folders with its powerful tagging system, the other systems rely on more static folders to bring structure into the chaos. Even the most basic “mail-silo” usually has a “Sent” Folder.

Now there are plans to drop these in favour of a direct uplink to the mail archive system. Awesome. Less structure. Just what I need to say “sorry, I didn’t see your mail. There was too much on top of it.” Whoever had this idea, if you read this: I hope your sleeves roll down while you’re washing your hands.

No signing allowed

I sign my mails. Crazy right? I can’t deny having sent something, I can be sure nobody has modified what I sent, and even if IT used my outbox to send out phishing training mails, users could⁶ immediately see: “Hey, that message is suspicious. Usually they have this badge next to them.” But during my attempts to get the next point alleviated I was told in no uncertain terms “don’t sign your mails, we don’t do that here”. Well, if you don’t value your employer’s (and employee’s) safety, who am I to object.

No, I am not pissed. Why would I? After all I managed that certificate myself, so they had exactly zero work with me signing my mails.

Mail Provider for managers

I am a backend dev by trade. I do occasionally dip my toes into the scary world of web design. What this leads to, is what you’re witnessing right now: A website that is most certainly not concerned with being the most pretty. Of course, I am aware that a Windows 98 style isn’t exactly ideal for selling a product. So I don’t blame companies for making their websites polished and pretty. It is however a great way to see if a provider values style over substance.

The provider at my employer uses Hornetsecurity, a provider I consider so subpar, I manually wrote the link, so I would not give them any SEO boost. However small my influence may be.

Personal pain point is their equation of PGP, S/MIME, and… TLS?! What the actual fuck. Yes, TLS is a kind of encryption. But not all encryption is made equal. PGP and S/MIME are End-to-End encryption and thus on an entirely different level. But hey, why not just sign our mails on the server. If your toenails are not currently curling up from that sentence, allow me to explain: The added value of a signature is that it is made by the client. You have a confirmation that the mail was actually sent by a person and not by a malicious actor who potentially compromised the sender’s infrastructure. Whatever dimwit thought this was a good idea: You don’t do that with S/MIME, you use DKIM, you absolute imbecile!

That there are better ways of doing it, can be seen in competitors⁷.

The ugly

And now for the part that’s the darkest. Not just in mood, but also in what insight this allows into the decision process higher up where the expertise is either not heard or potentially worse: not even provided.

Modifying email bodies

Let’s start off with the cardinal sin: touching the body of an email. The only person doing that. Is. The. Sender. You don’t manipulate a mail’s content, as you never know what this might lead to. It may be a slight inconvenience, or it could be something significantly undermining your companies’ security.

To help laymen understand email-related issues, I like to draw parallels to the good old postal service: As the postal service you don’t touch the content of a letter. You may scan it to make sure nobody’s sending anthrax, but the only person writing the content is the sender. And just how the postal service prints routing codes and invalidates stamps on the envelope, it is of utmost importance that this modification is limited to the envelope. They don’t add a “Sent and delivered with Deutsche Post” at the bottom, and if they did, all hell would break loose. As it should be.

However, with emails, we just accept this practice. I understand that there are things like address and registration information that has to legally be present in a mail, but then you instruct your employees to follow these rules. Maybe preconfigure the mail client with a proper signature and update it when the employee’s details change. All is happy in our little world. What you don’t do is adding that stuff to the body. If you are that concerned with compliance, add it as an attachment. That’s not great either, but still better than taking out the wax crayon and dragging it around the bottom of the mail.

And what if the manager is absolutely certain that you have to edit the body of a mail? Then you get the:

Russian nesting mail

This email contains a secure message that can be read by opening the attachment.

Yeah, sure. To verify your identity, please reply to this mail with your credit card details. Is there a way to make it look less like a low-budget scam? Yes! Just. Show. The. Original. Email.

Yes, this looks legit. But let’s open the attachment:

Oh, there’s another attachment. I wonder what that contains! It has no ribbon though, so it’s probably not safe, right?

Wait, is it groundhog day? Again? Nope. The forwarded message is just attached as an attachment, so it looks the same.

Could it be? The message that was actually forwarded? Awesome! Now I can read it and reply to it, which with Outlook… oh… usually attaches all previous attachments. And thus the cycle continues.

Do I fear any legal threats for sharing this “proprietary information”? No. As the disclaimer clearly states:

E-Mails sent over the internet may have been written under a wrong name or been manipulated

So I can’t even be sure that the sender actually wrote this. Maybe this was just a glitch in the ticketing system I was writing with.

Quick shoutout

I just want to take a second to praise the woman from HR that made me aware of that issue. She found this suspicious (as it is), and asked whether this mail was trustworthy or not. Excellent! Though there are some deductions for asking by replying to the suspicious mail. If I was an evil hacker, I would probably have replied the same :D

Where to go from here

Sure, I could go full-on Don Quijote and fight the windmills that is the corporate IT landscape, but how willing they are to budge when a “lowly employee” comes along is probably best illustrated by the last security audit which mentioned (as I did hours after starting my job) that the current password expiration policy of 90 days is – at best – security theatre, but more realistically, actually leads to worse passwords to begin with. To this day, the password policy has not been changed and passwords of users are weak, posted to the frame of the screen, or sent via email. Sometimes multiple of these at once.

If you need a carreer path for high pay with a low skill level, consider making decisions in corporate IT. Apparently the requirements on professional knowledge are not too high.

Do you know better? Have a comment? Great! Let me know by sending an email to ~mpldr/public-inbox@lists.sr.ht

If you feel like it, you can , or .
Unless stated otherwise the texts of this website are released under CC-BY and code-snippets are released into the public domain.
© Moritz Poldrack