Topic: no auth con smarthost post agg. 9.1->9.2

[v8star]

Ciao a tutti,

dopo l'aggiornamento dalla v. 9.1 alla 9.2 uno sme di un mio cliente non è più riuscito a consegnare la posta allo smarthost con autenticazione (gestito in autonomia), utilizzato con successo fino a prima dell'aggiornamento e utilizzato senza problemi in concomitanza da altri sme ancora alla v. 9.1 e da altri client.

La posta in uscita resta tutta in coda e nei log compare questa voce:

uid=453, ddelay=0.095669, xdelay=0.095117, stat=Deferred (Connected_to_127.0.0.1_but_greeting_failed./Remote_host_said:_454_TLS_not_available_due_to_temporary_reason_[SSL_connect_attempt_failed_error:14090086:SSL_routines:SSL3_GET_SERVER_CERTIFICATE:certificate_verify_failed]451_Could_not_auth_to_mail_server/)

dato che questo server va fuori con un ip con una pessima reputazione (telecom) non posso consegnare la posta direttamente e al momento ho "trustato" l'ip sul mio smarthost ma è una cosa fatta in fretta e furia per sbloccare la situazione.

Ho visto anche che è stato aperto un bug https://bugs.contribs.org/show_bug.cgi?id=8207 a proposito: ci sono aggiornamenti?

grazie

[Stefano]

nessun aggiornamento

riporta li il tuo problema, in modo da essere reso partecipe di eventuali sviluppi e poter ev. fare dei test per vedere come venirne a capo

chi è il tuo smarthost?

[v8star]

il mio smarthost è questo:

https://www.libraesva.com/

quello a cui punta questo sme è una delle N istanze che gestisco che, nello specifico, è in un datacenter. Sempre al medesimo ce ne sono almeno altri 15 sme 9.1 o più vecchi che lo stanno usando per inviare mail (e per riceverle)

[Stefano]

ok, quindi, se ho capito bene, tu hai un host (tuo? del fornitore? isp?) dove gira quella roba li verso la quale routi tutta la tua posta in uscita..

pare che O SME non supporti più certi "protocolli" SSL (e se non li supporta più è perchè sono obsoleti/insicuri) O quell'appliance ha smesso di supportare alcuni "protocolli" che sono gli unici disponibili su SME 9.2

la sostanza è che SME 9.2 non riesce a negoziare con l'appliance un protocollo sicuro, ergo abortisce.

Per cortesia, tutti i dettagli (meno quelli "sensibili") sul bug, grazie

[v8star]

si è tutta roba nostra che gira su ferro nostro. Questo host fa da antispam/mx per i domini dei clienti sparando poi  la posta pulita sull'ip pubblico:25 del cliente (filtrato da fw o da Allowhosts smtpd per i clienti che ancora credono che un fw sia un costoso optional) e viene usato anche come smarthost per i clienti che dispongono di connettività dei poveri, come in questo caso

la versione dell'antispam è la medesima da un mese e mezzo, questo problema è fresco di una settimana da questo cliente, dove gli abbiamo rifatto il server e aggiornato sme.

quando ho tempo raccolgo il tutto

[Stefano]

ci farebbe veramente comodo

[Stefano]

Leggi cosa Charlie Brady ha concluso (nel bug)..
Non è un qualcosa di definitivo, ma io penso che abbia individuato la causa del problema
In altre parole, contatta chi di dovere di libraesva e mandagli il link al bug

[v8star]

ho mandato a libra il link della discussione, vediamo se c'è qualche progresso.

Comunque chiedendo loro quali protocolli sono supportati mi è stato riportato che "tutti i protocolli gestiti da OpenSSL attualmente considerati sicuri. Come da documentazione OpenSSL "run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses"."

anche se mi viene riportato che nelle ultime release anche tls 1.0 è stato disabilitato, ma comunque questi ultimi agg. non sono nel delta temporale di questo problema.

Spero che coinvolgere anche libra possa servire nella risoluzione del bug. Se ti serve qualche altro log + specifico da sme fammi sapere che lo posto.

grazie

[v8star]

altra cosa curiosa incrociando problemi sorti recentemente:
sempre su questo server presso il cliente, venerdì, outlook ha smesso di funzionare l'smtp verso sme, dando errore praticamente subito dopo l'invio/ricezione. Un mio collega ha cambiato smtp nei client impostando direttamente libra come smtp per risolvere direttamente il problema.

Da un altro cliente, dove giovedì è stato deployato una nuova istanza di sme 9.2 con la stessa conf di flusso posta e nonostante abbia estrapolato il certificato ssl di sme e importato nel server terminal dove girano i client outlook, continua a darmi il warn del certificato all'invio ricezione. Pop è usato solo in lan (in chiaro) e a questo punto l'errore è nella parte smtp dove è stato impostato in auto nella cifratura di Outlook

E sono già due, non è più una coincidenza/caso. Mi do una scrollata ai log.

[Stefano]

grazie per tutto

fai riferimento al bug e, se riesci, prova a fare gli stessi test che sta facendo John Crisp

