IBM Websphere Portal 8.5 ed i rule based group

Devo dire che una delle cose meglio fatte di IBM Websphere Portal Server è la sicurezza. In realtà la sicurezza è configurata sull’IBM Websphere Application Server che lo ospita perciò è facile configurare repository sia di tipo LDAP che Active Directory.

Una funzione molto comoda è quella di configurare dei gruppi che abbiano a loro interno degli utenti pescati da una query LDAP.
In sostanza, nel gruppo non si aggiungono gli utenti normalmente ma si crea un gruppo diciamo “smart” che al suo interno contiene tutti gli utenti che soddisfano una determinata query LDAP, ad esempio del tipo:

1
(city=Rome)

La prima cosa da fare è creare una tabella che ospiterà i rule-based group. In questo esempio userò il DB2 come database di backend. Poi, siccome sono molto old school, userò DB2 CLI come client ma la stessa cosa può essere fatta con qualsiasi client di connessione ai database.

1
2
3
4
db2 "create database WPVMM"
db2 connect to WPVMM
db2 "CREATE TABLE SOFTGROUPS (ID INT NOT NULL GENERATED ALWAYS AS IDENTITY, GROUPNAME VARCHAR(128) NOT NULL, RULE VARCHAR(300) NOT NULL, DESCRIPTION VARCHAR(512), LASTMODIFIED TIMESTAMP, PRIMARY KEY (ID), UNIQUE (GROUPNAME))"
db2 "CREATE INDEX SOFTGROUPSIX1 ON SOFTGROUPS (LASTMODIFIED DESC);"

Va prima creato il database e poi la tabella che ospiterà i gruppi.
Come nome database ho scelto VPVMM ma il nome può essere qualsiasi. Come nome tabella ho usato SOFTGROUPS perché è lo stesso usato nella documentazione IBM e non avevo nessun problema ad usarlo.

La cosa da fare lato IBM Websphere Application Server ora, è configurare una risorsa JNDI che contenga la connessione al DB, ammettiamo che la nostra si chiami: wpvmmdbDS

Ammettiamo di avere il profilo del portale installato nel seguente path: /opt/IBM/WebSphere/wp_profile.
Andiamo ora a creare il Custom User Registry all’interno di Websphere usando lo script ConfigEngine.

1
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-create-cur -DWasPassword=<admin password> -Dfederated.cur.id=SoftGroups -Dfederated.cur.adapterClassName=com.ibm.wps.vmm.adapter.softgroups.SoftgroupsAdapter -Dfederated.cur.baseDN=o=softgroups

Potete lasciare tutto così com’è, va solo impostata la password di amministratore di WAS.

Useremo ora lo script ConfigEngine per configurare l’adapter appena creato.

1
2
3
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-create-cur-custom-property -DWasPassword=<admin password> -Dcur.id=SoftGroups -Dcur.name=dataSource -Dcur.value=jdbc/wpvmmdbDS
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-create-cur-custom-property -DWasPassword=<admin password> -Dcur.id=SoftGroups -Dcur.name=dbSchema -Dcur.value=DB2INST1
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-create-cur-custom-property -DWasPassword=<admin password> -Dcur.id=SoftGroups -Dcur.name=dbType -Dcur.value=

Nel campo WasPassword va inserita la password di amministratore di WAS. Come value del datasource va inserito il JNDI name, non il nome della connessione.
Come schema del database ho lasciato DB2INST1 perché è lo schema che si usa di default quando si installa DB2 ma lì ovviamente dovrete inserire il vostro schema.
Nel caso di DB2 il db type deve essere lasciato vuoto, se invece avete un database MS SQL dovrete inserire mssql come valore.

Ora c’è bisogno di indicare all’adapter qual’è la connessione verso il sistema di directory, Active Directory o LDAP.

1
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-update-group-repository-relationship -DWasPassword=<admin password> -Drepository.id=<id connessione LDAP/AD> -Drepository.forgroups=SoftGroups

In questo comando vanno rimpiazzati la password di amministratore e l’id della connessione LDAP o Active Directory già configurata su Websphere Application Server.

Ultimo step, dobbiamo configurare WIM per utilizzare i gruppi rule-based. Editiamo il seguente file: /opt/IBM/WebSphere/wp_profile/config/cells/<nome cella>/wim/model/wimxmlextension.xml ed inseriamo all’interno del tag schema il seguente blocco:

