mailx, gmail e certificati – Gabriele Merli

Spesso mi capita di dover usare mailx da riga di comando per inviare semplici mail di notifica, generalmente all’interno di uno script.

Il pacchetto mailx è questo (in centos 7)

]# yum info mailx<br /><br /> Installed Packages<br /><br /> Name : mailx<br /><br /> Arch : x86_64<br /><br /> Version : 12.5<br /><br /> Release : 12.el7_0<br /><br /> Size : 466 k<br /><br /> Repo : installed<br /><br /> From repo : updates<br /><br /> Summary : Enhanced implementation of the mailx command<br /><br /> URL : http://heirloom.sourceforge.net/mailx.html<br /><br /> License : BSD with advertising and MPLv1.1<br /><br /> Description : Mailx is an enhanced mail command, which provides the functionality<br /><br /> : of the POSIX mailx command, as well as SysV mail and Berkeley Mail<br /><br /> : (from which it is derived).<br /><br /> :<br /><br /> : Additionally to the POSIX features, mailx can work with Maildir/ e-mail<br /><br /> : storage format (as well as mailboxes), supports IMAP, POP3 and SMTP<br /><br /> : protocols (including over SSL) to operate with remote hosts, handles mime<br /><br /> : types and different charsets. There are a lot of other useful features,<br /><br /> : see mailx(1).<br /><br /> :<br /><br /> : And as its ancient analogues, mailx can be used as a mail script language,<br /><br /> : both for sending and receiving mail.<br /><br /> :<br /><br /> : Besides the “mailx” command, this package provides “mail” and “Mail”<br /><br /> : (which should be compatible with its predecessors from the mailx-8.x source),<br /><br /> : as well as “nail” (the initial name of this project).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

]# yum info mailx Installed Packages Name        : mailx Arch        : x86_64 Version     : 12.5 Release     : 12.el7_0 Size        : 466 k Repo        : installed From repo   : updates Summary     : Enhanced implementation of the mailx command URL         : http://heirloom.sourceforge.net/mailx.html License     : BSD with advertising and MPLv1.1 Description : Mailx is an enhanced mail command, which provides the functionality             : of the POSIX mailx command, as well as SysV mail and Berkeley Mail             : (from which it is derived).             :             : Additionally to the POSIX features, mailx can work with Maildir/ e–mail             : storage format (as well as mailboxes), supports IMAP, POP3 and SMTP             : protocols (including over SSL) to operate with remote hosts, handles mime             : types and different charsets. There are a lot of other useful features,             : see mailx(1).             :             : And as its ancient analogues, mailx can be used as a mail script language,             : both for sending and receiving mail.             :             : Besides the “mailx” command, this package provides “mail” and “Mail”             : (which should be compatible with its predecessors from the mailx–8.x source),             : as well as “nail” (the initial name of this project).

 

Utilizzando un mail server tipo postfix dall’interno di una rete in cui permetto il relay, per mandare un mail basta il comando:

]# mailx -v -s “Subject” -S smtp=smtp://mailserver.dominio.it -S from=”me@server(Gabriele Merli)” destination.mail@dominio.it

1	]# mailx -v -s “Subject” -S smtp=smtp://mailserver.dominio.it -S from=”me@server(Gabriele Merli)” destination.mail@dominio.it

Il soggetto sarà “Subject”, il server di posta utilizzato sarà mailserver.dominio.it, il mail del mittente è me@server con nome Gabriele Merli e il destinatario sarà destination.mail@dominio.it

Poi scrivo il testo, termino con un . e la mail viene inviata.

All’interno di uno script con body precompilato basta una cosa del tipo

]# echo “ciao” | mailx -v -s “Subject” -S smtp=smtp://mailserver.dominio.it -S from=”me@server(Gabriele Merli)” destination.mail@dominio.it

1	]# echo “ciao” | mailx -v -s “Subject” -S smtp=smtp://mailserver.dominio.it -S from=”me@server(Gabriele Merli)” destination.mail@dominio.it

ed il testo del messaggio sarà “ciao”.

---

Volendo usare GMAIL per inviare la stessa semplicissima mail la questione si complica leggermente.

Il comando da dare è questo:

echo “Un caro saluto” | mailx -v -s “Ciao Gabriele” -S smtp-auth=login -S smtp=smtps://smtp.gmail.com:465 -S from=”utente@gmail.com(Gabriele Merli – gmail)” -S smtp-auth-user=utente@gmail.com -S smtp-auth-password=lapassword -S ssl-verify=ignore -S nss-config-dir=~/certs2/ destination.mail@dominio.it

1

echo “Un caro saluto” | mailx –v –s “Ciao Gabriele” –S smtp–auth=login –S smtp=smtps://smtp.gmail.com:465 –S from=“utente@gmail.com(Gabriele Merli – gmail)” –S smtp–auth–user=utente@gmail.com –S smtp–auth–password=lapassword –S ssl–verify=ignore –S nss–config–dir=~/certs2/ destination.mail@dominio.it

I parametri in più servono per effettuare l’autenticazione in fase di invio via smtp e per connettersi al server via ssl.

Questa la man page di mailx riguardo ai parametri sopra indicati

