LINUX:Postfix-Tester

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche

→ retour au menu de Postfix

But

Après la configuration de Postfix, il faut le tester. On peut aussi tester un serveur distant.


Envoi de mail

On peut directement tester l'envoi à partir du serveur de messagerie via la commande "mail": 

mail root -s Essai

Avec la commande ci-dessus, on veut envoyer un mail à l'utilisateur local root dont le sujet ("-s") est "Essai". Le prompt apparaît pour introduire le corps du message. Ce message est clôturé par une ligne ne comportant qu'un point (".").

On peut l'envoyer à un autre serveur de messagerie afin de voir si l'envoi distant fonctionne: 

mail pdupont@home.dom -s Essai


Codage en BASE64

La messagerie via Internet est très ancienne; il travaillait en 7 bits dont la partie centrale correspond à l'alphabet anglais (majuscules et minuscules) et aux digits (0 à 9), ce qui correspond à 62 caractères (on y ajoute le "+" et le "/" pour arriver à 64) ; le début regroupe des caractères spéciaux comme le saut de ligne, le saut de page, le retour à la ligne, des codes pour la gestion du transfert sur ligne série ou via modem. Pour envoyer par exemple un exécutable directement, il allait y avoir interférence avec ces codes de gestion. La solution, toujours utilisée est de recoder ce fichier d'une base de 8 bits à une base de 6 bits (26=64); à chacune de ces 64 cases correspondent les 64 lettres et chiffres retenues ci-dessus; les cases sont numérotées de 0 à 63. Le principe est d'aligner l'un derrière l'autre toutes les séquences de 8 bits du fichier. On a une longue chaine binaire. Si on découpe cette chaine par lot de 6 bits au lieu de 8 bits, chaque bloc donne en binaire à un chiffre en base 64. Ce chiffre correspond au numéro d'ordre des 64 lettres et chiffres cités ci-dessus. On obtient ainsi une suite de caractères en BASE64.


Ce codage est encore utilisé actuellement pour l'envoi de fichier attaché à votre mail. Quand on regarde le texte source du mail, en début du fichier attaché, on peut remarquer une ligne: 

Content-Transfer-Encoding: base64

qui notifie que la suite de la section est codé sur cette base.

Lors de l'authentification passant par l'envoi du nom de l'utilisateur et de son mot de passe, ce codage est utilisé. Nous en avons donc besoin pour notre essai d'envoi de mail aux points qui suivent.

Les commande suivantes donnent un exemple d'un script permettant cette transformation: 

#!/usr/bin/bash
perl -MMIME::Base64 -le 'print encode_base64("pdupont\@CENTRAL");' > user.lis
perl -MMIME::Base64 -le 'print encode_base64("Bateau23Ivre");' > pw.lis

La seconde ligne transforme le nom d'utilisateur "pdupont@CENTRAL" et le stocke dans le fichier "user.lis". Son contenu est "cGR1cG9udEBDRU5UUkFM".

La troisième fait la même chose pour le mot de passe de cet utilisateur et le stocke dans le fichier "pw.lis". Son contenu est "QmF0ZWF1MjNJdnJl".

Nous pourrons intégrer leur contenu dans les deux scripts qui suivent.


Telnet

A la base le traitement des mails se fait sans cryptage. Par exemple, le protocole SMTP, port 25, envoie des messages en clair et n'utilise pas d'authentification.

Le but de ce script Linux est d'interagir directement avec le serveur de messagerie local et de dialoguer en direct avec lui sans passer par un client de messagerie tel Thunderbird ou MS Outlook. On va voir tous les échanges et les commandes entre nous, le client et un serveur de messagerie.

Pour ce script, nous aurez besoin des programmes "telnet", "expect" et "spawn" que l'on installe de la façon suivante: 

dnf install expect spawn telnet


Voici le script: 

#!/usr/bin/expect -f
spawn /usr/bin/telnet serverdb.home.dom 25
sleep 1
send -- "EHLO serverdb.home.dom\n"
sleep 1
send -- "MAIL FROM:<pdupont@home.dom>\n"
sleep 1
send -- "rcpt to:<edupont@home.dom>\n"
sleep 1
send -- "DATA\n"
send -- "From: Pierre <pdupont@home.dom>\n"
send -- "To: Eric <edupont@home.dom>\n"
send -- "Subject: Test\n"
send -- "OK\n"
send -- ".\n"
sleep 1
send -- "QUIT\n"
expect EOF

