Envoi e-mail depuis le shell avec sSMTP en STARTTLS : error

Support Debian
#1

Bonjour,
J’essaie désespérément d’envoyer un e-mail en ligne de commande.

Pour cela, j’ai installé les paquets ssmtp et bsd-mailx à l’aide de apt-get.
J’utilise la commande suivante et je reçois un message d’erreur:

mail -v -s "Test" <mon e-mail> sdfjsdlkf. . Cc: [<-] 220 smtp1.infomaniak.ch ESMTP Infomaniak Network Relay Mail Servers; Tue, 13 Sep 2011 10:35:09 +0200 [->] EHLO firearrow [<-] 250 HELP [->] STARTTLS [<-] 220 2.0.0 Ready to start TLS [->] EHLO firearrow [<-] send-mail: (firearrow) Can't send mail: sendmail process failed with error code 1

J’ai aussi installé Thunderbird et ça marche avec lui.
Donc j’ai fais deux analyses réseau avec Wireshark pour comparer les différences.
La différence semble se tenir au niveau de l’envoi du certificat.
Dans le cas de Thunderbird, celui-ci répond au mailserver avec un Certificat avant d’envoyer l’e-mail.
Dans le cas de sSMTP, celui-ci balance directe l’e-mail sans répondre au préalable au mailserver avec un Certificat.

Les deux anaylses Wireshark sont ci-dessous :

Et celle qui ne fonctionne pas avec sSMTP

Pour info, mon fichier de config est configuré comme suit selon les instructions de mon hébergeur infomaniak http://www.infomaniak.ch/support/faq/questions/auriez_vous_un_exemple_de_configuration_ssmtp-1447.html?language=french :

[code]#

Config file for sSMTP sendmail

The person who gets all mail for userids < 1000

Make this empty to disable rewriting.

root=<mon email. Ex: toto@titi.com>
UseSTARTTLS=yes
AuthUser=<mon email. Ex: toto@titi.com>
AuthPass=
AuthMethod=Login

The place where the mail goes. The actual machine name is required no

MX records are consulted. Commonly mailhosts are named mail.domain.com

mailhub:587=mail.infomaniak.ch

Where will the mail seem to come from?

rewriteDomain=<mon domaine hébergé. Ex: titi.com>

The full hostname

hostname=

Are users allowed to set their own From: address?

YES - Allow the user to specify their own From: address

NO - Use the system generated From: address

FromLineOverride=YES
[/code]

Si quelqu’un a une idée ça serait sympa. Parce que là je bloque. (OpenSSL est déjà installé pour info)
Merci

#2

Le pire c’est que ça marche si j’utilise le serveur de gmail en STARTTLS !

[ssmtp]$ mail -v -s "Test" monemail@gmail.com sdfsef . Cc: [<-] 220 mx.google.com ESMTP p13sm3101677wbh.13 [->] EHLO firearrow [<-] 250 ENHANCEDSTATUSCODES [->] STARTTLS [<-] 220 2.0.0 Ready to start TLS [->] EHLO firearrow [<-] 250 ENHANCEDSTATUSCODES [->] AUTH LOGIN [<-] 334 VXNlcm5hbWU6 [->] ZG91Z2xhcy5tYWduZW5hdEBnbWFpbC5jb20= [<-] 334 UGFzc3dvcmQ6 [<-] 235 2.7.0 Accepted [->] MAIL FROM:<monemail@gmail.com> [<-] 250 2.1.0 OK p13sm3101677wbh.13 [->] RCPT TO:<monemail@gmail.com> [<-] 250 2.1.5 OK p13sm3101677wbh.13 [->] DATA [<-] 354 Go ahead p13sm3101677wbh.13 [->] Received: by firearrow (sSMTP sendmail emulation); Wed, 14 Sep 2011 09:47:44 +0200 [->] From: "Moi" <monemail@gmail.com> [->] Date: Wed, 14 Sep 2011 09:47:44 +0200 [->] To: monemail@gmail.com [->] Subject: Test [->] [->] sdfsef [->] . [<-] 250 2.0.0 OK 1315986469 p13sm3101677wbh.13 [->] QUIT [<-] 221 2.0.0 closing connection p13sm3101677wbh.13

Et j’ai utilisé le même fichier de config ssmtp.conf à la différence près du Hub et évidement des détails de login.