ssl-verify<br /><br /> Sets the action to be performed if an error occurs during SSL/TLS server certificate validation. Valid values are `strict’ (fail and<br /><br /> close connection immediately), `ask’ (ask whether to continue on standard input), `warn’ (print a warning and continue), `ignore’ (do<br /><br /> not perform validation). The default is `ask’.

1 2 3 4

ssl–verify               Sets  the  action to be performed if an error occurs during SSL/TLS server certificate validation.  Valid values are `strict‘ (fail and               close connection immediately), `ask‘ (ask whether to continue on standard input), `warn’ (print a warning and continue),  `ignore‘  (do               not perform validation).  The default is `ask‘.

Nel mio caso ignoro gli errori di validazione del certificato ssl/tls (vedremo poi in seguito)

smtp-auth<br /><br /> Sets the SMTP authentication method. If set to `login’, or if unset and smtp-auth-user is set, AUTH LOGIN is used. If set to `cram-<br /><br /> md5′, AUTH CRAM-MD5 is used; if set to `plain’, AUTH PLAIN is used. Otherwise, no SMTP authentication is performed.

1 2 3

smtp–auth               Sets the SMTP authentication method.  If set to `login‘, or if unset and smtp–auth–user is set, AUTH LOGIN is used.  If set  to  `cram–               md5‘, AUTH CRAM-MD5 is used; if set to `plain’, AUTH PLAIN is used.  Otherwise, no SMTP authentication is performed.

L’autenticazione avviene tramite AUTH LOGIN passando poi username (generalmente l’indirizzo email @ gmail.com) e la password

nss-config-dir<br /><br /> A directory that contains the files certN.db to retrieve certificates, keyN.db to retrieve private keys, and secmod.db, where N is a digit.<br /><br /> These are usually taken from Mozilla installations, so an appropriate value might be `~/.mozilla/firefox/default.clm’. Mailx opens these<br /><br /> files read-only and does not modify them. However, if the files are modified by Mozilla while mailx is running, it will print a `Bad dataâ[m<br /><br /> base’ message. It may be necessary to create copies of these files that are exclusively used by mailx then. Only applicable if S/MIME and<br /><br /> SSL/TLS support is built using Network Security Services (NSS).

1 2 3 4 5 6

nss–config–dir               A directory that contains the files certN.db to retrieve certificates, keyN.db to retrieve private keys, and secmod.db, where N  is  a  digit.               These  are  usually  taken  from  Mozilla installations, so an appropriate value might be `~/.mozilla/firefox/default.clm‘.  Mailx opens these               files read–only and does not modify them.  However, if the files are modified by Mozilla while mailx is running, it will print  a  `Bad  dataâ[m               base‘  message.   It  may be necessary to create copies of these files that are exclusively used by mailx then.  Only applicable if S/MIME and               SSL/TLS support is built using Network Security Services (NSS).

La directory dove andiamo a memorizzare i certificati (vedremo poi in seguito), nel mio caso ~/certs

Volendo mandare mail utilizzando starttls e la porta 587 (quindi  primo collegamento in chiaro e poi si effettua la cifratura), il comando da dare è molto simile a quello visto precedentemente

echo “Un caro saluto” | mailx -v -s “Ciao Gabriele” -S smtp-use-starttls -S smtp-auth=login -S smtp=smtp://smtp.gmail.com:587 -S from=”utente@gmail.com(Gabriele Merli – gmail)” -S smtp-auth-user=utente@gmail.com -S smtp-auth-password=lapassword -S ssl-verify=ignore -S nss-config-dir=~/certs2/ destination.mail@dominio.it

1

echo “Un caro saluto” | mailx –v –s “Ciao Gabriele” –S smtp–use–starttls –S smtp–auth=login –S smtp=smtp://smtp.gmail.com:587 -S from=”utente@gmail.com(Gabriele Merli – gmail)” -S smtp-auth-user=utente@gmail.com -S smtp-auth-password=lapassword -S ssl-verify=ignore -S nss-config-dir=~/certs2/ destination.mail@dominio.it

In più abbiamo messo l’opzione

smtp-use-starttls<br /><br /> Causes mailx to issue a STARTTLS command to make an SMTP session SSL/TLS encrypted. Not all servers support this command; because of common<br /><br /> implementation defects, it cannot be automatically determined whether a server supports it or not

1 2 3

smtp–use–starttls               Causes mailx to issue a STARTTLS command to make an SMTP session SSL/TLS encrypted.  Not all servers support this command; because  of  common               implementation defects, it cannot be automatically determined whether a server supports it or not

che da il comando STARTTLS.

Ho cambiato la porta di comunicazione(587) e il protocollo (da smtps a  smtp)

Se non si specifica una directory in cui sono contenuti i certificati/chiavi nel formato nss (-S nss-config-dir=~/certs/) l’errore sarà

220 2.0.0 Ready to start TLS<br /><br /> Missing “nss-config-dir” variable.<br /><br /> “/home/merli/dead.letter” 11/354

1 2 3

220 2.0.0 Ready to start TLS Missing “nss-config-dir” variable. “/home/merli/dead.letter” 11/354

e l’email non verrà mandata.

---

Vediamo ora come crearsi una directory con i certificati che servono per inviare le mail con gmail.

Vado a utilizzare  il tool “certutil”

]# which certutil<br /><br /> /bin/certutil<br /><br /> ]# rpm -qf /bin/certutil<br /><br /> nss-tools-3.19.1-3.el7_1.x86_64<br /><br /> ]# yum info nss-tools<br /><br /> Installed Packages<br /><br /> Name : nss-tools<br /><br /> Arch : x86_64<br /><br /> Version : 3.19.1<br /><br /> Release : 3.el7_1<br /><br /> Size : 1.8 M<br /><br /> Repo : installed<br /><br /> From repo : updates<br /><br /> Summary : Tools for the Network Security Services<br /><br /> URL : http://www.mozilla.org/projects/security/pki/nss/<br /><br /> License : MPLv2.0<br /><br /> Description : Network Security Services (NSS) is a set of libraries designed to<br /><br /> : support cross-platform development of security-enabled client and<br /><br /> : server applications. Applications built with NSS can support SSL<br /><br /> : v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME,<br /><br /> : X.509 v3 certificates, and other security standards.<br /><br /> :<br /><br /> : Install the nss-tools package if you need command-line tools to<br /><br /> : manipulate the NSS certificate and key database.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

]# which certutil /bin/certutil ]# rpm -qf /bin/certutil nss–tools–3.19.1–3.el7_1.x86_64 ]# yum info nss-tools Installed Packages Name        : nss–tools Arch        : x86_64 Version     : 3.19.1 Release     : 3.el7_1 Size        : 1.8 M Repo        : installed From repo   : updates Summary     : Tools for the Network Security Services URL         : http://www.mozilla.org/projects/security/pki/nss/ License     : MPLv2.0 Description : Network Security Services (NSS) is a set of libraries designed to             : support cross–platform development of security–enabled client and             : server applications. Applications built with NSS can support SSL             : v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME,             : X.509 v3 certificates, and other security standards.             :             : Install the nss–tools package if you need command–line tools to             : manipulate the NSS certificate and key database.