Voici la réponse: 

spawn /usr/bin/telnet serverdb.home.dom 25
Trying 192.168.1.100...
Connected to serverdb.home.dom.
Escape character is '^]'.
EHLO serverdb.home.dom
250-serverdb.home.dom
250-PIPELINING
250-SIZE 10240000 
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
MAIL FROM:<pdupont@home.dom>
250 2.1.0 Ok
rcpt to:<edupont@home.dom>
250 2.1.5 Ok
DATA
From: Pierre <pdupont@home.dom>
To: Eric <edupont@home.dom>
Subject: Test
OK
.
354 End data with <CR><LF>.<CR><LF>
250 2.0.0 Ok: queued as 74D483001E96
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

En fin de réponse, avant la ligne "QUIT", nous voyons que le message a bien été mis en file d'attente sur notre serveur de messagerie.

Au passage, on remarque que ce service SMTP (port 25) supporte aussi le protocole STARTTLS. Des options spécifiques ont été ajoutées par rapport à la configuration par défaut de Postfix. Le script qui suit a été adapté pour cet envoi.


Openssl

Le but de ces scripts Linux est d'interagir directement avec un serveur de messagerie et de dialoguer en direct avec lui sans passer par un client de messagerie tel Thunderbird ou MS Outlook. On va voir tous les échanges et les commandes entre nous, le client et un serveur de messagerie.

Actuellement le cryptage est devenu la règle. On va utiliser pour cela le programme "openssl" qui nous a servi dans un autre article pour créer les certificats publiques.

Pour ce script, nous aurez besoin des programmes "expect" et "spawn" que l'on installe de la façon suivante: 

dnf install expect spawn


Dans le premier exemple, nous reprenons le cas décrit au point précédent mais en utilisant le protocole STARTTLS pour le protocole "SMTP" (port 25).

Dans les deux exemples qui suivent, nous interagissons avec un serveur de messagerie (MailEnable sous MS Windows) via les protocoles "Submission" et "SMTPS" avec authentification. Son adresse IP est 192.168.1.35 et, comme nous n'avons pas utilisé un serveur DNS interne, on interagit avec lui via son adresse IP. (option IP suivi du port de submission: -connect 192.168.1.35:587)

Comme ce serveur est sur un PC privé, le nom de domaine est créé pour la bonne cause "central.dom". Le certificat de CA de ce nom de domaine n'est pas connu au niveau international. Il ne se trouve pas dans le fichier global ou "bundle" des certificats des CA officiels de Linux. Il faut donc spécifier le nom du fichier du certificat CA du domaine "central.dom". (option: "-CAfile /etc/pki/tls/certs/ca.central.crt")

On peut effectuer la même opération avec un serveur de messagerie d'Internet pour autant que vous y ayez accès et que vous y ayez un compte pour y vérifier que le mail envoyé est bien arrivé. Dans ce cas, le certificat CA ne doit pas être spécifié.

Entre chaque envoi de commande, nous avons ajouté une pause ("sleep") afin de laisser le serveur répondre. A vous de juger. Ces scripts sont des exemples; à vous de les adapter à votre situation.


STARTTLS et SMTP

Dans ce cas, l'échange se fait ici via STARTSSL. Celui-ci est noté par l'option "-starttls smtp" pour le port 25 (SMTP).


Voici le script: 

#!/usr/bin/expect -f
spawn /usr/bin/openssl s_client -crlf -starttls smtp -connect serverdb.home.dom:25 -quiet
sleep 1
send -- "EHLO serverdb.home.dom\n"
sleep 1
send -- "MAIL FROM:<pdupont@home.dom>\n"
sleep 1
send -- "rcpt to:<edupont@home.dom>\n"
sleep 1
send -- "DATA\n"
sleep 1
send -- "From: Pierre <pdupont@home.dom>\n"
sleep 1
send -- "To: Eric <edupont@home.dom>\n"
sleep 1
send -- "Subject: Test\n"
sleep 1
send -- "OK\n"
sleep 1
send -- ".\n"
sleep 1
send -- "QUIT\n"
expect EOF

Voici la réponse: 

