From: Matthias A. <mat...@gm...> - 2024-05-18 09:16:12
|
Am 15.05.24 um 21:01 schrieb Lucio Chiappetti: > On Mon, 13 May 2024, Matthias Andree wrote: > >> So then, app password access it will be. > > Yes, insofar it works. > > I do not really understand in what an app password is different from > any other password (though I never dared trying it with webmail > access, which I do extremely seldom). Lucio, The idea behind "app passwords" is that * they give only limited access for *one* particular service or sub-area of the entire suite of services of some larger offering. Like, you cannot log into your Google account, or Google Meet, or use this app password to change your global account password, etc. (That is assuming you keep your recovery e-mail address separate from a service you can access with this app password for email.) * they are not subject to two-factor authentication (2FA), so easier to set up for an application that cannot do 2FA or where trusted. > > I feel inclined IMVHO to thin[k] G*** itself is a PITA. Just yesterday > I added a cousin's address to a series of crontab for birthday wishes > (used since years), and it bounced because of an SPF error. Apparently > this was due to the fact mailx (the MUA used by crontab) issued a From > of the form us...@ma...main (while alpine uses user@domain which > passes SPF on the SMTP for the domain). A mailx -r cured it. For my own convenience, on my computers, I have added SPF workarounds such that I usually set up source-address-based routing to the SMTP submission server [mail.gmx.net]:submission, and authentication to my Postfix ages ago to overcome this SPF madness. |