La configurazione di base che possiamo fare è estremamente semplice. Basta infatti creare una directory (nel mio caso ~/certs)

utente@client ]# mkdir certs

1	utente@client ]# mkdir certs

e poi lanciare certutil per creare all’interno della directory i  database con i certificati e le chiavi (non mettendo password)

utente@client: ]# certutil -N -d certs/

1	utente@client: ]# certutil -N -d certs/

-N nuova
-d il nome della directory in cui creare il db

All’interno di certs poi mi troverò 3 file .db (certX.db, keyX.db e secmod.db) che conterranno i vari certificati/chiavi che posso importare.

Visto che, quando mandiamo la mail via gmail e mailx, specifichiamo il parametro

-S ssl-verify=ignore

che di fatto ignora ogni possibile verifica del certificato, questo è tutto quello che dobbiamo fare.

In fase di invio ci sarà un warning di questo tipo

Error in certificate: Peer’s certificate issuer is not recognized.<br /><br /> Comparing DNS name: “smtp.gmail.com”

1 2	Error in certificate: Peer‘s certificate issuer is not recognized. Comparing DNS name: “smtp.gmail.com”

ma la mail verrà comunque inviata. Chiaramente se avessi scritto -S ssl-verify=strict questo sarebbe stato un errore che avrebbe fermato la procedura.

Se si vuole evitare di crearsi una cartella (certs) con all’interno i vari database sostanzialmente vuoti, è possibile riciclare quella che già esiste sul sistema se si sta usando firefox.
All’interno della cartella

~/.mozilla/firefox/XXXprofile_numberXXXX.default/

ci sono gli stessi identici 3 file di cui sopra (certX.db, keyX.db e secmod.db) che già contengono tutti i certificati dei server che abbiamo accettato durante la navigazione in internet con firefox.

Basterà quindi specificare in mailx il parametro

-S nss-config-dir=~/.mozilla/firefox/XXXprofile_numberXXXX.default/

(dove XXXprofile_numberXXXX è il nome della cartella contenente il nostro profilo).

Nota che mi sembra di aver capito che i certificati delle CA sono hard-coded all’interno dell’eseguibile di firefox e i certificati che vengno aggiunti in questi file .db sono solo quelli accettati dall’utente.

---

Ora la parte interessante.  Come posso far sparire il warning
“Error in certificate: Peer’s certificate issuer is not recognized.” e potenzialmente effetture la verifica “strict” del certificato di gmail?

Presumo di aver già creato la directory certs nella home e di aver dato il comando di certutil per creare i 3 file di database (sostanzialmente vuoti) al suo interno.

Ora con il client openssl vado a interrogare smtp.gmail.com per vedere che certificati vengono utilizzati

]# openssl s_client -connect smtp.gmail.com:465<br /><br /> CONNECTED(00000003)<br /><br /> depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority<br /><br /> verify return:1<br /><br /> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA<br /><br /> verify return:1<br /><br /> depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2<br /><br /> verify return:1<br /><br /> depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = smtp.gmail.com<br /><br /> verify return:1<br /><br /> —<br /><br /> Certificate chain<br /><br /> 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com<br /><br /> i:/C=US/O=Google Inc/CN=Google Internet Authority G2<br /><br /> 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2<br /><br /> i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA<br /><br /> 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA<br /><br /> i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority<br /><br /> —<br /><br /> Server certificate<br /><br /> —–BEGIN CERTIFICATE—–<br /><br /> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<br /><br /> —–END CERTIFICATE—–<br /><br /> subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com<br /><br /> issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

]# openssl s_client -connect smtp.gmail.com:465 CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = smtp.gmail.com verify return:1 —– Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com    i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority —– Server certificate ——–BEGIN CERTIFICATE——– XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ——–END CERTIFICATE——– subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2