1
2
3
4
5
<wim:propertySchema nsURI="http://www.ibm.com/websphere/wim" dataType="String"
multiValued="false"
propertyName="rule">
<wim:applicableEntityTypeNames>Group</wim:applicableEntityTypeNames>
</wim:propertySchema>

Inserire i gruppi rule-based
Al momento attuale non sono riuscito a trovare un modo user friendly di inserire i gruppi rule-based perciò ho provveduto ad inserirli via insert secca da client DB.

1
2
db2 connect to WPVMM
db2 "insert into SOFTGROUPS (GROUPNAME, RULE, DESCRIPTION, LASTMODIFIED) values ('MyGroupByCity', '(city=Rome)', 'All people from Rome', TIMESTAMP_FORMAT('2017-12-19 15:49:59', 'YYYY-MM-DD HH24:MI:SS'))"

Ora riavviate IBM Websphere Portal e andate nell’interfaccia di amministrazione. Cliccate su “Users and groups” e cercate il gruppo appena creato, se tutto è andato bene vedrete che il gruppo contiene tutti gli utenti che soddisfano la queri LDAP inserita nel record della tabella SOFTGROUPS.

UPDATE: 29.12.2017
Nel peggiore dei modi ho notato che la procedura sopra illustrata (nello specifico il comando ConfigEngine wp-create-cur) va liscia su un ambiente con un nodo solo (ovvero con deploy manager e nodo sulla stessa macchina), su un cluster può dare il seguente errore:

1
Caused by: com.ibm.websphere.wim.exception.WIMConfigurationException: CWWIM5019E Adapter class name is missing or is not valid: com.ibm.wps.vmm.adapter.softgroups.SoftgroupsAdapter.

Dopo aver tirato giù tutto il presepe siamo riusciti a capire che il comando, anche se lanciato su un nodo del portale, viene poi eseguito sul deploy manager che manca di un JAR fondamentale.
Per ovviare a questo andate sul nodo del cluster e copiate il seguente jar:

1
/opt/IBM/WebSphere/AppServer/lib/wp.user.connections.jar/wp.user.connections.jar

dentro la cartella “/opt/IBM/WebSphere/AppServer/lib/“ del deploy manager.
Riavviate il deploy manager, rilanciate il comando ConfigEngine wp-create-cur ed ora dovrebbe andare bene.

Documentazione ufficiale IBM: https://www.ibm.com/support/knowledgecenter/en/SSYJ99_8.5.0/admin-system/rbug.html

Cambiare la data di creazione ad un file word

Qualche giorno fa mi è stato chiesto di cambiare la data di creazione ad un file word, nello specifico docx, perciò scrivo qui la procedura nel caso possa servire a qualcuno. La procedura è spiegata su GNU/Linux ma su Windows è praticamente identica.
I file docx, sostanzialmente, sono dei file zip, perciò rinominiamo il file da “.docx” a “.zip”, nel caso la vostra utility di decompressione non sia così intelligente da non fare obiezioni.

1
mv file_word.docx file_word.zip

Creiamo una cartella che ospiterà il file dezippato e posizioniamoci al suo interno:

1
2
mkdir documento
cd documento

Decomprimiamo qui dentro il file word:

1
2
cd documento
unzip ../file_word.zip

La gerarchia dei file decompressi dovrebbe essere la seguente (o similare):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Archive: file_word.zip
Length Date Time Name
--------- ---------- ----- ----
1605 1980-01-01 00:00 [Content_Types].xml
590 1980-01-01 00:00 _rels/.rels
1218 1980-01-01 00:00 word/_rels/document.xml.rels
12470 1980-01-01 00:00 word/document.xml
69582 1980-01-01 00:00 word/media/image1.png
7078 1980-01-01 00:00 word/theme/theme1.xml
2239 1980-01-01 00:00 word/settings.xml
1451 1980-01-01 00:00 word/fontTable.xml
16888 1980-01-01 00:00 word/styles.xml
17641 1980-01-01 00:00 word/stylesWithEffects.xml
714 1980-01-01 00:00 docProps/app.xml
751 1980-01-01 00:00 docProps/core.xml
428 1980-01-01 00:00 word/webSettings.xml
7137 1980-01-01 00:00 word/numbering.xml
--------- -------
139792 14 files

Ora, non c’è bisogno che vi dica che nei file XML potete cambiare quello che volete, però per cambiare la data di creazione dobbiamo andare nella cartella docProps:

