On 21.6.2019 15:01, Peter Rosa wrote:
Port 587 vyuzivam hlavne ja na posielanie mailov z weboveho servera a z
klientov v lokalnej sieti, neviem, ci ho pouziva aj nejaky server z
internetu.
Nemel by. 587 neni o SSL/TLS, ale o "submission". Je to port urceny pro
koncove uzivatele pres ktery mail vstupuje do prenosoveho retezce. Neni
to port pro komunikaci mezi MTA.
Problem je so STARTTLS - z nejakeho dovodu cca 2 % serverov zvonka nie
su schopne poslat mojmu serveru nic. Vo /var/log/maillog sa objavi
NOQUEUE: connect from XXX [IP.A.D.R.E.S.A] a ziadna sprava neprejde.
Hm ...
A nakolik si jsi jisty, ze ti stroj IP.A.D.R.E.S.A nejakou zpravu vubec
poslat chtel ? Takovejhle pripadu mam log plnej - jenze podl evseho jde
v naproste vetrine pripadu o sitove scannery, ktere zkoumaji kde na 25
bezi SMTP servery (a nasledne pak ten seznam prochazi dalsi tester,
ktery zjistuje jestli nejaky z nich neni open-relay).
TLS uz na serverech mame, no, nerad bych kecal, pres deset let urcite, a
workaround s ad-hoc vypinamim STARTTLS jsme za celou dobu potreboval asi
trikrat ...
Takze rada prvni - ujistit se, ze problem, ktery resis, opravdu existuje.
Pripustme, jako pracovni hypotezu, ze existuje. Pak bych primarne resil
pricinu - proc se vzdalenemu serveru spojeni nepodari. A
nejpravdepodobnejsi duvod je, ze mas mnozinu podporovanych
protokolu/sifer/MAC nastavenou tak, ze se vzdalenym serverem nemate
spolecny prunik. Coz me ale docela prekvapuje, protoze ja jsem co se
mnoziny podporovanych veci hodne restriktivni a pritom tenhle problem
nemam. Mam (v access):
TLS_Srv_features:.
Options=+SSL_OP_CIPHER_SERVER_PREFERENCE;
CipherList=HIGH:!ADH:!EXPORT56:!aNULL:!DH:!CAMELLIA:!ECDSA:!kECDHe:!SRP:!PSK:!MD5:-kRSA:@STRENGTH;
TLS_Clt_features:.
CipherList=HIGH:!ADH:!EXPORT56:!aNULL:!DH:!CAMELLIA:!ECDSA:!kECDHe:!SRP:!PSK:!MD5:-kRSA:@STRENGTH
... takze efektivne pripoustim jen 12 kombinaci - a zjevne to staci.
Vyjimky mam jen tri:
Try_TLS:spamfree.cz NO
Try_TLS:virusfree.cz NO
Try_TLS:dell.com NO
A ty tam jsou uz strasne dlouhoo, takze je klidne mozne, ze uz nejsou treba.
Takze rada druha - zjistit co tem protistranam opravdu vadi. Pokud ti to
nereknou jejich spravci v ramci reseni problemu, ze k tobe nemuzou
protlacit zadny email, pak potrebujes TCPDUMP porizeni na tve strane.
Kompletni pakety, cela session (nektera z tech, ktere selzou). Jinymi
slovy, az se ti zase v logu objevi nejaky takovy zdroj, tak zacnes
komunikaci s nim dumpovat - pokud ma opravdu mail, ktery ti chce
dorucit, zkusi doruceni za nejakou dobu znovu. Pokud uz se ten stroj
nikdy neozve, pak ti ve skutecnosti zadny email dorucit nechtel a
nemusis to resit.
Chcem to vyriesit nejako vseobecne. Napadlo ma riesenie, ze na porte 25
by neponukal STARTTLS nikomu, ponukol by ho iba na 587. Ale neviem, ci:
A) je to spravne riesenie ?
Neexistuje "spravne reseni". Nemusis TLS jako server nabizet. Prenos pak
bude probihat nesifrovane, ale pokud ti to nevadi, tak to nevadi. Muze
ti to ale snizit reputaci.
B) ako upravit konfiguraciu sendmailu ?
Zakazat TLS na konkretnim maileru lze pomoci optionu S parametru M= v
DAEMON_OPTIONS(...).
Takze k tomu co tam uz u M= mas muzes prihodit 'S'
Ja bych ale touhle cestou sel az jako zcel aposledni moznost a primarne
bych se pokusil vyresit pricinu problemu (po overeni, ze nejaky problem
skutecne existuje).
Dan
Vopred dakujem pekne za postrcenie. Prajem prijemny vikend,
--
Peter Rosa
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