[code]root=monemail@gmail.com
AuthUser=monemail@gmail.com
AuthPass=monmotdepasse
UseSTARTTLS=yes

The place where the mail goes. The actual machine name is required no

MX records are consulted. Commonly mailhosts are named mail.domain.com

mailhub:587=smtp.gmail.com

Where will the mail seem to come from?

rewriteDomain=gmail.com

The full hostname

hostname=firearrow

Are users allowed to set their own From: address?

YES - Allow the user to specify their own From: address

NO - Use the system generated From: address

FromLineOverride=YES
[/code]

Cela laisse à penser que le problème est du côté d’Infomaniak.

#3

La réponse de Infomaniak c’est que SSMTP ne respecte pas le protocol STARTTLS.

Super comme réponse !

#4

As-tu quelques renseignements sur l’erreur dans tes logs (je ne sais pas où loggue ssmtp, je suppose que ça va aller dans /var/log/mail.* ou dans /var/log/syslog).

Ils n’ont pas plus de renseignements sur le sujet ?

STARTTLS semble effectivement fonctionnel de leur côté :

$ openssl s_client -starttls smtp -connect mail.infomaniak.ch:587
CONNECTED(00000003)
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO High-Assurance Secure Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=CH/postalCode=1227/ST=GE/L=Carouge/street=Av. de la Praille 26/O=Infomaniak Network SA/OU=Infomaniak/OU=PlatinumSSL Wildcard/CN=*.infomaniak.ch
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO High-Assurance Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO High-Assurance Secure Server CA
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFpzCCBI+gAwIBAgIQL+FEox4L6JaOd3et57j6lTANBgkqhkiG9w0BAQUFADCB
iTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxLzAtBgNV
BAMTJkNPTU9ETyBIaWdoLUFzc3VyYW5jZSBTZWN1cmUgU2VydmVyIENBMB4XDTEw
MDkwNzAwMDAwMFoXDTEyMTEwMjIzNTk1OVowgcgxCzAJBgNVBAYTAkNIMQ0wCwYD
VQQREwQxMjI3MQswCQYDVQQIEwJHRTEQMA4GA1UEBxMHQ2Fyb3VnZTEdMBsGA1UE
CRMUQXYuIGRlIGxhIFByYWlsbGUgMjYxHjAcBgNVBAoTFUluZm9tYW5pYWsgTmV0
d29yayBTQTETMBEGA1UECxMKSW5mb21hbmlhazEdMBsGA1UECxMUUGxhdGludW1T
U0wgV2lsZGNhcmQxGDAWBgNVBAMUDyouaW5mb21hbmlhay5jaDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANQtzUytw0m62vgymAphF2hO/PnzpMGksATw
5Gw77dPR+5zTIU0lhVQlf2vbqRyxDWWiNDXIrPAHoPWTLA1IaQ4j2teGiqjvO9M5
a6y/ppRtBxn67kODb4rkiUdOk0wg9NE3Xxx1H+PRLJJJCAaSAbFyEvzw/2BhfFns
+Wu1sHn02MHeNPsJSeHqoAmefTmpEhU703Oc8moWDEEeAdEniJWhQJveHsCnuIa5
s3ajh6mqjd0wKZxD2MkVp6EMsz1VKaafVTb/eGGjxmyM6wSuRBGyhIc/kg3fPUt1
EHk3MKuplsn+QM8vRT96+1ImOoAKUifXrBQPj1rA4GuBsZ2WKs8CAwEAAaOCAcgw
ggHEMB8GA1UdIwQYMBaAFD/VtdDWRHlQShejm4xK3LiwImRrMB0GA1UdDgQWBBSC
lA5+y3ffHufpbmRdBCKYB7iZzjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIw
ADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwRgYDVR0gBD8wPTA7Bgwr
BgEEAbIxAQIBAwQwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2Rv
LmNvbS9DUFMwTwYDVR0fBEgwRjBEoEKgQIY+aHR0cDovL2NybC5jb21vZG9jYS5j
b20vQ09NT0RPSGlnaC1Bc3N1cmFuY2VTZWN1cmVTZXJ2ZXJDQS5jcmwwgYAGCCsG
AQUFBwEBBHQwcjBKBggrBgEFBQcwAoY+aHR0cDovL2NydC5jb21vZG9jYS5jb20v
Q09NT0RPSGlnaC1Bc3N1cmFuY2VTZWN1cmVTZXJ2ZXJDQS5jcnQwJAYIKwYBBQUH
MAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTApBgNVHREEIjAggg8qLmluZm9t
YW5pYWsuY2iCDWluZm9tYW5pYWsuY2gwDQYJKoZIhvcNAQEFBQADggEBAE6HffJK
SQBWyPiWqUYfno88Gzt0c/bTZFV8/vCeKvnmCBO29SzsxJgF2aanUma76zRrNjzi
ziOYS1+MwVUZv1NIYrMk+9g1TNuFbaYmefGYO3e/MF67olUKDpl6fhWfAo6uh+k/
7Vhpa89fT5BLO0mccZpcCbm/BbIf+WsiOrrJe7hhvqk7xLUt54HsZe/9Y0rFtam+
0weOWT/cupyM1V+TEcAItRGvpuBJisDLGovYmPFg4Zdryq1hhl2R9t3gtMG54Dzk
D8QNl/Yc5F5PbIhFLuHJyn8o/Z2/9DUntsyFz/Ifgpl//+LdHo4wDqqM3HPj2RHf
gj+9mlzQXz5z750=
-----END CERTIFICATE-----
subject=/C=CH/postalCode=1227/ST=GE/L=Carouge/street=Av. de la Praille 26/O=Infomaniak Network SA/OU=Infomaniak/OU=PlatinumSSL Wildcard/CN=*.infomaniak.ch
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO High-Assurance Secure Server CA
---
Acceptable client certificate CA names
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO High-Assurance Secure Server CA
---
SSL handshake has read 3824 bytes and written 392 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 8D5D373DD8CE7C057DFFB1CA98526A4712D336214BCEDCD861E0E1BAD367B615
    Session-ID-ctx: 
    Master-Key: 7F15871C3A5A488F9DE20035B5A72C83FA87709803FBC74273BC00ED03F406C259B8537B30795BA05C622B99237254E7
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    Compression: 1 (zlib compression)
    Start Time: 1324585786
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
250 HELP