1
cd docProps

ora editiamo il file core.xml

1
vi core.xml

in questo file troviamo i tag “dcterms:created” e “dcterms:modified” che sono rispettivamente la data di creazione e la data di modifica. Modificate le date che vi interessano in formato ISO 8601 combined UTC (’YYYY-MM- DDThh:mm:ssZ’) e salvate il file.
Sempre da dentro la cartella documento ricomprimiamo il file:

1
zip -r file_word.docx *

Il file ’fileword.docx’ ora sarà identico al file originale ma con la data di creazione e/o la data di modifica aggiornate.

Configurare una mail di iCloud su Android

Non è raro vedere qualcuno che passa da iPhone ad Android, ma per la mail iCloud come si fa? Finché si passa da Android a iPhone non c’è problema perché l’account Google è perfettamente supportato su iOS ma quando si fa il contrario diventa un problema. Senza scaricare app di terze parti a cui dovremmo molto poco simpaticamente dare i nostri dati di accesso di iCloud, vediamo come poter configurare la mail di iCloud tramite IMAP sul client standard del telefono.

Via con la configurazione

Aprite il client desiderato su Android, andate nelle impostazioni e scegliete di configurare un nuovo indirizzo di posta, scegliete IMAP come tipo. Nei campi della configurazione inserite i seguenti valori:

  • Server IMAP: imap.mail.me.com
  • Username: <nome utente>@icloud.com
  • Password: <la vostra password di iCloud>
  • Sicurezza: SSL
  • Porta: 993

se andate avanti nella configurazione sarà il momento di configurare il server SMTP, inserite i seguenti valori:

  • Server SMTP: smtp.mail.me.com
  • Username: <nome utente>@icloud.com
  • Password: <la vostra password di iCloud>
  • Sicurezza: TLS
  • Porta: 587

Terminate la configurazione, date un nome alla connessione e dovrebbe cominciare fin da subito a sincronizzare la posta elettronica.

A cialtrone, a me da un errore di autenticazione errata!

Può capitare, soprattutto se avete la two-step authentication abilitata. Se è questo il caso fate così.
Andate all’indirizzo https://appleid.apple.com/it/, cliccate sul pulsante “Gestisci il tuo ID Apple”, fate login e vi troverete nelle impostazioni del vostro account.
Cliccate sulla voce “Password e sicurezza”. Sotto la voce “Genera una password specifica per l’app” cliccate sul link “Genera una password specifica per l’app”. Vi chiederà di nominare l’app per cui state generando la password, dategli un nome e cliccate su avanti. A questo punto vi mostrerà una password nuova di zecca che potrete utilizzare. Inserite questa nuova password come password della vostra configurazione, al posto di quella dell’account e dovrebbe funzionare tutto.

Un mail server fatto in casa

Avere le email su servizi pubblici è si comodo, per via del fatto che possiamo connetterci alla loro webmail sempre e comunque, ma non è sicuro in quanto le nostre email risiedono su server di “sconosciuti” presso i quali lavorano “sconosciuti” che hanno il potere di leggere le email altrui avendo i diritti di amministratori.
In questo documento spiegherò come mettere in piedi un infrastruttura per ricevere posta a casa ma la posta non arriverà direttamente al nostro server, bensì verrà spedita a Gmail ed il nostro sistema la preleverà da li, cancellandola dal server, per renderla disponibile a casa nostra.
Ho eseguito l’installazione su un sistema Ubuntu Server, perciò penso che le istruzioni per Debian siano simili.
Ovviamente il tutto necessita che si lasci la macchina accesa sempre, o quando se ne ha bisogno, però attualmente ci sono delle ottime soluzioni, prima su tutte il Raspberry PI che permettono di avere un vero e proprio computer in uno spazio ridotto, a basso costo e silenzioso.

Gli ingredienti

