[Raion]

I would add Qt as a GUI option. A relatively old Qt version with support for IRIX (C++98) and some multimedia support would ease this task and help in both UI and UX.

As an option maybe, but it'd have to be QT3 and below. As I said, there's lua bindings for Motif so ease of prototyping is there. I would want the flagship for this to be Motif for obvious reasons; QT has a nonnative UI, and it has issues with text shaping just like later GTKs do due to lack of GL support for antialiasing in either library.

If supporting only simple text, the client could still be used for private email exchange. In this case I would say all expected email functions should be implemented: attachments, reply, forward, carbon copy, et.al.

I'm leaning towards no HTML for the client for better curses support.

A lighweight email client with support for S/MIME and or PGP would be great! I would send my emails from now on encrypted just to brag about having sent them from IRIX 

Same!

I can imagine a user friendly interface for managing attachments, which is done horribly on any other email client/service I have encountered:

A combination of traditional UX and more modern interfaces like WhatsApp/Telegram/Signal, where the selection and filtering process of attachments is easy, straightforward and extremely fast.

This is how it would work:

Attachments are saved as objects in the client. Let's define these as an "AO" (Attachment Object). An AO can contain any number of attached files. So the client remembers in a chronologically sorted list, all AOs created and used in emails. By managing them independently of the emails, they can be easily reused: just pick the corresponding AO from the list.

Creation of an AO: Define the relevant logical environments to filter attachments from, in increasing order of size: single email, entire dialog, all emailS, whole client (<- this includes the local filesystem). Select attachments through checkbox, click "create" and your AO is ready to be used.

Filtering is done in any environment and can include filetype, name, size, date, ... . Technically every filter is just a for loop.

The problem I want to solve with this is to reduce the time of bundling together all required attachments from: local filesystems and email attachments spread across multiple different emails. This task is not easily solved, not even in GMail.

As long as the implementation of any FS ops doesn't use glib I'm ok with this idea. Glib is one bit I think deserves a slow painful death.

The latest developments on more exotic OSs like HP-UX or OpenVMS, are to access different administrative applications using a web interface. It's a very cheap and portable way of achieving interoperability.

Being able to access my email client running on IRIX using PuTTY or any web browser from any machine from the mid 90's up to today's PCs, is definitely a good idea.

My two cents.

Thank you for your input Tru.