Puncte:1

Postfix - Depanarea timpilor de conexiune pentru toate serverele, cu excepția unuia

drapel lr
Cos

Am moștenit un server postfix care rulează pe RedHat. Este o versiune nedocumentată, dar critică pentru operațiunile de afaceri (Nu ne place tuturor?)

A dezvoltat probleme cu livrarea e-mailurilor întârziate și întârziate. Problemele au fost raportate pentru prima dată acum câteva săptămâni, dar ar putea reveni pe o perioadă nedeterminată de timp.

Experiența mea *nix este ruginită, dar am reușit să cercetez sistemul suficient pentru a determina că atunci când serverul se confruntă cu întârzieri, acesta raportează expirări de conexiune către releele SMTP din amonte ale organizației mele.

Exemplu de eroare:

*3D27412A016
4187 Marți, 19 aprilie 17:04:26
[email protected]

(livrare suspendată temporar: conectați-vă la UpstreamRelayA4.doi.net[10.xx.xx.206]:25: Conexiune a expirat)

[email protected]*

Cu toate acestea, proprietarii releului din amonte raportează că nu au erori de potrivire în jurnalele lor de la acest server SMTP. Pentru organizația mea există o singură înregistrare MX cu 4 servere releu incluse. Toate cele 4 pot fi accesate de pe serverul meu SMTP prin telnet pe portul 25, cu toate acestea, 3 dintre cele 4 expiră în jurnalele postfix.

Sfaturi despre cum să găsiți de ce Postfix crede că expiră?

Adăugat 20.4.22 - ieșire postconf -n

    [USERNAME@mailer ~]$ postconf -n

alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

broken_sasl_auth_clients = da

director_comandă = /usr/sbin

config_directory = /etc/postfix

daemon_directory = /usr/libexec/postfix

debug_peer_level = 2

debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb
 
$daemon_directory/$process_name $process_id & sleep 5

disable_vrfy_command = da

html_directory = nr

inet_interfaces = all

inet_protocols = ipv4

local_recipient_maps =

mail_owner = postfix

mail_spool_directory = /var/mail

cutie_poștală_size_limit = 0

mailq_path = /usr/bin/mailq.postfix

director_manpage = /usr/share/man

maximal_queue_lifetime = 1d

limită_dimensiunea mesajului = 30720000

mydestination = $myhostname, localhost.$mydomain, localhost

myhostname = mailer.domain.org.com

rețelele mele = 

127.0.0.0/8,165.83.0.0/16,10.0.0.0/8,64.241.25.0/24,172.16.0.0/12

myorigin = $mydomain

calea_newaliases = /usr/bin/newaliases.postfix

director_codă = /var/spool/postfix

readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES

relayhost = relayLOCATION.parentorg.com

sample_directory = /usr/share/doc/postfix-2.10.1/samples

sendmail_path = /usr/sbin/sendmail.postfix

setgid_group = postdrop

smtp_tls_note_starttls_offer = da

smtp_use_tls = da

smtpd_delay_reject = da

smtpd_helo_required = da

smtpd_helo_restrictions = 
permis_mynetworks,reject_non_fqdn_helo_hostname,reject_invalid_helo_hostname,permit

smtpd_policy_service_max_idle = 5s

smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

smtpd_sasl_auth_enable = da

smtpd_sasl_authenticated_header = da

smtpd_sasl_local_domain =

smtpd_sasl_security_options = noanonymous

smtpd_sender_restrictions = permit_mynetworks,reject_non_fqdn_sender,permit

smtpd_tls_CAfile = /etc/postfix/ssl/mailer_DOMAIN_ORG_COM.pem

smtpd_tls_auth_only = nr

smtpd_tls_cert_file = /etc/postfix/ssl/mailer_DOMAIN_ORG_COM.crt

smtpd_tls_key_file = /etc/postfix/ssl/mailer_DOMAIN_ORG_COM.key

smtpd_tls_loglevel = 1

smtpd_tls_security_level = mai

smtpd_use_tls = da

tls_random_source = dev:/dev/urandom

transport_maps = hash:/etc/postfix/transport

[USERNAME@mailer ~]$

Adăugat 20.4.22 - ieșire postconf -M

