[SERVER MAIL] mail in locale visualizzabili

[rinosan_76]

Salve a tutti. Oggi mi è venuta una paranoia... o almeno qualcosa di simile.
Io come tutti ormai ho il mio bel account di posta gmail e la mia compagna pure. Quindi 2 account per 2 persone che ovviamente non devono vedere le cose dell'altro.
Sarebbe possibile (e credo di si) realizzare un sistema che prenda ogni tot ore la nuova posta da quell'account e me la spedisca ad un mio server di posta locale così da avere io le copie della posta e non quelli in america?
In modo che poi vado a visionarmela in locale? Una cosa come il buon thunderbird ma che valga per piu account in modo che poi ognuno possa vedersi solo il suo con password etc etc
Grazie
Rino

[Lucio C]

Non capisco bene la terminologia.
Io fino a qualche anno fa ricevevo praticamente tutta la posta seria sull'account di lavoro, e poca altra sulla rete civica milanese. Allora il sistema mail di lavoro ce lo gestivamo noi con sendmail e spamassassin e la scelta era che la posta arrivava O su un server imap di istituto O sulla macchina individuale della persona. Il mio cliente e-mail era (ed e') alpine, che pui' leggere sia posta locale, che da un server imap, che da un server pop (come quello della rete civica).
Il vantaggio (per me) della mia soluzione era che tutta la posta stava sulla mia macchina, e che potevo usare un tot di filtri procmail per smistare la posta in arrivo. L'apparente svantaggio era che tale posta non era accessibile dall'esterno (in realta' a questo ovviavo in caso di vacanze o missioni lunghe attivando un server imap sulla mia macchina).
Quando a livello di ente siamo passati a Gsuite (versione commerciale di gmail) io ho voluto mantenere tutto quanto sopra. Per cui non accedo ordinariamente via imap al server google dal mio client, ma uso fetchmail che lo fa. fetchmail gira da crontab, nel mio caso ogni 5 minuti per l'account Gsuite, e ogni qualche ora per l'account di rete civica. Per cui tutta la posta continua a arrivare sulla mia macchina (di lavoro). Nel caso che non voglia aspettare i 5 min posso accedere direttamente via imap. ggi Inoltre a causa di una quirk nella (non) interpretazione degli standard da parte di google, i messaggi fetchati non sono fisicamente cancellati dal server google, ma spostati in Bin. Una volta al giorno mi collego via imap, verfico lo spam e ripulisco (espungo) Bin.

Quindi si', fetchmail puo' fare quanto chiesto ... pero' in futuro ci potrebbero essere delle difficolta' di autenticazione con oauth2 (google mette i bastoni tra le ruote a chi non usa i loro clienti). Quelli di fetchmail ci stanno lavorando.

Ho della documentazione di tutti gli arrangiamenti, ma in inglese. Se interessasse passo gli URL.
Pero' tutto cio' lo ho fatto al lavoro su Suse. A casa non ho ancora configurato nulla su Ubuntu (ho un postfix solo locale), per ora tutta la posta la gestisco in ssh sulla macchina di lavoro.

[korda]

Credo che @rinosan_76 voglia semplicemente scaricare le mail sul suo client senza lasciarne copia sul server.

In teoria basterebbe configurare il client ad usare il server POP3 anziché il server IMAP. Dopodiché, se dovessi disgraziatamente perdere quello che hai in locale sono razzi tuoi però.

Per quanto riguarda Oauth2.0 lo switch definitivo sarà molto prossimo, tra meno di due mesi. Questo per quanto riguarda gli account privati, non so come funzioni per i profili business (ad esempio Office365 non lo usano ancora, nella configurazione di base dei tenant).

Credo che il problema Oauth2.0 comunque non ti riguardi se, da quanto ho letto, usi client avanzati ad interfaccia grafica come Thunderbird. Se preferisci invece la shell mail agent come msmtp dovrebbero già implementare Oauth2.0, io ho scelto un'alternativa usando Python e direttamente le API di Google. Grazie all'aiuto di @rai, che colgo l'occasione di ringraziare nuovamente.

[frapox]

Salve a tutti. Oggi mi è venuta una paranoia... o almeno qualcosa di simile.
Io come tutti ormai ho il mio bel account di posta gmail e la mia compagna pure. Quindi 2 account per 2 persone che ovviamente non devono vedere le cose dell'altro.
Sarebbe possibile (e credo di si) realizzare un sistema che prenda ogni tot ore la nuova posta da quell'account e me la spedisca ad un mio server di posta locale così da avere io le copie della posta e non quelli in america?
In modo che poi vado a visionarmela in locale? Una cosa come il buon thunderbird ma che valga per piu account in modo che poi ognuno possa vedersi solo il suo con password etc etc
Grazie
Rino

Prova a vedere se fetchmail fa al caso tuo:
https://www.fetchmail.info/
https://en.wikipedia.org/wiki/Fetchmail

[Alien321]

Quindi si', fetchmail puo' fare quanto chiesto ... pero' in futuro ci potrebbero essere delle difficolta' di autenticazione con oauth2 (google mette i bastoni tra le ruote a chi non usa i loro clienti). Quelli di fetchmail ci stanno lavorando.

A be solo perché si vuole passare a uno standard diverso, che è STANDARD allora è "mettere il bastone tra le ruote" mi sembra ridicolo, è compito di
fetchmail adattarsi a nuovi standard se non lo fanno non è colpa di google.

[Lucio C]

A be solo perché si vuole passare a uno standard diverso, che è STANDARD allora è "mettere il bastone tra le ruote" mi sembra ridicolo, è compito di
fetchmail adattarsi a nuovi standard se non lo fanno non è colpa di google.

OT ma suggerirei di studiare la storia degli ultimi 20-30 anni ca. dell'IETF, degli RFC, di X11, di TCP-IP, ecc. e di frequentare i forum e le mailing list dei tool che rispettano gli standard ufficiali (come p.es. il browser Pale Moon, il mail client Alpine) per capire la differenza tra uno standard concordato di interoperabilita' o un draft standard permanentemente in draft imposti (surretiziamente) da una posizione dominante (una cosa un po' diversa dallo spirito FOSS e Linux).

[frapox]

A be solo perché si vuole passare a uno standard diverso, che è STANDARD allora è "mettere il bastone tra le ruote" mi sembra ridicolo, è compito di
fetchmail adattarsi a nuovi standard se non lo fanno non è colpa di google.

OT ma suggerirei di studiare la storia degli ultimi 20-30 anni ca. dell'IETF, degli RFC, di X11, di TCP-IP, ecc. e di frequentare i forum e le mailing list dei tool che rispettano gli standard ufficiali (come p.es. il browser Pale Moon, il mail client Alpine) per capire la differenza tra uno standard concordato di interoperabilita' o un draft standard permanentemente in draft imposti (surretiziamente) da una posizione dominante (una cosa un po' diversa dallo spirito FOSS e Linux).

Oauth2 è descritto in una RFC dell'IETF, Microsoft è il proponente mi sa (non Google). È stato "imposto surrettizialmente" all'IETF?

Ma sta cosa che Google dev'essere sempre il Male però ha anche un po' stancato, no?

[Alien321]

A be solo perché si vuole passare a uno standard diverso, che è STANDARD allora è "mettere il bastone tra le ruote" mi sembra ridicolo, è compito di
fetchmail adattarsi a nuovi standard se non lo fanno non è colpa di google.

OT ma suggerirei di studiare la storia degli ultimi 20-30 anni ca. dell'IETF, degli RFC, di X11, di TCP-IP, ecc. e di frequentare i forum e le mailing list dei tool che rispettano gli standard ufficiali (come p.es. il browser Pale Moon, il mail client Alpine) per capire la differenza tra uno standard concordato di interoperabilita' o un draft standard permanentemente in draft imposti (surretiziamente) da una posizione dominante (una cosa un po' diversa dallo spirito FOSS e Linux).

Non sarei dovuto a risponderti a tono ma non mi passa...

1) Uso Linux da 30 anni, prima distribuzione Slackware, quindi io non ho letto la storia, l'ho vissuta !!!!
2) Sono sistemista professionista, ci mangio con quello che faccio
3) Di cercare sui forum i gossip su chi ha obbligato chi a a fare cose non me ne frega nulla, dopo le palle con systemd ne ho avuto abbastanza

Detto questo ripeto, È uno STANDARD? La risposta è SI!

Poi al limite possiamo discutere se è un uno standard buono o cattivo, o cosa più importante se è semplice o complesso.

[korda]

A be solo perché si vuole passare a uno standard diverso, che è STANDARD allora è "mettere il bastone tra le ruote" mi sembra ridicolo, è compito di
fetchmail adattarsi a nuovi standard se non lo fanno non è colpa di google.

OT ma suggerirei di studiare la storia degli ultimi 20-30 anni ca. dell'IETF, degli RFC, di X11, di TCP-IP, ecc. e di frequentare i forum e le mailing list dei tool che rispettano gli standard ufficiali (come p.es. il browser Pale Moon, il mail client Alpine) per capire la differenza tra uno standard concordato di interoperabilita' o un draft standard permanentemente in draft imposti (surretiziamente) da una posizione dominante (una cosa un po' diversa dallo spirito FOSS e Linux).

Oauth2 è descritto in una RFC dell'IETF, Microsoft è il proponente mi sa (non Google). È stato "imposto surrettizialmente" all'IETF?

Ma sta cosa che Google dev'essere sempre il Male però ha anche un po' stancato, no?

Può darsi che Microsoft sia il proponente, ma io gestisco tranquillamente le mail di Office365 alla vecchia maniera* ancora, senza OAuth2.0. Solo SMTP e IMAP, con ovviamente SSL/TLS 1.2.

E dal centro o365 non mi è ancora pervenuto alcun ultimatum, a differenza di Gmail.

...ma forse perché con i profili business ci si va un po' più graduali, prima di stravolgere le cose (l'esperienza di Gmail è sul privato retail)

Che poi "stravolgere" è una parola grossa. Ormai buona parte dei client è al passo da tempi, e chi non si è adeguato può benissimo venire relegato nell'obsolescenza del legacy. Qualche fastidio in più sicuramente per le soluzioni headless, ma non mi sembra nulla di così trascendentale.

*: ovviamente le mail ordinarie le gestisco con Outlook, mi riferisco alla configurazione del logsender di cui ho chiesto lumi, e risolto, in altro 3d

[Alien321]

Può darsi che Microsoft sia il proponente, ma io gestisco tranquillamente le mail di Office365 alla vecchia maniera* ancora, senza OAuth2.0. Solo SMTP e IMAP, con ovviamente SSL/TLS 1.2.

E dal centro o365 non mi è ancora pervenuto alcun ultimatum, a differenza di Gmail.

Se abiliti l'autenticazione a 2 fattore è obbligatorio OAuth2 altrimenti puoi farne a meno. Questo sui profili office365, se usi il profilo gratuito allora OAuth2 penso sia
diventato obbligatorio

[korda]

Può darsi che Microsoft sia il proponente, ma io gestisco tranquillamente le mail di Office365 alla vecchia maniera* ancora, senza OAuth2.0. Solo SMTP e IMAP, con ovviamente SSL/TLS 1.2.

E dal centro o365 non mi è ancora pervenuto alcun ultimatum, a differenza di Gmail.

Se abiliti l'autenticazione a 2 fattore è obbligatorio OAuth2 altrimenti puoi farne a meno. Questo sui profili office365, se usi il profilo gratuito allora OAuth2 penso sia
diventato obbligatorio

...ma forse perché con i profili business ci si va un po' più graduali, prima di stravolgere le cose (l'esperienza di Gmail è sul privato retail)

