Dotaz: komunikace mailserveru - MAIL FROM

[f1lo]

Dobrý den, řeším poměrně nepříjemný problém odesílání emailu z mého SMTP na doménu administer.cz. Email nedorazí a po 6 dnech se vrátí s chybovou hláškou:

info@administer.cz: lost connection with
mail3.administer.cz[80.95.104.194] while sending MAIL FROM

Je ale zajímavé, že mail3.administer.cz není vůbec dostupný pomocí pingu, a mail4.administer.cz zase ano. Ale pokud to mají nastaveno nějak dynamicky, tak by byla sakra náhoda, že mi to vždy z Gmailu odejde v pořádku a z mého SMTP nikoliv. Pokud odešlu email například z Gmailu, email v pohodě dorazí. Může být tedy nějaká chyba na straně mého SMTP? Děkuji

---

---

Odpovědi

[Jendа]

tcpdump, postqueue -f

[Filip Jirsák]

Ano, chyba samozřejmě může být na straně vašeho serveru. Podívejte se do logů vašeho serveru, pravděpodobně tam o té chybě něco bude. Je dost pravděpodobné, že správce toho cílového serveru vymyslel další geniální způsob, jak odmítat e-maily (a říká tomu ochrana proti spamu), a váš server tu podmínku nesplňuje.

[alles32]

pic

ping muze bejt zariznutej na firewalu. lepe je dostupnost sluzby zjistovat nmapem

$ nmap -p 25 mail3.administer.cz

Nmap scan report for mail3.administer.cz (80.95.104.194)
Host is up (0.032s latency).
PORT   STATE SERVICE
25/tcp open  smtp

ze kteryho je zrejmy, ze na TCP 25 neco posloucha

[R]

Staci "telnet blabla 25".

[lertimir]

A na telnetu rukama realizovat SMTP nebo ESMTP protokol a je videt proc to protejsek zarizne.

[MMMMMMMMM]

Spoj se s postmasterem daného server a zeptej se jej, proč/jak tě blokuje.

[pupu]

Ta hlaska je v poradku - dva servery z toho seznamu vubec neposkytuji SMTP. Spis je otazka, proc Tvuj mailserver nezkousi ty ostatni a pokud zkousi, proc to neprojde pres ne. Chce to logy, pripadne zkusit rucne, treba takhle:

[root@hactar ~]# telnet mail.administer.cz 25
Trying 80.95.104.194...
Connected to mail.administer.cz.
Escape character is '^]'.
220 mail.administer.cz Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at  Sat, 14 Mar 2015 10:16:21 +0100
ehlo hactar.pupu.cz
250-mail.administer.cz Hello [88.208.110.148]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM
250-AUTH GSSAPI NTLM
250-X-LINK2STATE
250-XEXCH50
250 OK
mail from: pupu@pupu.cz
250 2.1.0 pupu@pupu.cz....Sender OK
rcpt to: postmaster@administer.cz
250 2.1.5 postmaster@administer.cz
data
354 Start mail input; end with <CRLF>.<CRLF>
^]
telnet> quit
Connection closed.

[f1lo]

Tak tohle jsem našel v logu při komunikaci se serverem administer.cz: postfix/smtp[26268]: warning: TLS library problem: 26268:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:339:

Takže předpokládám bude potřeba aktualizovat nějaký balíček openssl? Přepodkládám openssl? Ještě se zkusím podívat na internetu, přiznám jsem, že tenhle příspěvek píši a ještě jsem nezkoušel chybovou hlášku hledat na netu.

[Jendа]

openssl s_client -connect mail.administer.cz:25 -starttls smtp

New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit

Ne, spíš pro ně povolit slabé šifry a protokoly. Bohužel netuším jak se to dá udělat, možná jim budeš muset nastavit wrapper.

[Filip Jirsák]

Spíš to vypadá, že máte v knihovně OpenSSL natvrdo vypnutou podporu SSLv3 - některé distribuce to tak myslím udělaly, místo aby se vypnula podpora SSLv3 v každé jednotlivé aplikaci konfiguračně, mají OpenSSL zkompilované bez podpory SSLv3. Důvod je ten, že pro SSLv3 je známo dost zranitelností a důrazně se doporučuje místo toho používat alespoň TLS 1.0 (což je nástupce SSLv3).

No a protistrana zřejmě při šifrované komunikaci podporuje jen SSLv3 a nic novějšího. Divné je, že se ty servery ale nedokážou dohodnout na tom, že nepodporují žádnou společnou šifru a že tudíž budou komunikovat nešifrovaně. Máte v smtp_tls_mandatory_protocols nebo smtp_tls_protocols nakonfigurované, že Postfix nemá používat SSLv3? Protože Postfix asi nezjistí, že to OpenSSL knihovna nepodporuje, a je myslím potřeba mu to explicitně říci.