Tra le rige  —–BEGIN CERTIFICATE—– e —–END CERTIFICATE—– mi trovò il certificato del server. Questo è firmato (Issuer) da “Google Internet Authority” il quale è firmato da “GeoTrust Global” il quale è firmato dalla root CA “Equifax Secure Certificate Authority”. Questi 3 certificati formano la chain che permette al client (conoscendo la CA) di essere sicuro di star parlando proprio con gmail.

Dando lo stesso comando di cui sopra, ma specificando anche -showcerts potrò vedere tutti e 3 i certificati della chain

]# openssl s_client -showcerts -connect smtp.gmail.com:465</p><br /> <p>—<br /><br /> Certificate chain</p><br /> <p> 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com<br /><br /> i:/C=US/O=Google Inc/CN=Google Internet Authority G2<br /><br /> —–BEGIN CERTIFICATE—–<br /><br /> AAAAAAAAAAAAAAAAAAAAAAAAAAAA<br /><br /> —–END CERTIFICATE—–</p><br /> <p> 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2<br /><br /> i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA<br /><br /> —–BEGIN CERTIFICATE—–<br /><br /> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB<br /><br /> —–END CERTIFICATE—–</p><br /> <p> 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA<br /><br /> i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority<br /><br /> —–BEGIN CERTIFICATE—–<br /><br /> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br /><br /> —–END CERTIFICATE—–

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

]# openssl s_client -showcerts -connect smtp.gmail.com:465 —– Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com    i:/C=US/O=Google Inc/CN=Google Internet Authority G2 ——–BEGIN CERTIFICATE——– AAAAAAAAAAAAAAAAAAAAAAAAAAAA ——–END CERTIFICATE——– 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA ——–BEGIN CERTIFICATE——– BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB ——–END CERTIFICATE——– 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority ——–BEGIN CERTIFICATE——– CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC ——–END CERTIFICATE——–

Ora prendo ciascuna riga compresa tra —–BEGIN CERTIFICATE—– e —–END CERTIFICATE—– (comprese) e creo 3 file (chiamti come voglio, nel mio caso google, geotrust e equifax) contenenti i 3 certificati.

Vado ora ad aggiungere al mio db i 3 certificati appena salvati

]# certutil -A -n “GeoTrust Global CA” -t “TC,,” -d certs -i geotrust<br /><br /> ]# certutil -A -n “Equifax Secure Certificate Authority” -t “TCP,,” -d certs -i equifax<br /><br /> ]# certutil -A -n “Google Internet Authority” -t “TC,,” -d certs -i google

1 2 3

]# certutil -A -n “GeoTrust Global CA” -t “TC,,” -d certs -i geotrust ]# certutil -A -n “Equifax Secure Certificate Authority” -t “TCP,,” -d certs -i equifax ]# certutil -A -n “Google Internet Authority” -t “TC,,” -d certs -i google

-A aggiunge
-n è il nickname del certificato che gli asssegno nel db (nel mio caso ho copiato il CN)
-t è la tipologia di certificato (non ho pienamente compreso cosa sia)

· p – Valid peer<br /><br /> · P – Trusted peer (implies p)<br /><br /> · c – Valid CA<br /><br /> · T – Trusted CA (implies c)<br /><br /> · C – trusted CA for client authentication (ssl server only)<br /><br /> · u – user

1 2 3 4 5 6

·   p – Valid peer            ·   P – Trusted peer (implies p)            ·   c – Valid CA            ·   T – Trusted CA (implies c)            ·   C – trusted CA for client authentication (ssl server only)            ·   u – user

-d certs la directory che contiene i file del database
-i nome_file il nome del file contenente il certificato

Verifico di aver importato correttamente i 3 certificati dando il comando

]# certutil -L -d certs</p><br /> <p>Certificate Nickname Trust Attributes<br /><br /> SSL,S/MIME,JAR/XPI</p><br /> <p>GeoTrust Global CA CT,,<br /><br /> Google Internet Authority CT,,<br /><br /> Equifax Secure Certificate Authority CT,,

1 2 3 4 5 6 7 8

]# certutil -L -d certs Certificate Nickname                                         Trust Attributes                                                              SSL,S/MIME,JAR/XPI GeoTrust Global CA                                           CT,, Google Internet Authority                                    CT,, Equifax Secure Certificate Authority                         CT,,

per curiosità lo stesso comando lo puoi dare sulla directory di mozilla e verificare che i certificati che vedi sono gli stessi che trovi nelle Preferences/Advanced/Certificates/View Certificates/Servers

Ora quindi nel mio db ho i 3 certificati della chain di gmail. Riprovo a dare il comando di mailx per inviare le mail e, effettivamente, il warning “Error in certificate: Peer’s certificate issuer is not recognized.” è sparito.

Purtroppo però ciò non vuol dire che io possa mettere “-S ssl-verify=strict” in quanto, se lo faccio, la procedura si blocca comunque dando il messaggio:
Comparing DNS name: “smtp.gmail.com”.

Peraltro sto usando i certificati in modo improprio, prendendo per buoni quelli che mi fornisce gmail e non andando a verificare per davvero quello della CA che avrei dovuto scaricare da altre fonti.