[USERNAME@mailer ~]$ postconf -M
smtp inet n - n - - smtpd
pickup fifo n - n 60 1 pickup
curatare unix n - n - 0 curatare
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rescrie unix - - n - - trivial-rescriere
bounce unix - - n - 0 bounce
amână unix - - n - 0 săritură
trace unix - - n - 0 săritură
verifica unix - - n - 1 verifica
spălați Unix n - n 1000? 0 culoare
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
releu unix - - n - - smtp -o fallback_relay=
showq unix n - n - - showq
eroare unix - - n - - eroare
arunca unix - - n - - arunca
unix local - n n - - local
unix virtual - n n - - virtual
lmtp unix - - n - - lmtp
nicovală unix - - n - 1 nicovală
scache unix - - n - 1 scache
maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${destinatar}
old-cyrus unix - n n - - pipe flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user}
cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}
uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($destinatar)
ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($destinatar)
bsmtp unix - n n - - steaguri pipe=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $destinatar
reîncercați Unix - - n - - eroare
proxywrite unix - - n - 1 proxymap
[USERNAME@mailer ~]$

Adăugat 20/04/22 - Dispozitive între relee de e-mail

Nu avem vizibilitate în rețea sau dispozitive de securitate dintre relee. Traceroute indică doar 3 hopuri, toate acestea fiind cel mai probabil routere standard pe baza adreselor lor IP din aspectul rețelei noastre.

Adăugat 20/04/22 - versiunea Postfix

Postfix pare să fie versiunea 2.10.1, care ar plasa instalarea în jurul anului 2013 conform paginii Postfix Releases

Adăugat 22/04/22 - testul de conectare openssl

[USERNAME@mailer ~]$ openssl s_client -connect UPSTREAM_RELAY.ORG.net:25 -starttls smtp -crlf
CONECTAT(00000003)
adâncime=1 DC = net, DC = ORG, CN = CA_Server
verify error:num=20:nu se poate obține certificatul de emitent local
---
Lanț de certificate
 0 s:/C=US/ST=STATE/L=CITY/O=PARENT_ORG/OU=PARENT_ORG/CN=UPSTREAM_RELAY.ORG.net
   i:/DC=net/DC=ORG/CN=CA_Server
 1 s:/DC=net/DC=ORG/CN=CA_Server
   i:/CN=ORGRootCA2
---
Certificat de server
-----ÎNCEPE CERTIFICAT-----

[Conținutul certificatului a fost eliminat]

-----CERTIFICAT FINAL-----
subiect=/C=US/ST=STATEA/L=CITY/O=PARENT_ORG/OU=PARENT_ORG/CN=UPSTREAM_RELAY.ORG.net
emitent=/DC=net/DC=ORG/CN=CA_Server
---
Nu s-au trimis nume de CA de certificat de client
Rezumat peer signing: SHA1
Cheie Temp Server: ECDH, P-384, 384 biți
---
SSL handshake a citit 5841 de octeți și a scris 538 de octeți
---
Nou, TLSv1/SSLv3, Cipher este ECDHE-RSA-AES256-SHA384
Cheia publică a serverului este de 2048 biți
Este acceptată renegocierea sigură
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Sesiune SSL:
    Protocol: TLSv1.2
    Cifr: ECDHE-RSA-AES256-SHA384
    ID sesiune: [ELIMINAT]
    ID-ul sesiunii-ctx:
    Cheie principală: [ELIMINAT]
    Key-Arg: Niciuna
    Principalul Krb5: Nici unul
    Identitate PSK: Niciuna
    Sugestie de identitate PSK: Niciuna
    Ora de începere: 1650649689
    Timeout: 300 (sec)
    Verificați codul de returnare: 20 (nu se poate obține certificatul de emitent local)
---
250 XSHADOWREQUEST
 (Consola funcțională după aceasta)

Adăugat 22/04/22 - Maillog grep pentru serverul care nu funcționează

[USERNAME@mailer ~]$ sudo mailq | grep UPSTREAM_RELAY_103.ORG.net

(livrarea a fost suspendată temporar: conversația cu UPSTREAM_RELAY_103.ORG.net[10.x.x.125] a expirat în timpul trimiterii sfârșitului datelor -- mesajul poate fi trimis de mai multe ori)

(conversația cu UPSTREAM_RELAY_103.ORG.net[10.x.x.125] a expirat în timpul trimiterii sfârșitului datelor -- mesajul poate fi trimis de mai multe ori)