D’un autre côté, une rapide recherche google me donne en première page ce topic et un bug corrigé depuis 2009 !

Si ils ont plus d’infos sur le sujet, ça serait intéressant. Ou a défaut un lien vers une page qui en parle.
Et si c’est effectivement ça le problème, tu peux utiliser un autre MSA (msmtp par exemple) et faire un rapport de bug pour que le problème soit corrigé!

#5

J’ai ça :

[quote]Sep 13 10:35:10 smtp1 sm-mta[22859]: p8D8Z97U022859: cust.static.212-222-111-222.swisscomdata.ch [212.222.111.222] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

Il semble a priori que vous ne respectiez pas le protocole mail. Par exemple, le champ EHLO doit correspondre a un FQDN, ce qui n’est pas le cas ici.
(cf. ietf.org/rfc/rfc2821.txt, paragraphe 3.6)[/quote]
Ils bbloquaient mon hostname bidon, alors j’ai remplacé la valeur “firearrow” sur le paramètre hostname par mon IP public :

[quote]Vous envoyez bien un fqdn dans sa commande EHLO à présent, l’échange mail peut donc continuer.
Dans la trace TCPdump l’erreur actuelle survient dans l’échange TLS, qui n’est pas respecté.

RFC TLS : rfc-editor.org/rfc/rfc5246.txt
Paragraphe 7.3. Handshake Protocol overview :
Client Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

(Voir aussi sur Wikipedia, c’est plus clair : en.wikipedia.org/wiki/Transport_Layer_Security)

Dans le TCPdump, l’échange s’arrête au moment ou le serveur émet la “CertificateRequest”, car le client répond juste après du contenu “Application Data” sans envoyer préalablement son “ClientKeyExchange” et “CertificateVerify”. Le protocole n’est pas respecté et le serveur réponds donc “Unexpected message”.

20 1.660292000 84.16.68.123 192.168.70.51 TLSv1 Server Key Exchange, Certificate Request, Server Hello Done
21 1.661254000 192.168.70.51 84.16.68.123 TLSv1 Application Data
23 1.689149000 84.16.68.123 192.168.70.51 TLSv1 Alert (Level: Fatal, Description: Unexpected Message)[/quote]