Un account Dyn DNS. In realtà funzionerebbe anche inserendo l’IP a mano ma spesso i provider telefonici applicano una tariffa maggiorata per chi richiede l’IP fisso perciò vediamo di evitare questa inutile spesa. Fetchmail. Fetchmail è un programma gratuito ed open source per il reperimento delle email. In poche parole si occupa di scaricare la posta da un server tramite i protocolli conosciuti (POP3, IMAP etc. . . ) e salvarla da qualche parte, tipo il nostro account su Linux oppure passarla ad un altro programma. Procmail. Procmail è un altro programma gratuito ed open source che si occupa di processare la posta, volendo la può smistare in cartelle, mandarla ad un altro indirizzo email (forwarding) passarla ad un altro programma ancora e così via. Spamassassin. Lo avrete capito dal nome, spamassassin è un altro programma gratuito ed open source che si occupa di controllare il contenuto e la provenienza delle email e, tramite varie regole, magie ed incantesimi vari, riesce a marcare come spam la posta che lui ritiene tale aggiungendo headers appositi alle email. Dovecot. Dovecot è un programma server di email (indovinate un po’? Gratuito ed open source) che si occuperà di servirci le email. Lui si espone tramite i protocolli conosciuti, IMAP nel nostro caso e noi potremo connetterci a lui con un client di posta e controllare la posta.

Vai con l’impasto!

Salto la parte dell’account su Dyn DNS, mettiamo che abbiate registrato un DNS chiamato mymailserver.dyndns.org.
Procediamo ad installare i componenti. Per prima cosa installiamo fetchmail. Si può installare usando i sistemi di pacchettizzazione delle distribuzioni Linux, ad esempio:
Debian (e derivati):

1
sudo apt-get install fetchmail

Fedora (e derivati):

1
sudo yum install fetchmail

Per tutti gli altri sistemi è possibile scaricare i sorgenti da Fetchmail e compilarlo seguendo le istruzioni, il classico

1
./configure && make && make install

Lasceremo per ora inconfigurato fetchmail e passeremo all’installazione di Procmail. La procedura è la stessa che per fetchmail:
Debian (e derivati):

1
sudo apt-get install procmail

Fedora (e derivati):

1
sudo yum install procmail

Per le altre distro potrete installare direttamente dai sorgenti scaricabili al sito Procmail.
Saltiamo anche la configurazione di procmail e andiamo a installare Spam
Assassin. La procedura è identica, anche questo è disponibile nei repository ufficiali:
Debian (e derivati):

1
sudo apt-get install spamassassin

Fedora (e derivati):

1
sudo yum install spamassassin

La configurazione di Spam Assassin la salterò del tutto perché è talmente variegata che vi rimando alla documentazione ufficiale e al download dei sorgenti nel caso abbiate bisogno o vogliate compilarlo da essi all’indirizzo https://spamassassin.apache.org. Sappiate comunque che la configurazione di base fa già un ottimo lavoro.
Per ultimo installiamo Dovecot. Anche questo disponibile sui repository ufficiali. Nel nostro caso installeremo la versione apposita per fornire il protocollo IMAP.
Debian (e derivati):

1
sudo apt-get install dovecot-imapd

Non utilizzando Fedora non sono riuscito a capire se esiste sui repository, per voi e per gli utilizzatori di distro in cui non sia presente nei repository, vi rimando ai sorgenti sul sito ufficiale Dovecot.

Abilitare su Google il prelievo in POP3

Gmail di default non supporta il download della posta tramite protocollo POP3, esso va abilitato. Andiamo nelle impostazioni di Gmail (di solito è il tastino con l’ingranaggio in alto a destra), selezioniamo “Settings”, clicchiamo sul tab “Forwarding and POP/IMAP”. Nella sezione “POP Download” selezioniamo “Enable POP for all mail”. Nel caso vogliate che le email vengano cancellate da Gmail una volta scaricate, nella sezione “When messages are accessed with POP” selezionate “delete Gmail’s copy”. Salvate e siamo a posto.

I certificati di Google

Ovviamente fetchmail storcerà il naso quando vedrà che stiamo prelevando la posta da un server di cui non possediamo il certificato, così ora andremo a scaricare i certificati di Google in una nostra cartella da passare poi a fetchmail. La seguente procedura la potete trovare descritta al seguente indirizzo:
http: //www.andrews-corner.org/mutt.html#ssl.

Andiamo ad eseguire i seguenti comandi:

1
mkdir -pv $HOME/.certs

In questo modo creiamo la cartella .certs nella nostra home la quale conterrà i certificati.

1
2
3
cd $HOME/.certs
touch Thawte_Premium_Server_CA.pem
touch Equifax_Secure_CA.pem

Ci siamo spostati nella cartella .certs e abbiamo creato i due file .pem vuoti.

1
2
wget --no-check-certificate https://github.com/bagder/curl/raw/master/lib/mk-ca-bundle.
perl mk-ca-bundle.pl