Spesso mi capita di dover usare mailx da riga di comando per inviare semplici mail di notifica, generalmente all’interno di uno script.

Il pacchetto mailx è questo (in centos 7)

]# yum info mailx<br /><br /> Installed Packages<br /><br /> Name : mailx<br /><br /> Arch : x86_64<br /><br /> Version : 12.5<br /><br /> Release : 12.el7_0<br /><br /> Size : 466 k<br /><br /> Repo : installed<br /><br /> From repo : updates<br /><br /> Summary : Enhanced implementation of the mailx command<br /><br /> URL : http://heirloom.sourceforge.net/mailx.html<br /><br /> License : BSD with advertising and MPLv1.1<br /><br /> Description : Mailx is an enhanced mail command, which provides the functionality<br /><br /> : of the POSIX mailx command, as well as SysV mail and Berkeley Mail<br /><br /> : (from which it is derived).<br /><br /> :<br /><br /> : Additionally to the POSIX features, mailx can work with Maildir/ e-mail<br /><br /> : storage format (as well as mailboxes), supports IMAP, POP3 and SMTP<br /><br /> : protocols (including over SSL) to operate with remote hosts, handles mime<br /><br /> : types and different charsets. There are a lot of other useful features,<br /><br /> : see mailx(1).<br /><br /> :<br /><br /> : And as its ancient analogues, mailx can be used as a mail script language,<br /><br /> : both for sending and receiving mail.<br /><br /> :<br /><br /> : Besides the “mailx” command, this package provides “mail” and “Mail”<br /><br /> : (which should be compatible with its predecessors from the mailx-8.x source),<br /><br /> : as well as “nail” (the initial name of this project).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

]# yum info mailx Installed Packages Name        : mailx Arch        : x86_64 Version     : 12.5 Release     : 12.el7_0 Size        : 466 k Repo        : installed From repo   : updates Summary     : Enhanced implementation of the mailx command URL         : http://heirloom.sourceforge.net/mailx.html License     : BSD with advertising and MPLv1.1 Description : Mailx is an enhanced mail command, which provides the functionality             : of the POSIX mailx command, as well as SysV mail and Berkeley Mail             : (from which it is derived).             :             : Additionally to the POSIX features, mailx can work with Maildir/ e–mail             : storage format (as well as mailboxes), supports IMAP, POP3 and SMTP             : protocols (including over SSL) to operate with remote hosts, handles mime             : types and different charsets. There are a lot of other useful features,             : see mailx(1).             :             : And as its ancient analogues, mailx can be used as a mail script language,             : both for sending and receiving mail.             :             : Besides the “mailx” command, this package provides “mail” and “Mail”             : (which should be compatible with its predecessors from the mailx–8.x source),             : as well as “nail” (the initial name of this project).

 

Utilizzando un mail server tipo postfix dall’interno di una rete in cui permetto il relay, per mandare un mail basta il comando:

]# mailx -v -s “Subject” -S smtp=smtp://mailserver.dominio.it -S from=”me@server(Gabriele Merli)” destination.mail@dominio.it

1	]# mailx -v -s “Subject” -S smtp=smtp://mailserver.dominio.it -S from=”me@server(Gabriele Merli)” destination.mail@dominio.it

Il soggetto sarà “Subject”, il server di posta utilizzato sarà mailserver.dominio.it, il mail del mittente è me@server con nome Gabriele Merli e il destinatario sarà destination.mail@dominio.it

Poi scrivo il testo, termino con un . e la mail viene inviata.

All’interno di uno script con body precompilato basta una cosa del tipo

]# echo “ciao” | mailx -v -s “Subject” -S smtp=smtp://mailserver.dominio.it -S from=”me@server(Gabriele Merli)” destination.mail@dominio.it

1	]# echo “ciao” | mailx -v -s “Subject” -S smtp=smtp://mailserver.dominio.it -S from=”me@server(Gabriele Merli)” destination.mail@dominio.it

ed il testo del messaggio sarà “ciao”.

---

Volendo usare GMAIL per inviare la stessa semplicissima mail la questione si complica leggermente.

Il comando da dare è questo:

echo “Un caro saluto” | mailx -v -s “Ciao Gabriele” -S smtp-auth=login -S smtp=smtps://smtp.gmail.com:465 -S from=”utente@gmail.com(Gabriele Merli – gmail)” -S smtp-auth-user=utente@gmail.com -S smtp-auth-password=lapassword -S ssl-verify=ignore -S nss-config-dir=~/certs2/ destination.mail@dominio.it

1

echo “Un caro saluto” | mailx –v –s “Ciao Gabriele” –S smtp–auth=login –S smtp=smtps://smtp.gmail.com:465 –S from=“utente@gmail.com(Gabriele Merli – gmail)” –S smtp–auth–user=utente@gmail.com –S smtp–auth–password=lapassword –S ssl–verify=ignore –S nss–config–dir=~/certs2/ destination.mail@dominio.it

I parametri in più servono per effettuare l’autenticazione in fase di invio via smtp e per connettersi al server via ssl.

Questa la man page di mailx riguardo ai parametri sopra indicati