spawn /usr/bin/openssl s_client -crlf -starttls smtp -connect serverdb.home.dom:25 -quiet
Connecting to 192.168.1.100
depth=1 CN=CA.home.dom, emailAddress=pdupont@home.dom, OU=Dupont, O=Home, L=Namur, ST=Belgique, C=BE
verify return:1
depth=0 CN=mail.home.dom, emailAddress=pdupont@home.dom, OU=Dupont, O=Home, L=Namur, ST=Belgique, C=BE
verify return:1
250 CHUNKING
EHLO serverdb.home.dom
250-serverdb.home.dom
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
MAIL FROM:<pdupont@home.dom>
250 2.1.0 Ok
rcpt to:<edupont@home.dom>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: Pierre <pdupont@home.dom>
To: Eric <edupont@home.dom>
Subject: Test
OK
.
250 2.0.0 Ok: queued as F33A43001E96
QUIT
221 2.0.0 Bye

Nous avons utilisé l'option "-quite" afin déviter de recevoir tout le détail des certificats.


STARTTLS et Submission

Dans ce cas, l'échange se fait ici via STARTSSL. Celui-ci est noté par l'option "-starttls smtp". Le protocole utilisé est Submission avec le port 587.


Voici le script: 

#!/usr/bin/expect -f
spawn /usr/bin/openssl s_client -crlf -starttls smtp -CAfile /etc/pki/tls/certs/ca.central.crt -connect 192.168.1.35:587
sleep 1
send -- "EHLO mail.adbweb.gslb.eu\n"
sleep 1
send -- "AUTH LOGIN\n"
sleep 1
send -- "cGR1cG9udEBDRU5UUkFM\n"
sleep 1
send -- "QmF0ZWF1MjNJdnJl\n"
sleep 1
send -- "MAIL FROM:<pdupont@central.dom>\n"
sleep 1
send -- "rcpt to:<edupont@central.dom>\n"
sleep 1
send -- "DATA\n"
sleep 1
send -- "From: Pierre <pdupont@central.dom>\n"
sleep 1
send -- "To: Eric <edupont@central.dom>\n"
sleep 1
send -- "Subject: Test\n"
sleep 1
send -- "OK\n"
sleep 1
send -- ".\n"
sleep 1
send -- "QUIT\n"
expect EOF


Voici la réponse; nous avons mis en gras ce que nous envoyons: 

CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 CN = CA.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
verify return:1
depth=0 CN = mail.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
verify return:1
---
Certificate chain
 0 s:CN = mail.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
   i:CN = CA.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST= Belgique, C = BE
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=CN = mail.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
issuer=CN = CA.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 1754 bytes and written 484 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
   Protocol  : TLSv1.2
   Cipher    : ECDHE-RSA-AES256-GCM-SHA384
   Session-ID: 85380000236DDA4F300C27AC2A8D6F504119261324F739EC0AC03B7E6702A2B3
   Session-ID-ctx:
   Master-Key: 8F7EDBC71316CED9600AB12FB758FA8C00E12A5BD2FA21EC6282F916B70D755F009092653CD8A5C1FF5E22281F5FD4BD
   PSK identity: None
   PSK identity hint: None
   SRP username: None
   Start Time: 1604581840
   Timeout   : 7200 (sec)
   Verify return code: 0 (ok)
   Extended master secret: yes
---
250 STARTTLS
EHLO mail.adbweb.gslb.eu
250-central.dom [192.168.1.100], this server offers 4 extensions
250-AUTH CRAM-MD5 PLAIN LOGIN
250-SIZE 40960000
250-HELP
250 AUTH=LOGIN
AUTH LOGIN
334 VXNlcm5hbWU6
 cGR1cG9udEBDRU5UUkFM
334 UGFzc3dvcmQ6
 QmF0ZWF1MjNJdnJl
235 Authenticated
MAIL FROM:<pdupont@central.dom>
250 Requested mail action okay, completed
rcpt to:<edupont@central.dom>
250 Requested mail action okay, completed
DATA
From: Pierre <pdupont@central.dom>
To: Eric <edupont@central.dom>
Subject: Test
OK
.
354 Start mail input; end with <CRLF>.<CRLF>
250 Requested mail action okay, completed
QUIT
DONE

En début, le serveur se présente. (certificats, nom et version du logiciel, protocole TLS,...). Il annonce le protocole STARTTLS.

Nous présentons ("EHLO mail.adbweb.gslb.eu").

Le serveur présente les types d'authentification disponibles ("AUTH CRAM-MD5 PLAIN LOGIN").

On lance l'authentification, on fourni le nom d'utilisateur et le mot de passe codés en BASE64 comme calculés ci-dessus.

Le serveur accepte l'authentification.