Abbiamo scaricato un bundle perl per la creazione dei certificati. Ora che abbiamo lanciato il file perl mk-ca-bundle.pl, esso avrà generato il file ca- bundle.crt nella cartella, questo è il pack dei certificati. Andiamo ad aprirlo con un qualsiasi editor di testo. In questo file troverete due blocchi di codice alieno contenuti tra le stringhe —–BEGIN CERTIFICATE—– e —–END CERTIFICATE—–. Il primo blocco lo troverete sotto il titolo Thawte Premium Server CA, copiatelo (comprensivo di —–BEGIN CERTIFICATE—– e —–END CERTIFICATE—–) dentro il file ThawtePremiumServerCA.pem. Prendete il secondo blocco di codice sotto il titolo Equifax Secure CA e copiatelo dentro il file EquifaxSecureCA.pem.
Ora lanciamo il comando

1
c_rehash $HOME/.certs/

e avremo i certificati belli e pronti per l’uso dentro la cartella .certs nella nostra home.

Vai con la cottura!

Dopo aver installato questa saccocciata di roba è arrivato il momento di configurare il tutto. Partiamo dal fondo, ovvero da Dovecot. A Dovecot basterà indicare la directory in cui salveremo la posta (per comodità sceglieremo il formato Maildir). Personalmente ho messo la cartella su un HD secondario, se avete uno di quei NAS che si collegano via USB3 o eSATA sarebbe ancora meglio. Perciò ammettiamo che vogliamo salvare la posta nella cartella del nostro hard disk ausiliario /mnt/MailHD/dovecot.
Apriamo il file 10-mail.conf che troviamo nel percorso /etc/dovecot/conf.d e cerchiamo la variabile maillocation, come valore inseriamo il nostro percorso appena scelto, la riga nel file avrà questo aspetto:

  • mail_location = maildir:/mnt/MailHD/dovecot/Maildir

Sostanzialmente gli stiamo dicendo che la posta sarà memorizzata in formato maildir nella cartella Maildir dentro la cartella che abbiamo scelto. Maildir sarà la cartella che conterrà l’architettura della cartella della posta in arrivo. Dovecot è già pronto, se lo avete installato dai repository del vostro sistema operativo sarà già configurato per partire all’avvio, in questo modo già vi fornisce la posta con protocollo IMAP.
Ora andiamo a configurare procmail, ovvero il software che si occuperà di infilare la posta di Gmail dentro a Dovecot. Creiamo un file chiamato .procmailrc dentro la home del nostro utente, il file avrà il seguente contenuto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
PATH=/usr/bin:/usr/local/bin
MAILDIR=/mnt/MailHD/dovecot/Maildir
DEFAULT=/mnt/MailHD/dovecot/Maildir
LOGFILE=/home/user/procmail.log
DELIVER="/usr/lib/dovecot/deliver"
SHELL=/bin/sh
:0fw: spamassassin.lock
* < 256000
| spamassassin
# All mail tagged as spam (eg. with a score higher than the set
# threshold)
# is moved to "probably-spam".
:0:
* ^X-Spam-Status: Yes
$MAILDIR/.INBOX.Spam/
:0 w
| $DELIVER

Vi spiego in breve cosa abbiamo scritto:
PATH = E’ il percorso dove si trova l’eseguibile
MAILDIR = La directory madre in formato Maildir relativa alla posta
DEFAULT = E’ la directory dove sarà memorizzata la posta, di solito si mette lo stesso percorso di MAILDIR
LOGFILE = Quale sarà il file di log, vi consiglio vivamente di inserire questa variabile così nel caso ci siano problemi potete facilmente investigarne la natura.
DELIVER = E’ un eseguibile opzionale, nel nostro caso vitale, che si occuperà di fare lo store delle email. Nel nostro caso è obbligatorio in quanto se mettessimo le email direttamente nella cartella di Dovecot, esso non aggiornerebbe il suo indice e non riusciremmo a farci restituire le email arrivate. In questo caso, deliver aggiorna l’indice e copia la mail nella directory Maildir.
SHELL = La shell dei comandi da utilizzare
Dopo il blocco delle variabili abbiamo le seguenti direttive.

1
2
3
:0fw: spamassassin.lock
* < 256000
| spamassassin

Queste tre righe passano qualsiasi mail arrivata a spamassassin che aggiungerà degli header alle email nel caso ritenga che siano spam.