ssl-verify<br /><br /> Sets the action to be performed if an error occurs during SSL/TLS server certificate validation. Valid values are `strict’ (fail and<br /><br /> close connection immediately), `ask’ (ask whether to continue on standard input), `warn’ (print a warning and continue), `ignore’ (do<br /><br /> not perform validation). The default is `ask’.

1 2 3 4

ssl–verify               Sets  the  action to be performed if an error occurs during SSL/TLS server certificate validation.  Valid values are `strict‘ (fail and               close connection immediately), `ask‘ (ask whether to continue on standard input), `warn’ (print a warning and continue),  `ignore‘  (do               not perform validation).  The default is `ask‘.

Nel mio caso ignoro gli errori di validazione del certificato ssl/tls (vedremo poi in seguito)

smtp-auth<br /><br /> Sets the SMTP authentication method. If set to `login’, or if unset and smtp-auth-user is set, AUTH LOGIN is used. If set to `cram-<br /><br /> md5′, AUTH CRAM-MD5 is used; if set to `plain’, AUTH PLAIN is used. Otherwise, no SMTP authentication is performed.

1 2 3

smtp–auth               Sets the SMTP authentication method.  If set to `login‘, or if unset and smtp–auth–user is set, AUTH LOGIN is used.  If set  to  `cram–               md5‘, AUTH CRAM-MD5 is used; if set to `plain’, AUTH PLAIN is used.  Otherwise, no SMTP authentication is performed.

L’autenticazione avviene tramite AUTH LOGIN passando poi username (generalmente l’indirizzo email @ gmail.com) e la password

nss-config-dir<br /><br /> A directory that contains the files certN.db to retrieve certificates, keyN.db to retrieve private keys, and secmod.db, where N is a digit.<br /><br /> These are usually taken from Mozilla installations, so an appropriate value might be `~/.mozilla/firefox/default.clm’. Mailx opens these<br /><br /> files read-only and does not modify them. However, if the files are modified by Mozilla while mailx is running, it will print a `Bad dataâ[m<br /><br /> base’ message. It may be necessary to create copies of these files that are exclusively used by mailx then. Only applicable if S/MIME and<br /><br /> SSL/TLS support is built using Network Security Services (NSS).

1 2 3 4 5 6

nss–config–dir               A directory that contains the files certN.db to retrieve certificates, keyN.db to retrieve private keys, and secmod.db, where N  is  a  digit.               These  are  usually  taken  from  Mozilla installations, so an appropriate value might be `~/.mozilla/firefox/default.clm‘.  Mailx opens these               files read–only and does not modify them.  However, if the files are modified by Mozilla while mailx is running, it will print  a  `Bad  dataâ[m               base‘  message.   It  may be necessary to create copies of these files that are exclusively used by mailx then.  Only applicable if S/MIME and               SSL/TLS support is built using Network Security Services (NSS).

La directory dove andiamo a memorizzare i certificati (vedremo poi in seguito), nel mio caso ~/certs

Volendo mandare mail utilizzando starttls e la porta 587 (quindi  primo collegamento in chiaro e poi si effettua la cifratura), il comando da dare è molto simile a quello visto precedentemente

echo “Un caro saluto” | mailx -v -s “Ciao Gabriele” -S smtp-use-starttls -S smtp-auth=login -S smtp=smtp://smtp.gmail.com:587 -S from=”utente@gmail.com(Gabriele Merli – gmail)” -S smtp-auth-user=utente@gmail.com -S smtp-auth-password=lapassword -S ssl-verify=ignore -S nss-config-dir=~/certs2/ destination.mail@dominio.it

1

echo “Un caro saluto” | mailx –v –s “Ciao Gabriele” –S smtp–use–starttls –S smtp–auth=login –S smtp=smtp://smtp.gmail.com:587 -S from=”utente@gmail.com(Gabriele Merli – gmail)” -S smtp-auth-user=utente@gmail.com -S smtp-auth-password=lapassword -S ssl-verify=ignore -S nss-config-dir=~/certs2/ destination.mail@dominio.it

In più abbiamo messo l’opzione

smtp-use-starttls<br /><br /> Causes mailx to issue a STARTTLS command to make an SMTP session SSL/TLS encrypted. Not all servers support this command; because of common<br /><br /> implementation defects, it cannot be automatically determined whether a server supports it or not

1 2 3

smtp–use–starttls               Causes mailx to issue a STARTTLS command to make an SMTP session SSL/TLS encrypted.  Not all servers support this command; because  of  common               implementation defects, it cannot be automatically determined whether a server supports it or not

che da il comando STARTTLS.

Ho cambiato la porta di comunicazione(587) e il protocollo (da smtps a  smtp)

Se non si specifica una directory in cui sono contenuti i certificati/chiavi nel formato nss (-S nss-config-dir=~/certs/) l’errore sarà

220 2.0.0 Ready to start TLS<br /><br /> Missing “nss-config-dir” variable.<br /><br /> “/home/merli/dead.letter” 11/354

1 2 3

220 2.0.0 Ready to start TLS Missing “nss-config-dir” variable. “/home/merli/dead.letter” 11/354

e l’email non verrà mandata.

---

Vediamo ora come crearsi una directory con i certificati che servono per inviare le mail con gmail.

Vado a utilizzare  il tool “certutil”

]# which certutil<br /><br /> /bin/certutil<br /><br /> ]# rpm -qf /bin/certutil<br /><br /> nss-tools-3.19.1-3.el7_1.x86_64<br /><br /> ]# yum info nss-tools<br /><br /> Installed Packages<br /><br /> Name : nss-tools<br /><br /> Arch : x86_64<br /><br /> Version : 3.19.1<br /><br /> Release : 3.el7_1<br /><br /> Size : 1.8 M<br /><br /> Repo : installed<br /><br /> From repo : updates<br /><br /> Summary : Tools for the Network Security Services<br /><br /> URL : http://www.mozilla.org/projects/security/pki/nss/<br /><br /> License : MPLv2.0<br /><br /> Description : Network Security Services (NSS) is a set of libraries designed to<br /><br /> : support cross-platform development of security-enabled client and<br /><br /> : server applications. Applications built with NSS can support SSL<br /><br /> : v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME,<br /><br /> : X.509 v3 certificates, and other security standards.<br /><br /> :<br /><br /> : Install the nss-tools package if you need command-line tools to<br /><br /> : manipulate the NSS certificate and key database.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

]# which certutil /bin/certutil ]# rpm -qf /bin/certutil nss–tools–3.19.1–3.el7_1.x86_64 ]# yum info nss-tools Installed Packages Name        : nss–tools Arch        : x86_64 Version     : 3.19.1 Release     : 3.el7_1 Size        : 1.8 M Repo        : installed From repo   : updates Summary     : Tools for the Network Security Services URL         : http://www.mozilla.org/projects/security/pki/nss/ License     : MPLv2.0 Description : Network Security Services (NSS) is a set of libraries designed to             : support cross–platform development of security–enabled client and             : server applications. Applications built with NSS can support SSL             : v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME,             : X.509 v3 certificates, and other security standards.             :             : Install the nss–tools package if you need command–line tools to             : manipulate the NSS certificate and key database.

