[conspire] Third-party (IMAP4, SMTP, OAUTH2) code access to GMail

[Rick Moen]

Quoting Syeed Ali (syeedali at syeedali.com):

> Will you be updating your MUA list to note OATH2 support?
> http://linuxmafia.com/faq/Mail/muas.html

I'll admit I haven't checked, but there are these several things I
notice:

1.  Offhand, I'm doubting that even _one_ of those programs
supports the only known implementation of OAuth 2.0 in IMAP/SMTP
space, that implementation being Google's weird-ass "XOATH2" mechanism
that they frankensteined together.  To repeat, the normal and expected 
use-case for OAuth 2.0 authentication tokens is HTTPS.

2.  Even before that page started becoming a bit moldy from deferring of
the not-inconsiderable work of re-researching everything from time to
time (let's call that the middle 2000s), I'd already noticed and 'fessed
up to some problematic vagueness, which I annotated near the top:

  I must also admit to being sloppy in two details, below: "SMTP" merely
  means the program either does SMTP itself or can invoke (variously)
  local SMTP agents or remote ones (smarthosts), and "OpenPGP" encompasses
  legacy PGP support.  I am gradually correcting this imprecision.

(Well, I meant to.  It still needs doing.)  In my mind, I tend to assume
the old-school Unix mail scenario, where you're either at shell on the
MTA smarthost box (as I am), or the smarthost is accepting your outbound
SMTP mail on 25/tcp _without_ authentication because of one of the
traditional ways of recognising customers, e.g., you're on an IP known
to it or your IP recently auth'd your user identity to pull down a
bundle over IMAP/POP3.

But the world long ago got more complex, with a couple of different
"submission" ports for outbound mail, where unlike with 25/tcp the
concept of authentication's built into the port protocol.  See:
https://www.sparkpost.com/blog/what-smtp-port/   Also, there are now
numerous sorts of authentication for mail that are more sophisticated
and better than plain password auth.  And my page is silent about that,
because I was barely aware of that at the time, and didn't bother.

But, even at that, I doubt XOATH2 even rates as an authentication
method.  Unlike OAuth 2.0, it's not an IETF standard, and it exists only
one place, GMail.  But, if I see support for it around, maybe I'll take
notice.

3.  Like several other such pages I built in early years, its purpose
was in part to be pragmatically useful, but partly also just to make a
point: to show how extremely many alternatives we have.  However, as the
years have passed, I've learned there's a big catch:  graphics toolkits.
In short, version churn in those has (indirectly) killed many of the
graphical MUAs, and my page hasn't caught up.

Here's what I mean:  Consider "Balsa", which I listed as an excellent,
open-source, all-round mailer -- and called out a favourite.  As I 
say, it's based on "GTK+".  But that's imprecise.  It's actually
gtk-3.0.  So, as long as GTK[1]'s 3.0 branch keeps being maintained, 
Balsa will be fine, but contrast that with _another_ GTK+-based small
mailer I praised, pronto.  Near as I can tell without digging, the
version of GTK _it_ depends on is the original GTK+ 1.1 series of
libraries, not even GTK2.  And, apparently (I'm envisioning this,
anyway), when GTK2 replaced primordial GTK and the latter got quickly
abandoned, pronto's maintainer looked at the mountain of recoding work
he/she'd need to do, in order to catch up with GTK2, and said "The hell
with that; I'm done."  Thus, pronto's been a dead project since 2002.

And my list (other than noting the last-updated year) says nothing about
this matter.

So, in short, the page has issues that would take precedence over noting
XOAUTH2 support, were I working hard to update it -- and also I don't
know if what the protocol suggest would even be in any Linux MUAs or
mail delivery agents (things like fetchmail), anyway (because it's just
a one-off GMail thing).