[TruHobbyist]

1. SSL/IMAP support. A lot of the older email clients only support pop which is kind of dated. SSL and TLS support are obviously quite necessary. 

Crucial

2. Multiple mailboxes. Doesn't necessarily have to be like Mozilla Thunderbird or anything but we should have the ability to switch between them pretty easily, IMHO. 

Crucial

3. Motif GUI. Judging by the hubbub that was around the Motif Netsurf and IRC clients I think this is pretty much a given for everybody.

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.

1. Should we support pop? I don't think there's any mail providers that really are around anymore that only support pop; but it might be preferred for people to use that and I just don't know. 

Last time I configured one of my desktop email clients (eM Client: https://www.emclient.com/, Win10), it still used POP by default. Since this was just a couple years ago and the client in question has a good reputation on the internet, I assume there is still some use of POP/POP3 out there.

2. Is displaying HTML messages important?

If going that path, CSS would need to be supported too. This would make the client way more useful but also restrict this usability to a GUI frontend.

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.

3. RSS feeds or other integrations like you see with Mozilla Thunderbird or other common email clients?

Personally, I don't use this one.

4. GNUPg integration?

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 

5. Attachments

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.

Architecture for an email client

I obtained the idea for this from looking at the architecture of the transmission torrent client. Suffice to say that client has a useful feature where it can have a daemon running in the background and you can have everything from a web, command line interface or a curses interface. 

In order to be pragmatic about the development of this email client I think that it would be necessary to start in stages: 

Stage 1: daemon and library for various frontends. A reference frontend in the form of a curses-based user interface for email. 

Stage 2: a prototype Motif interface in Motif Lua so that we can more easily adjust and adapt it to people's preferences. Basically we build a reference design out and then later on port it to C or Viewkit C++ if necessary.

Stage 3: a web-based front end if necessary so that you can access it from other machines but this might not be strictly necessary. 

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.