Certo. Volendo si può anche richiedere esplicitamente l'OTP ad ogni accesso invece che una sola volta. Oltre a questo qui da noi o365 è configurato in modo tale che, se vuoi usare la app Outlook su Android, sei costretto a cambiare il metodo di sblocco del telefono (il gesto non è ammesso). Oppure ancora puoi aggiungerci certificati.

Non so se anche sui profili aziendali Google sia facoltativo a tempo indeterminato. Non ne uso più uno da anni

[rinosan_76]

Non capisco bene la terminologia.
Io fino a qualche anno fa ricevevo praticamente tutta la posta seria sull'account di lavoro, e poca altra sulla rete civica milanese. Allora il sistema mail di lavoro ce lo gestivamo noi con sendmail e spamassassin e la scelta era che la posta arrivava O su un server imap di istituto O sulla macchina individuale della persona. Il mio cliente e-mail era (ed e') alpine, che pui' leggere sia posta locale, che da un server imap, che da un server pop (come quello della rete civica).
Il vantaggio (per me) della mia soluzione era che tutta la posta stava sulla mia macchina, e che potevo usare un tot di filtri procmail per smistare la posta in arrivo. L'apparente svantaggio era che tale posta non era accessibile dall'esterno (in realta' a questo ovviavo in caso di vacanze o missioni lunghe attivando un server imap sulla mia macchina).
Quando a livello di ente siamo passati a Gsuite (versione commerciale di gmail) io ho voluto mantenere tutto quanto sopra. Per cui non accedo ordinariamente via imap al server google dal mio client, ma uso fetchmail che lo fa. fetchmail gira da crontab, nel mio caso ogni 5 minuti per l'account Gsuite, e ogni qualche ora per l'account di rete civica. Per cui tutta la posta continua a arrivare sulla mia macchina (di lavoro). Nel caso che non voglia aspettare i 5 min posso accedere direttamente via imap. ggi Inoltre a causa di una quirk nella (non) interpretazione degli standard da parte di google, i messaggi fetchati non sono fisicamente cancellati dal server google, ma spostati in Bin. Una volta al giorno mi collego via imap, verfico lo spam e ripulisco (espungo) Bin.

Quindi si', fetchmail puo' fare quanto chiesto ... pero' in futuro ci potrebbero essere delle difficolta' di autenticazione con oauth2 (google mette i bastoni tra le ruote a chi non usa i loro clienti). Quelli di fetchmail ci stanno lavorando.

Ho della documentazione di tutti gli arrangiamenti, ma in inglese. Se interessasse passo gli URL.
Pero' tutto cio' lo ho fatto al lavoro su Suse. A casa non ho ancora configurato nulla su Ubuntu (ho un postfix solo locale), per ora tutta la posta la gestisco in ssh sulla macchina di lavoro.

Beh se passi 2 link io una lettura me la do... inizio ad essere stufo di alcune situazioni... ma ci sta che un giorno di questo vado a farmi direttamente un server di posta mio a casa... anche solo per gioco... così imparo qualcosa.
Grazie
Rino