La configurazione di base che possiamo fare è estremamente semplice. Basta infatti creare una directory (nel mio caso ~/certs)

utente@client ]# mkdir certs

1	utente@client ]# mkdir certs

e poi lanciare certutil per creare all’interno della directory i  database con i certificati e le chiavi (non mettendo password)

utente@client: ]# certutil -N -d certs/

1	utente@client: ]# certutil -N -d certs/

-N nuova
-d il nome della directory in cui creare il db

All’interno di certs poi mi troverò 3 file .db (certX.db, keyX.db e secmod.db) che conterranno i vari certificati/chiavi che posso importare.

Visto che, quando mandiamo la mail via gmail e mailx, specifichiamo il parametro

-S ssl-verify=ignore

che di fatto ignora ogni possibile verifica del certificato, questo è tutto quello che dobbiamo fare.

In fase di invio ci sarà un warning di questo tipo

Error in certificate: Peer’s certificate issuer is not recognized.<br /><br /> Comparing DNS name: “smtp.gmail.com”

1 2	Error in certificate: Peer‘s certificate issuer is not recognized. Comparing DNS name: “smtp.gmail.com”

ma la mail verrà comunque inviata. Chiaramente se avessi scritto -S ssl-verify=strict questo sarebbe stato un errore che avrebbe fermato la procedura.

Se si vuole evitare di crearsi una cartella (certs) con all’interno i vari database sostanzialmente vuoti, è possibile riciclare quella che già esiste sul sistema se si sta usando firefox.
All’interno della cartella

~/.mozilla/firefox/XXXprofile_numberXXXX.default/

ci sono gli stessi identici 3 file di cui sopra (certX.db, keyX.db e secmod.db) che già contengono tutti i certificati dei server che abbiamo accettato durante la navigazione in internet con firefox.

Basterà quindi specificare in mailx il parametro

-S nss-config-dir=~/.mozilla/firefox/XXXprofile_numberXXXX.default/

(dove XXXprofile_numberXXXX è il nome della cartella contenente il nostro profilo).

Nota che mi sembra di aver capito che i certificati delle CA sono hard-coded all’interno dell’eseguibile di firefox e i certificati che vengno aggiunti in questi file .db sono solo quelli accettati dall’utente.

---

Ora la parte interessante.  Come posso far sparire il warning
“Error in certificate: Peer’s certificate issuer is not recognized.” e potenzialmente effetture la verifica “strict” del certificato di gmail?

Presumo di aver già creato la directory certs nella home e di aver dato il comando di certutil per creare i 3 file di database (sostanzialmente vuoti) al suo interno.

Ora con il client openssl vado a interrogare smtp.gmail.com per vedere che certificati vengono utilizzati

]# openssl s_client -connect smtp.gmail.com:465<br /><br /> CONNECTED(00000003)<br /><br /> depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority<br /><br /> verify return:1<br /><br /> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA<br /><br /> verify return:1<br /><br /> depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2<br /><br /> verify return:1<br /><br /> depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = smtp.gmail.com<br /><br /> verify return:1<br /><br /> —<br /><br /> Certificate chain<br /><br /> 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com<br /><br /> i:/C=US/O=Google Inc/CN=Google Internet Authority G2<br /><br /> 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2<br /><br /> i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA<br /><br /> 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA<br /><br /> i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority<br /><br /> —<br /><br /> Server certificate<br /><br /> —–BEGIN CERTIFICATE—–<br /><br /> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<br /><br /> —–END CERTIFICATE—–<br /><br /> subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com<br /><br /> issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

]# openssl s_client -connect smtp.gmail.com:465 CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = smtp.gmail.com verify return:1 —– Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com    i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority —– Server certificate ——–BEGIN CERTIFICATE——– XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ——–END CERTIFICATE——– subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2