[S-au eliminat duplicatele, toate intrările pentru acel server sunt exact aceleași două mesaje]

Editare finală 27.04.2022

În depanarea săptămâna trecută, am descoperit că /etc/resolv.conf avea un server de nume care nu mai există. După eliminarea acestui lucru și repornirea postfixului, se pare că nu mai primim timeout-uri în jurnale, iar e-mailul curge rapid.

După cum a menționat @anx în comentarii, acest lucru nu are prea mult sens în legătură cu expirarea conexiunii, dar de îndată ce a fost remediat și postfix a fost repornit, trimiterile noastre de ieșire au crescut drastic în viteză și nu am avut niciuna. probleme de întârziere din moment ce, în ciuda adăugării a peste 20.000 de e-mailuri de testare suplimentare pe zi (o creștere cu aproximativ 30% față de volumul obișnuit de e-mail).

Cos avatar
drapel lr
Cos
@anx Informații adăugate la postare. Din câte putem spune, rezoluția numelui este ok. Nu au existat modificări documentate recent și putem ajunge la toate cele 4 relee de ieșire prin telnet pe portul 25 cu numele de gazdă și IP fără nicio problemă. Avem câteva înregistrări ale numărului de e-mailuri de ieșire. Fără modificări recente ale volumului. Avem o medie de 50.000-70.000 de ieșiri pe zi și ne aflăm încă în acest interval dacă renunțați la trimiterile mele în vrac, concepute pentru a induce în mod intenționat restanța pentru depanare. Repornirea postfix nu oferă erori vizibile, dar dacă există un jurnal\verbose de verificat, sunt bucuros să încerc.
anx avatar
drapel fr
anx
(n.b. inspectarea ieșirii `mailq` nu este echivalentă cu căutarea în jurnalele: mailq listează motivul *ultimei încercări* pentru fiecare fișier de coadă, dar nu ar conține neapărat indicii suplimentare care ar fi putut fi scrise în jurnalele pentru încercările de livrare *anterioare* ale același mesaj.)
Cos avatar
drapel lr
Cos
@anx Poate ne-am dat seama de asta. În /etc/resolv.conf aveam un server de nume care nu mai există. După eliminarea acestui lucru, se pare că nu mai primim timeout-uri în jurnale. Voi verifica săptămâna viitoare să văd dacă problema este complet rezolvată. Îndrumarea dvs. de a verifica jurnalele vechi a fost sfatul de care aveam nevoie. M-am întors și am verificat arhivele istorice ale jurnalului de corespondență. Ei au indicat că problema a început cu ani în urmă, dar se pare că nimeni nu monitoriza serverul suficient pentru a observa. Acest lucru s-ar putea alinia cu vechiul server DNS deconectat, dar nimeni nu a existat suficient de mult pentru a-și aminti.
anx avatar
drapel fr
anx
Mulțumesc pentru actualizare.Chiar dacă vă rezolvă problema imediată (vă rugăm să puneți detaliile într-un răspuns!), totuși, pare să lipsească ceva aici: cum ar putea o problemă DNS - care rezultă într-o eroare după ce ați renunțat după câteva *secunde* - să ducă la serverul nu răspunde (cel puțin cu „încercați din nou mai târziu”) în intervalele de timp de câteva *minute*?
Cos avatar
drapel lr
Cos
@anx Actualizarea finală a fost adăugată la postare. Încă nu ne putem da seama de ce a eșuat, dar putem reproduce problema imediat adăugând orice IP de server de nume nevalid la /etc/resolv.conf . Dacă aceasta ar fi o versiune modernă, probabil că aș încerca să o raportez ca o eroare și să văd dacă cineva care are cunoștințe despre situație de dezvoltator ar putea să o urmărească, dar având în vedere vechimea versiunii instalate și a versiunii sistemului de operare, vom construi un înlocuire de la zero cu o versiune nouă de postfix. Mulțumesc pentru tot ajutorul tău.
Puncte:1
drapel lr
Cos

Din câte ne-am putut da seama, această problemă a fost cauzată de o intrare DNS nevalidă în /etc/resolv.conf . Odată ce intrarea proastă a fost eliminată, am încetat să mai avem probleme în jurnale, iar corespondența a revenit la fluxul corespunzător cu o întârziere minimă la ieșire.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.