Případně můžete v konfiguraci nastavit, že se pro danou doménu nemá používat SSL/TLS, ale tím problém jenom obejdete pro jednu známou problémovou doménu (může se to hodit, pokud potřebujete pro tu doménu hlavně už odesílat e-maily, a mít klid na vyřešení podstaty problému).

[f1lo]

Dobrý den, děkuji za vaše reakce. Snažil jsem se postupovat podle návodu zde: http://disablessl3.com/#postfix

tedy do /etc/postfix/main.cf přidat následující:
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

a do /etc/dovecot/dovecot.conf přidat následující:
ssl_protocols = !SSLv2 !SSLv3

Následně jsem provedl restart služeb:
/etc/init.d/postfix restart
/etc/init.d/dovecot restart

a zkusil jsem odeslat testovací email na nějakou z adres domény administer.cz, ovšem v logu se zobrazuje stejné chybové hlášení, provedl jsem tedy nějaký krok chybně?

[f1lo]

Nejspíše jsem testováním přišel na správnou konfiguraci:
/etc/postfix/main.cf přidat následující:
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3

a do /etc/dovecot/dovecot.conf přidat následující:
ssl_protocols = !SSLv2 !SSLv3

Následně jsem provedl restart služeb:
/etc/init.d/postfix restart
/etc/init.d/dovecot restart

Podle logu email již odešel bez jakékoliv chyby. Ještě počkám na zpětnout odpověď od člověka, kterému jsem email posílal. Děkuji za vaši podporu.

[f1lo]

Tak jsem se asi unáhlil, v logu se objevuje stále stejná chybová hláška a server stále odmítá spojení, nevíte kde by mohl být problém?

[f1lo]

Určitě si můžete přes smtp_tls_per_site nastavit, že pro danou doménu se TLS nemá vůbec používat. Pokud to budete dál ladit, nastavte si smtp_tls_loglevel alespoň na 2, ať máte v logu zapsáno, jak přesně se o TLS vyjednávalo.

Nejsem si jist, jak přesně to má fungovat, pokud se při StartTLS nepodaří dohodnout šifra – zda je v protokolu možnost návratu k nešifrovanému spojení, případně zda to umí udělat Postfix (spojení ukončit a navázat nové s tím, že už se o TLS nebude pokoušet). Další věc je zkusit kontaktovat administrátora toho cílového serveru, protože pokud ten server podporuje jen SSLv3, bude s tím podle mne mít problémy a je v jeho vlastním zájmu upgradovat na bezpečnější protokoly.

[Filip Jirsák]

Ještě jsem to zkoušel – pořád to hlásí wrong version number? Když jsem to zkoušel, poštovní servery administer.cz podporují TLSv1, ale posílají expirovaný certifikát. To je pak asi správně, že váš server odmítne pokračovat a spojení ukončí. To ale musí vyřešit správce administer.cz (a vy zatím můžete pro tu doménu TLS úplně vypnout, jak jsem psal v předchozím komentáři) Akorát mi není moc jasná souvislost mezi touhle chybou a tou wrong version number, podle mne jsou to dvě nezávislé chyby.

[f1lo]

Dobrý den,

děkuji za vaše reakce, v logu jsem si po vaší doporučované úpravě úrovně logování všiml, že využívají TLSv1. Expirace certifikátu jsem si již nevšiml. Přidal jsem tedy doménu do výjimek a již to nejspíše frčí v pořádku, alespoň v logu se již žádná chyba nezobrazuje.

Informuji o tomto faktu administer.cz, snad se toho ujme nějaká kompetentní osoba, děkuji za vaši pomoc.

[Josef Kufner]

Divné je, že se ty servery ale nedokážou dohodnout na tom, že nepodporují žádnou společnou šifru a že tudíž budou komunikovat nešifrovaně.

To je snad dobře, ne?

[f1lo]

Z důvodu bezpečnosti ano, ovšem z uživatelského hlediska to až tak dobré není . Například z Gmailu mi email na administer.cz odejde v pořádku.

[Josef Kufner]

Z uživatelského hlediska je potřeba to opravit.

[f1lo]

Teď vám asi nerozumím. Myslel jste, že je dobře, že nebudou komunikovat nešifrovaně, pokud se nedohodnou na společném šifrování, které oba poštovní servery podporují? S tímto souhlasím, ale opravu by v tom případě museli provést na straně administer.cz, což je pro mě nevhodné čekat na opravu (podporu novějšího šifrování) z jejich strany, navíc takových serverů může být více.

[Filip Jirsák]

Dobře by to bylo, pokud by SSL komunikace byla povinná. Pokud je ale nakonfigurováno „použij ji, pokud je k dispozici“, má se použít nešifrovaná komunikace, pokud se šifrované spojení nepodaří navázat.