mailctl --> oama (OAuth Manager)

[pdobsan]

Summary

mailctl is undergoing a fundamental rewrite and will be transformed into a
new utility called oama standing for OAuth Manager.
It will be simpler, better, etc. -- I hope :-)

(Oama is also a name of a Hawaiian fish.)

History

mailctl originated from a shell script with same name I used to glue
together and control the components of my email system. These components
were mutt, msmtp, fdm, crontab and pass. The script worked fine
with my setup for quite a while. I should note that I have been using
several email accounts for various purposes.

When the need for dealing with OAuth2 credentials for my gmail account arose
and I could not find an additional component to deal with OAuth for my
liking I decided to replace the script with a utility of my own. So a new
application written in Haskell was born. The application provided everything
what the old script did plus also solved the OAuth problem for the other
components.

The new mailctl program was more or less like my old script with some
additional functionality. It worked but in fact was an inconsistent mess
with numerous external dependencies. It completely went against the (Unix)
design philosophy of solving one definite problem well while avoiding
coupling and leaving not related problems to other tools. Who says that you
cannot write hard to maintain spaghetti code in Haskell.

On top of that dealing with OAuth turned out to be more difficult than I
anticipated. Service providers make it hard: no standard followed, no proper
documentation, implementations keep subtly changing, no compatibility just
go for the vendor lock-in.

Going public

When I made the program public and people started using it the design and
implementation shortcomings surfaced quickly. It also became clear that most
people wanted to use it differently from the way I used it. I guess most
users use mainly the OAuth component and even if they use some of the other
functionalities they are not always a perfect fit for them or wanted to use
something else.

As bug reports and new feature requests were coming in the maintenance has
been becoming increasingly difficult and frustrating. The time has arrived
for a rewrite.

The new program: oama

The essence of the redesign is stripping away every functionalities and
external (tool) dependencies which are not directly related to dealing with
OAuth credentials.

Here is the outline of the main goals.

Available commands left:

  access        Get the access token (with automatic renewal)
  renew         Renew the access token
  authorize     Authorize OAuth2 for service/email

Backends:

- gpg encrypted files
- gnome keyring
(- age encrypted files  -- considered)

Reduce configuration as much as reasonable:

- select a backend: keyring or gpg
    (no argument details)
- specify services:
    - provider
    - client_id
    - cleint_secret
    hide the rest, if possible

Gradually improve the authorization process, in particular for company
accounts.

Provide completely static binaries at least for Linux x86_64 and
aarch64 architectures.

It is obvious that the new program won't be a controller of some mail
system only a utility to deal with OAuth credentials. That's why the new
name is OAuth Manager (oama).

Comments are welcome, just don't ask me to keep the old mailctl ;-)

[ferdinandyb]

It would be nice if oama also had a transparent way of getting the refresh token. Stuff like access -r returning the refresh token instead of the access token and authorize -o not writing it to disk but instead to STDOUT. It might be handy for other software, that can use a refresh token but do not support authorization (looking at you aerc).

[pdobsan]

It would be nice if oama also had a transparent way of getting the refresh token. Stuff like access -r returning the refresh token instead of the access token and authorize -o not writing it to disk but instead to STDOUT.

I suppose that can be done. Printing the already stored refresh token on stdout is easy. Printing the refresh token at the end of the authorization without storing it can also be an option but that would mean the user needs to copy/paste it from the terminal.

[dkwo]

This is great news.
I'd really appreciate supporting age as an alternative, as well as completely static binaries for both aarch64 and x86_64.

[pdobsan]

It would be nice if oama also had a transparent way of getting the refresh token.

See the new show <email> command in release 0.11.1