Re: [Fetchmail-users] my solution to recent gmail issues

[graeme v. <gra...@ve...>]

Lucio,

This is also what I was forced to may years ago. Yes a password THEY set 
does not seem so secure (although I do agree with them simply have a 
password is less secure ...far better if they accepted *my* key)


ABTW, you also show as having a bad DKIM:

(Invalid SPF: Pass  DMARC None)


On 22/01/2024 15:39, Lucio Chiappetti wrote:
> I have recently received a message that I *SHALL* move to 2 Factor 
> Authentication in Gsuite, and, as I suspected, this broke my 
> arrangement (which exists sicne years and years) and I took my 
> counter-measures, and I wish to share.
>
> In a nutshell what I wanted to achieve and what I did is:
>
> (1) I want to have mail stored locally on my machine, and to have
>      incoming mails processed by procmail (this is not just for my fun,
>      I have a couple of cases where procmail post-processes mail from
>      forms to update a local database for service reasons).
>
> (2) The simplest way to feed incoming mails into procmail is to use
>     fetchmail, which I am happily using since 2018, when my institution
>     moved from howgrown sendmail to Gsuite
>
> (3) The simplest way to have fetchmail working (after I activated
>      2FA on Gsuite fetchmail was not authenticateds) is to "bypass" 
> Gmail,
>      i.e. instruct Gsuite to forward all mail to another provider which
>      provides *standard* IMAP.
>
>      This solves 98% of my problems, because
>
>      - Spam is not forwarded from Gmail to the alternate provider
>      - messages forwrded *and deleted* are not actually deleted
>        but staged in Gmail's Bin for 30 days
>
> (4)  The solution is ... "app passwords". Gmail with 2FA allows to
>      define a 16-char password THEY generate to be used with what in
>      the past were called provocatorily "less secure applications"
>
>      So I generated such an "app passwords" and I can use it from my
>      preferred mail client (Alpine). And this solves my problem.
>
> (5)  Actually the same app password can work also with fetchmail,
>      so in theory I would not need the alternate provider of point (3) 
> and
>      could work "as previously", but I left it in.
>
> I had no need to move to OAUTH2, or learn it, or get an OAUTH2-capable 
> version of fetchmail (I use the OS-bundled one).
>
> I think I could be happy with the new arrangement.
>
> I hope the above is useful to somebody else.
>