relativamente al problema col certificato self signed, outlook è un PITA con quel tipo di certificati.. raramente sono riuscito a farglieli digerire (poi ho semplicemente abolito outlook da tutti i miei clienti)

[v8star]

no per il cert ho fatto io una vaccata: testando con la mail di admin mi sono trovato questa mail:

/etc/cron.daily/conf-mod_ssl:

You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:State or Province Name (full name) []:Locality Name (eg, city) [Default City]:Organization Name (eg, company) [Default Company Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, your name or your server's hostname) []:Email Address []:


e ho capito subito che il campo dn nella rubrica era sballato

[v8star]

riesumo questo post per aggiornamenti in merito al problema, putroppo ancora presente...

l'errore è relativo al modulo smtp-auth-proxy che non riesce ad autenticarsi con lo smarthost, non per mancata "decodifica" del certificato come originariamente pensato.

Se disabilito il proxy le mail partono regolarmente sempre tramite il solito isp (concedendogli il relay)

questo è il log relativo, ovviamente i nomi degli host sono di fantasia

2018-11-23 12:29:16.519797500 Resolved [localhost]:26 to [127.0.0.1]:26, IPv4
2018-11-23 12:29:16.520979500 Binding to TCP port 26 on host 127.0.0.1 with IPv4
2018-11-23 12:29:16.521268500 Setting gid to "99 99"
2018-11-23 12:29:16.521340500 Setting uid to "99"
2018-11-23 12:29:25.038412500 Net::SMTP>>> Net::SMTP(2.31)
2018-11-23 12:29:25.038458500 Net::SMTP>>>   Net::Cmd(2.29)
2018-11-23 12:29:25.038487500 Net::SMTP>>>     Exporter(5.63)
2018-11-23 12:29:25.038538500 Net::SMTP>>>   IO::Socket::INET(1.31)
2018-11-23 12:29:25.038567500 Net::SMTP>>>     IO::Socket(1.31)
2018-11-23 12:29:25.038616500 Net::SMTP>>>       IO::Handle(1.28)
2018-11-23 12:29:25.070278500 Net::SMTP=GLOB(0x18c1a60)<<< 220 mail.isp.it ESMTP Postfix
2018-11-23 12:29:25.070427500 Net::SMTP=GLOB(0x18c1a60)>>> EHLO srvmail.customer.it
2018-11-23 12:29:25.102638500 Net::SMTP=GLOB(0x18c1a60)<<< 250-mail.isp.it
2018-11-23 12:29:25.102683500 Net::SMTP=GLOB(0x18c1a60)<<< 250-PIPELINING
2018-11-23 12:29:25.102714500 Net::SMTP=GLOB(0x18c1a60)<<< 250-SIZE 50000000
2018-11-23 12:29:25.102744500 Net::SMTP=GLOB(0x18c1a60)<<< 250-ETRN
2018-11-23 12:29:25.102774500 Net::SMTP=GLOB(0x18c1a60)<<< 250-STARTTLS
2018-11-23 12:29:25.102814500 Net::SMTP=GLOB(0x18c1a60)<<< 250-AUTH LOGIN GSSAPI DIGEST-MD5 PLAIN CRAM-MD5
2018-11-23 12:29:25.102847500 Net::SMTP=GLOB(0x18c1a60)<<< 250-AUTH=LOGIN GSSAPI DIGEST-MD5 PLAIN CRAM-MD5
2018-11-23 12:29:25.102878500 Net::SMTP=GLOB(0x18c1a60)<<< 250-ENHANCEDSTATUSCODES
2018-11-23 12:29:25.102908500 Net::SMTP=GLOB(0x18c1a60)<<< 250-8BITMIME
2018-11-23 12:29:25.102938500 Net::SMTP=GLOB(0x18c1a60)<<< 250 DSN
2018-11-23 12:29:25.103066500 Net::SMTP=GLOB(0x18c1a60)>>> STARTTLS
2018-11-23 12:29:25.133906500 Net::SMTP=GLOB(0x18c1a60)<<< 220 2.0.0 Ready to start TLS
2018-11-23 12:29:25.179367500 Net::SMTP::SSL=GLOB(0x18c1a60)>>> RSET
2018-11-23 12:29:25.179467500 Net::SMTP::SSL=GLOB(0x18c1a60)<<< 
M�
I�Aya‘r³`´Ä÷§ôÛRìÿˆ‹ð[=òÀ-/š56¯%çã†ñ¥øúâ%tNº>”(
&L#M{¬OK3

�F¨)<øɳ­ò
œÂYö£{dÐiç³eSÉNQ£°GTvÞÓ²~F:•€Üÿ¶»†Œ¹ÁÔŽU>Q<@l{]øœã–V�­p­9£0ž²‡Ñ±‚‚ia#½ŒøŒÎD<
´Ø%'˜îacÎîÝX¬<
Ãeî
2018-11-23 12:29:25.179521500 Use of uninitialized value $code in substr at /usr/share/perl5/Net/Cmd.pm line 366, <GEN2> line 1.
2018-11-23 12:29:25.179539500 Argument "" isn't numeric in numeric eq (==) at /usr/share/perl5/Net/SMTP.pm line 522, <GEN2> line 1.
2018-11-23 12:29:25.179577500 Net::SMTP::SSL=GLOB(0x18c1a60)>>> EHLO srvmail.customer.it
2018-11-23 12:29:25.179618500 Net::SMTP::SSL=GLOB(0x18c1a60)<<< \4†Ö#¾-ŒutÖ   ‡
2018-11-23 12:29:25.179651500 Use of uninitialized value $code in substr at /usr/share/perl5/Net/Cmd.pm line 366, <GEN2> line 2.
2018-11-23 12:29:25.179665500 Argument "" isn't numeric in numeric eq (==) at /usr/share/perl5/Net/SMTP.pm line 512, <GEN2> line 2.
2018-11-23 12:29:25.179742500 Trying authentication method LOGIN
2018-11-23 12:29:25.182874500 Net::SMTP::SSL=GLOB(0x18c1a60)>>> AUTH LOGIN
2018-11-23 12:29:25.182931500 Net::SMTP::SSL=GLOB(0x18c1a60)<<< µ¢kÞEþ䇦“Ïkˆ sl XdE,Ý0´UWÔöÊìz/%ÚSeè«Ï¨¯ùãO½GýÖáåAj1æ,à¢Wœo¿e,•¾’¢šõ|ÐѧĒZÇ#sia[†,¾È¥Ï‰_þjW<¯¿Ži½0����Use of uninitialized value $code in substr at /usr/share/perl5/Net/Cmd.pm line 366, <GEN2> line 3.
2018-11-23 12:29:25.182976500 Argument "" isn't numeric in numeric eq (==) at /usr/share/perl5/Net/SMTP.pm line 156, <GEN2> line 3.
2018-11-23 12:29:25.182993500 SMTP authentication (with LOGIN) with ISP server failed
2018-11-23 12:29:25.183009500 Trying authentication method GSSAPI
2018-11-23 12:29:25.184203500 exception during authentication (with GSSAPI): No SASL mechanism found
2018-11-23 12:29:25.184204500  at /usr/share/perl5/vendor_perl/Authen/SASL.pm line 77
2018-11-23 12:29:25.184204500  at /usr/share/perl5/Net/SMTP.pm line 143
2018-11-23 12:29:25.184204500
2018-11-23 12:29:25.184224500 Trying authentication method DIGEST-MD5
2018-11-23 12:29:25.187044500 Net::SMTP::SSL=GLOB(0x18c1a60)>>> AUTH DIGEST-MD5
2018-11-23 12:29:25.187094500 SMTP authentication (with DIGEST-MD5) with ISP server failed
2018-11-23 12:29:25.187110500 Trying authentication method PLAIN
2018-11-23 12:29:25.187602500 Net::SMTP::SSL=GLOB(0x18c1a60)>>> AUTH PLAIN Y2Fycm96emVyaWFjZXJldHRhAGNhcnJvenplcmlhY2VyZXR0YQBjYXJzbXRwY2VyMjAxNUA=
2018-11-23 12:29:25.187647500 SMTP authentication (with PLAIN) with ISP server failed
2018-11-23 12:29:25.187663500 Trying authentication method CRAM-MD5
2018-11-23 12:29:25.188020500 Net::SMTP::SSL=GLOB(0x18c1a60)>>> AUTH CRAM-MD5
2018-11-23 12:29:25.188063500 SMTP authentication (with CRAM-MD5) with ISP server failed
2018-11-23 12:29:25.188256500 all SMTP authentication methods failed
2018-11-23 12:29:25.188288500 Net::SMTP::SSL=GLOB(0x18c1a60)>>> QUIT

[ReetP]

Abbiamo un "bug" aperto per questo problema

La soluzione qui dentro ti farà lavorare, ma NON è una buona soluzione

https://bugs.contribs.org/show_bug.cgi?id=8207#c40

Lo faremo e ripareremo il prima possibile.

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

We stil have a 'bug' open for this issue

The workaround in here will get you working, but it is NOT a good solution

https://bugs.contribs.org/show_bug.cgi?id=8207#c40

We will and get it fixed as soon as possible.

[v8star]

Abbiamo un "bug" aperto per questo problema

La soluzione qui dentro ti farà lavorare, ma NON è una buona soluzione

https://bugs.contribs.org/show_bug.cgi?id=8207#c40

Lo faremo e ripareremo il prima possibile.

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

We stil have a 'bug' open for this issue

The workaround in here will get you working, but it is NOT a good solution

https://bugs.contribs.org/show_bug.cgi?id=8207#c40

We will and get it fixed as soon as possible.

l'ho provata al tempo ma non mi funziona (riprovando anche oggi): mi viene proprio rifiutata la connessione al demone smtp proxy. Da qua sono andato a scavare ulteriormente, abilitando il debug del proxy ed estrapolando il log di cui sopra.
il problema relativo di attacchi mitm sarebbe il male minore nel mio caso, il mio workaround è fare da relay ai vari sme senza auth tutti dietro ip statico, ma dato che siamo in aria di cambiamenti volevo "sanare" questa situazione, di cui non mi occuperò più personalmente.

grazie