Pourtant ils se targuent de supporter ssmtp en proposant une page de config en exemple : ssmtp.conf proposé par infomaniak

Bon faut que je déclare un bug à Debian… pfff la galère… la dernière fois que je l’ai fait, j’ai passé 1h dessus et ils m’ont envoyer proprement ballader sous pretexte que je donnais pas le nom du paquet. Faudra m’expliquer qu’elle est le nom du paquet qui gère l’installation de Debian ^^

Enfin là au moins c’est clair, c’est ssmtp.

Comme d’habitude, les logs sont très vagues :
Dans syslogd et mail.err j’ai : Unable to connect to “mail.infomaniak.ch” port 587
Un problème de protocol quoi :slightly_smiling:

Bon on a un beau bugs avec SSMTP en STARTLS au niveau de la gestion des certificats je crois ^^

#6

Voilà ce que Debian répond quand on se donne la peine de faire bien les choses.
Ils en ont rien à faire !!!

[quote]Your message didn’t have a Package: line at the very first line of the
mail body (part of the pseudo-header), or didn’t have a Package: line
at all. Unfortunatly, this means that your message has been ignored
completely.

Without this information we are unable to categorise or otherwise deal
with your problem report. Please resubmit your report to
submit@bugs.debian.org and tell us which package the
report is for. For help, check out
debian.org/Bugs/Reporting.

Your message was dated Thu, 05 Jan 2012 17:15:05 +0100 and had
message-id 4F05CC89.9060203@bluebirdcommunication.ch
and subject SSMTP ne respecte pas le RFC5246 lors du key Exchange en mode STARTTLS.
The complete text of it is attached to this message.

If you need any assistance or explanation please contact
owner@bugs.debian.org and include the the attached
message.

If you didn’t send the attached message (spam was sent forging your
from address), we apologize; please disregard this message.

– -1: owner@bugs.debian.org with problems

Sujet: SSMTP ne respecte pas le RFC5246 lors du key Exchange en mode STARTTLS
De : moi
Date : 05.01.2012 17:15
Pour : submit@bugs.debian.org

Package: SSMTP
Version: 2.62-3

=============================

Bonjour,

Il y a un problème lorsqu’on essaie de faire du STARTTLS.
Lors de l’échange de certificat et de clé, SSMTP ne répond pas avec l’échange de clé standard de la RFC5246, mais envoie directement les datas ce qui cause un échec de négociation.

mail -v -s “Test”
sdfjsdlkf.
.
Cc:
[<-] 220 smtp1.infomaniak.ch ESMTP Infomaniak Network Relay Mail Servers; Tue, 13 Sep 2011 10:35:09 +0200
[->] EHLO firearrow
[<-] 250 HELP
[->] STARTTLS
[<-] 220 2.0.0 Ready to start TLS
[->] EHLO firearrow
[<-]
send-mail: (firearrow)
Can’t send mail: sendmail process failed with error code 1

Veuillez trouver, ci-joint, mon fichier ssmtp.conf
Mon fournisseur ISP d’e-mail me donne le feedback suivant :

Dans la trace TCPdump l’erreur actuelle survient dans l’échange TLS, qui n’est pas respecté.

RFC TLS : rfc-editor.org/rfc/rfc5246.txt
Paragraphe 7.3. Handshake Protocol overview :
Client Server

ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data

(Voir aussi sur Wikipedia, c’est plus clair : en.wikipedia.org/wiki/Transport_Layer_Security)

Dans
le TCPdump, l’échange s’arrête au moment ou le serveur émet la
"CertificateRequest", car le client répond juste après du contenu
"Application Data" sans envoyer préalablement son “ClientKeyExchange” et
"CertificateVerify". Le protocole n’est pas respecté et le serveur
réponds donc “Unexpected message”.

20 1.660292000 84.16.68.123 192.168.70.51 TLSv1 Server Key Exchange, Certificate Request, Server Hello Done
21 1.661254000 192.168.70.51 84.16.68.123 TLSv1 Application Data
23 1.689149000 84.16.68.123 192.168.70.51 TLSv1 Alert (Level: Fatal, Description: Unexpected Message)

Le détail de mes tests se trouve ici : envoi-e-mail-depuis-le-shell-avec-ssmtp-en-starttls-error-t35231.html

En vous remerciant de votre réponse.

Meilleures salutations[/quote]