1
2
3
:0:
* ^X-Spam-Status: Yes
$MAILDIR/.INBOX.Spam/

Questa parte fa si che tutte le email che Spamassassin ha marcato con l’header X-Spam-Status vengano spostate nella directory Spam.

1
2
:0 w
| $DELIVER

Quest’ultima parte passa tutte le email, processate e non, all’eseguibile deliver che si occuperà di inserirle in Dovecot.
Passiamo ora a configurare fetchmail, che si occuperà di prelevare la posta da Gmail. Creiamo un file dentro la home dell’utente chiamato .fetchmailrc.
Il file avrà il seguente contenuto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
set no bouncemail
set logfile /home/user/fetchmail.log
set daemon 90
poll pop.gmail.com
proto pop3
port 995
auth password
user ’username@gmail.com’ there
with password ’myPasswordOrMyGoogleApplicationsPassword’
options
nokeep
ssl
sslcertck
sslcertpath /home/user/.certs
mda "/usr/bin/procmail -f %F -d %T";

Le prime tre righe indicano semplicemente che le email errate non devono tornare al destinatario, il percorso al file di log e che fetchmail girerà in modalità demone ogni 90 secondi.
Le righe seguenti indicano che prenderemo la posta dal server pop.gmail.com usando il protocollo POP3 sulla porta 995 autenticandoci con la password. Lo username sarà il nostro indirizzo Gmail, la password sarà la nostra password Gmail ma se avete abilitato il 2-step-authentication dovrete inserire la password delle applicazioni che Google vi ha dato al momento che avete abilitato questo sistema, potete vederla nel vostro profilo Google.
Options indica che andremo ad indicare le opzioni sotto.
Nokeep indicherà che la posta non dovrà essere conservata sul server di Google.
Ssl, sslcertck e sslcertpath sarà il percorso in cui sono i certificati di Google.
L’ultima riga invoca il Mail Delivery Agent, nel nostro caso procmail che andrà a processare ogni email prelevata.

Il varo

Ok ora è tutto pronto, se avete installato tutto da repository dovrebbe essere tutto già in piedi e pronto a partire al boot del sistema. Se fetchmail non dovesse partire all’avvio, potete lanciarlo con il comando:

1
fetchmail -d 600

l’opzione -d indica che partirà in modalità demone (non sarà huppato alla console e cose del genere) e girerà ogni 600 secondi.
Ora dovrebbe cominciare a tirare giù la posta, ci mettera molto, ve lo dico subito. Controllate di frequente i log di Fetchmail e Procmail per vedere se ci sono errori particolari o se procede tutto spedito.

Apertura all’esterno e configurazione del client

Ora quello che vi rimane da fare è rendere disponibile il sistema dall’esterno. All’inizio del documento vi ho indicato dyndns. In soldoni, DynDns rende disponibile il vostro IP esterno di casa tramite un indirizzo umano, nel nostro caso ad esempio sarà mymailserver.dyndns.org (l’indirizzo lo scegliete al momento dell’apertura dell’account e della crazione di un nuovo servizio DNS). Alcuni router supportano l’account DynDns, basta inserire le credenziali e il router aggiornerà automaticamente DynDns con l’IP del momento. Per chi non ha un router che supporta questa configurazione non c’è problema, sono disponibili i tool di DynDns da installare sulla macchina che penseranno ad aggiornare automaticamente l’IP, potete scaricarli a questo indirizzo: http://dyn.com/support/clients/.
Ora dovete configurare il router per esporre il servizio IMAP dall’esterno. Per fare questo vi rimando alle istruzioni del vostro router, solo vi do un consiglio. La porta IMAP è la 143 ma non esponete direttamente la 143, configurate il PAT/NAT in modo che la porta esterna sia ad esempio la 5421 o una porta strana e poi rimappate internamente verso la 143.
Ora aprite il client di posta che volete usare e configurate il vostro account Gmail. Andate poi nelle impostazioni del server della posta in arrivo e cambiate i seguenti valori:
Server: mymailserver.dyndns.org (o qualsiasi indirizzo DynDns avete scelto)
Porta: 5421 (o la porta che avete aperto dall’esterno sul router)
Sicurezza: STARTTLS
Autenticazione: password
Come username e password inserite le credenziali del vostro utente Linux.
Come server di posta in uscita SMTP utilizzate quello di Google, lasciate quindi configurato così com’è.