Tra le rige  —–BEGIN CERTIFICATE—– e —–END CERTIFICATE—– mi trovò il certificato del server. Questo è firmato (Issuer) da “Google Internet Authority” il quale è firmato da “GeoTrust Global” il quale è firmato dalla root CA “Equifax Secure Certificate Authority”. Questi 3 certificati formano la chain che permette al client (conoscendo la CA) di essere sicuro di star parlando proprio con gmail.

Dando lo stesso comando di cui sopra, ma specificando anche -showcerts potrò vedere tutti e 3 i certificati della chain

]# openssl s_client -showcerts -connect smtp.gmail.com:465</p><br /> <p>—<br /><br /> Certificate chain</p><br /> <p> 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com<br /><br /> i:/C=US/O=Google Inc/CN=Google Internet Authority G2<br /><br /> —–BEGIN CERTIFICATE—–<br /><br /> AAAAAAAAAAAAAAAAAAAAAAAAAAAA<br /><br /> —–END CERTIFICATE—–</p><br /> <p> 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2<br /><br /> i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA<br /><br /> —–BEGIN CERTIFICATE—–<br /><br /> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB<br /><br /> —–END CERTIFICATE—–</p><br /> <p> 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA<br /><br /> i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority<br /><br /> —–BEGIN CERTIFICATE—–<br /><br /> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC<br /><br /> —–END CERTIFICATE—–

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

]# openssl s_client -showcerts -connect smtp.gmail.com:465 —– Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com    i:/C=US/O=Google Inc/CN=Google Internet Authority G2 ——–BEGIN CERTIFICATE——– AAAAAAAAAAAAAAAAAAAAAAAAAAAA ——–END CERTIFICATE——– 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA ——–BEGIN CERTIFICATE——– BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB ——–END CERTIFICATE——– 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority ——–BEGIN CERTIFICATE——– CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC ——–END CERTIFICATE——–

Ora prendo ciascuna riga compresa tra —–BEGIN CERTIFICATE—– e —–END CERTIFICATE—– (comprese) e creo 3 file (chiamti come voglio, nel mio caso google, geotrust e equifax) contenenti i 3 certificati.

Vado ora ad aggiungere al mio db i 3 certificati appena salvati

]# certutil -A -n “GeoTrust Global CA” -t “TC,,” -d certs -i geotrust<br /><br /> ]# certutil -A -n “Equifax Secure Certificate Authority” -t “TCP,,” -d certs -i equifax<br /><br /> ]# certutil -A -n “Google Internet Authority” -t “TC,,” -d certs -i google

1 2 3

]# certutil -A -n “GeoTrust Global CA” -t “TC,,” -d certs -i geotrust ]# certutil -A -n “Equifax Secure Certificate Authority” -t “TCP,,” -d certs -i equifax ]# certutil -A -n “Google Internet Authority” -t “TC,,” -d certs -i google

-A aggiunge
-n è il nickname del certificato che gli asssegno nel db (nel mio caso ho copiato il CN)
-t è la tipologia di certificato (non ho pienamente compreso cosa sia)

· p – Valid peer<br /><br /> · P – Trusted peer (implies p)<br /><br /> · c – Valid CA<br /><br /> · T – Trusted CA (implies c)<br /><br /> · C – trusted CA for client authentication (ssl server only)<br /><br /> · u – user

1 2 3 4 5 6

·   p – Valid peer            ·   P – Trusted peer (implies p)            ·   c – Valid CA            ·   T – Trusted CA (implies c)            ·   C – trusted CA for client authentication (ssl server only)            ·   u – user

-d certs la directory che contiene i file del database
-i nome_file il nome del file contenente il certificato

Verifico di aver importato correttamente i 3 certificati dando il comando

]# certutil -L -d certs</p><br /> <p>Certificate Nickname Trust Attributes<br /><br /> SSL,S/MIME,JAR/XPI</p><br /> <p>GeoTrust Global CA CT,,<br /><br /> Google Internet Authority CT,,<br /><br /> Equifax Secure Certificate Authority CT,,

1 2 3 4 5 6 7 8

]# certutil -L -d certs Certificate Nickname                                         Trust Attributes                                                              SSL,S/MIME,JAR/XPI GeoTrust Global CA                                           CT,, Google Internet Authority                                    CT,, Equifax Secure Certificate Authority                         CT,,

per curiosità lo stesso comando lo puoi dare sulla directory di mozilla e verificare che i certificati che vedi sono gli stessi che trovi nelle Preferences/Advanced/Certificates/View Certificates/Servers

Ora quindi nel mio db ho i 3 certificati della chain di gmail. Riprovo a dare il comando di mailx per inviare le mail e, effettivamente, il warning “Error in certificate: Peer’s certificate issuer is not recognized.” è sparito.

Purtroppo però ciò non vuol dire che io possa mettere “-S ssl-verify=strict” in quanto, se lo faccio, la procedura si blocca comunque dando il messaggio:
Comparing DNS name: “smtp.gmail.com”.

Peraltro sto usando i certificati in modo improprio, prendendo per buoni quelli che mi fornisce gmail e non andando a verificare per davvero quello della CA che avrei dovuto scaricare da altre fonti.