[conspire] (forw) Re: [Golugtech] Fw: [Alpine-info] O365 XOAUTH2 via fetchmail

[Rick Moen]

Quoting Alex Kleider (alexkleider at protonmail.com):

> https://myaccount.google.com/u/1/lesssecureapps?pli=1&rapt=AEjHL4MjjvQ_vFhfyNJA4L8D6F7Ebe23Pp8XOtkTzUpxd4mp5NhUHiFxACtGDaF0HkPzo03agudCrj5aMFoKkq3n4WtyaZZ9yQ&pageId=none

Not a complaint, but viewing that URL requires Google Account login.


> in the process of generating this email, I've discovered that as of
> May 22nd the ability to do ["lessecureapps" mode] will go away!  Don't
> know what I'll do after that.  Any suggestions??

Online, I find mention of May _30th_ as the cutoff date.
https://support.google.com/accounts/answer/6010255

I look forward to seeing what Akkana suggests.  Google's "exceptions to
verification requirements" documentation may be of interest.
https://support.google.com/cloud/answer/9110914#exceptions-ver-reqts&zippy=

For security purposes, GMail's data is considered within a "restricted
scope" (as opposed to a "sensitive scope" or the scope of "all apps") as
to the requirements imposed on "app requests".  Apps reaching into 
"restricted scope" data must meet all requirements for apps requesting
sensitive scopes, and also some additional requirements.  See prior URL
for details.

I tell you, Alex (and Akkana), this _sort_ of thing is rather difficult
to distinguish from the Googlers passive-aggressively saying "We'd
rather you not use your own code, and stick with Google's own hosted
proprietary software only".


I'm going to throw in, here, a story of how I was recently able to
eliminate a need for GMail, and how/why that made me happy:

Many years ago, I was running through and updating setup for my domains,
making very sure I was following my advice, and one of that bits of
advice is to observe the "out of band" principle.  That is, it would be
painfully ironic if nobody could contact me to say "Dude, there's a
problem with your domain" because of a problem with the domain.
Therefore, I made sure that at least one, preferrably two, or the three 
public domain contacts (Registrant = owner, Technical Contact, and
Administrative Contact) stated e-mail addresses both outside the domain
itself and handled solely by technical infrastructure outside mine.

For that, I fell back on the hallowed community principle of "You do
mine, and I'll gladly do yours":  Deirdre gave me a full mail login of
rick at deirdre.net, and I used that for Registrant and Technical Contact.

Years wore on.  Eventually, Deirdre changed providers to host her mail
at Fastmail, a meritorious for-pay hosted mail provider -- but with
the problem that rick at deirdre.net couldn't be (absent more money) a full
mail account, and had to be re-implemented as an /etc/alises -style mail
reflector.  As this was thrown together in impromptu fashion, I had
Deirdre point it at a GMail account.  

That worked, and I figured GMail would be good enough as an emergency
fallback -- but there was a hidden gotcha, that didn't bite me at the
time, but would later.  

More years wore on, to April 2022, and a friend who test-mailed to
rick at deirdre.net (now Fastmail-handled, and redirected to GMail) got an
SMTP 55x reject from GMail, which, fair cop, was correct because his
sending domain published an unequivocal SPF anti-forgery record in his
DNS, much like mine, saying "please reject mail purporting to be from
this domain unless it comes from one of the following authorised IPs."



Here's mine:

:r! dig -t txt linuxmafia.com. +short
"v=spf1 ip4:96.95.217.99 -all"

That's _very_ unambigous.  It says if the mail comes from anywhere but
IP 96.95.217.99 (mine), please reject it as forging my domain.


I should have spotted the pitfall:  /etc/aliases, ~/.forward, and
similar simple mail reflectors, have been obsoleted for cross-domain
mail reflection by SMTP antiforgery controls.

Fortunately, my friend handed me a solution by handing me an IMAP/SMTP 
account on his Linux server, so _that_ is now the new domain contact,
and I was able to jettison GMail.  

And it's really nice to be able to automate checking of that IMAP
mailbox, without having to outsource to any complicated Google Cloud,
Google Workspace, Google API, or other ridiculously baroque corporate 
proprietary crud.  All I needed was just a little tweak to my mutt
config.  Done.