Ensuite, on annonce qui envoie le mail et à qui.

Après acceptation du serveur, on émet le message (étape "DATA"). Remarquez que l'on répète le nom de l'envoyeur et du réceptionniste. C'est ce contenu que recevra notre correspondant. Il n'y a pas de vérification de ce contenu. On peut mettre ce que l'on veut. Les émetteurs de virus et de SPAMs ne s'en privent pas.

Le serveur accepte le message. Tout s'est bien passé.

Lors de l'échange du nom d'utilisateur et du mot de passe, le serveur envoie les messages "334 VXNlcm5hbWU6" et "334 UGFzc3dvcmQ6". Ces messages sont codés en BASE64. Si on les décode avec les commandes respectives: 

perl -MMIME::Base64 -le 'print decode_base64("VXNlcm5hbWU6");'
perl -MMIME::Base64 -le 'print decode_base64("UGFzc3dvcmQ6");'

on a les traductions: "Username:" et "Password:".


SSL/TLS et SMTPS

Dans ce second exemple, la configuration du serveur a changé. Nous obligeons le cryptage SSL (SSL/TLS) comme pour le protocole SMTPS et nous avons changé le port qui devient 3587 au lieu de 465 habituel. Pour cette raison, l'option "-starttls smtp" a disparu. Le n° du port a changé aussi. Les reste est le même.


Voici le script: 

#!/usr/bin/expect -f
spawn /usr/bin/openssl s_client -crlf -CAfile /etc/pki/tls/certs/ca.central.crt -connect 192.168.1.35:3587
sleep 1
send -- "EHLO mail.adbweb.gslb.eu\n"
sleep 1
send -- "AUTH LOGIN\n"
sleep 1
send -- " cGR1cG9udEBDRU5UUkFM\n"
sleep 1
send -- " QmF0ZWF1MjNJdnJl\n"
sleep 1
send -- "MAIL FROM:<pdupont@central.dom>\n"
sleep 1
send -- "rcpt to:<edupont@central.dom>\n"
sleep 1
send -- "DATA\n"
sleep 1
send -- "From: Pierre <pdupont@central.dom>\n"
sleep 1
send -- "To: Eric <edupont@central.dom>\n"
sleep 1
send -- "Subject: Test\n"
sleep 1
send -- "OK\n"
sleep 1
send -- ".\n"
sleep 1
send -- "QUIT\n"
expect EOF


Voici la réponse; nous avons mis en gras ce que nous envoyons: 

CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 CN = CA.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
verify return:1
depth=0 CN = mail.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
verify return:1
---
Certificate chain
 0 s:CN = mail.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
   i:CN = CA.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=CN = mail.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
issuer=CN = CA.central.dom, emailAddress = pdupont@home.dom, OU = Dupont, O = Central, L = Namur, ST = Belgique, C = BE
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 1530 bytes and written 451 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: B82D0000E8986401F48CE36CF3CBA2428C180A89B8AB9520791465FB22005D60
    Session-ID-ctx:
    Master-Key: D9609E195D90C8A81F3CDD0A66B17C1C7F9D6FEB451F6BF4A18F906240A57E79A3BD18AADC11DA70A25F48BB7618FBF4
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1604581681
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
220 mail.central.dom ESMTP MailEnable Service, Version: 10.31-- ready at 11/05/20 14:08:46
EHLO mail.adbweb.gslb.eu
250-central.dom [192.168.1.100], this server offers 4 extensions
250-AUTH CRAM-MD5 PLAIN LOGIN
250-SIZE 40960000
250-HELP
250 AUTH=LOGIN
AUTH LOGIN
334 VXNlcm5hbWU6
 cGR1cG9udEBDRU5UUkFM
334 UGFzc3dvcmQ6
 QmF0ZWF1MjNJdnJl
235 Authenticated
MAIL FROM:<pdupont@central.dom>
250 Requested mail action okay, completed
rcpt to:<edupont@central.dom>
250 Requested mail action okay, completed
DATA
From: Pierre <pdupont@central.dom>
To: Eric <edupont@central.dom>
Subject: Test
OK
.
354 Start mail input; end with <CRLF>.<CRLF>
250 Requested mail action okay, completed
QUIT
DONE

Comme différence, nous voyons que la réponse "250 STARTTLS" a disparu.


→ retour au menu de Postfix

Récupérée de "https://www.adbweb.gslb.eu/wiki/index.php?title=LINUX:Postfix-Tester&oldid=9553"