Stăpânirea Exim: ghid pentru rescrierea adreselor și erorile TLS de client

Dacă rescrierea adreselor în Exim nu funcționează, cauza este de obicei una dintre patru: regula este în locul greșit, flag-urile nu se potrivesc cu tipul de adresă pe care crezi că îl procesează, te aștepți ca rescrierea la nivel de transport să schimbe envelope-ul deși nu poate face asta, sau routing-ul și redirecționarea se întâmplă într-o etapă diferită față de cea pe care o presupui. Dacă erorile tale TLS de client în Exim apar în același timp, modelul obișnuit este similar: Exim negociază exact ceea ce îi permit configurația și biblioteca TLS, dar serverul remote, politica ta de validare a certificatelor sau propria versiune a stack-ului tău nu este aliniată cu această așteptare.

Aceste două probleme apar împreună mai des decât se așteaptă majoritatea oamenilor, pentru că ambele trăiesc în partea din Exim care pedepsește modelele mentale vagi. Rescrierea are etape precise. TLS are roluri precise. Dacă știi unde rescrie Exim, când face routing și ce opțiuni TLS se aplică pentru partea de server versus partea de client SMTP, eșecurile nu mai par aleatorii.

Acest ghid intră în detaliu pe ambele subiecte. Acoperă cum funcționează de fapt rescrierea în Exim, de ce o regulă care pare corectă poate totuși să fie sărită, cum să testezi corect rescrierea, cum este negociat TLS outbound de transportul smtp și cum să depanezi eșecuri reale de livrare fără să ghicești. Exemplele sunt scrise să rămână aproape de specificația Exim curentă, nu de folclorul de forum.

De ce este atât de des înțeleasă greșit rescrierea în Exim

Exim are mai mult de un loc unde o adresă se poate schimba, iar acele locuri fac lucruri diferite. Secțiunea principală rewrite se aplică adreselor din mesajele primite. Un transport poate folosi și headers_rewrite, dar asta este mai târziu și afectează doar headerele, nu envelope-ul. Envelope sender poate fi schimbat și la nivel de transport cu return_path, dar envelope recipient nu poate fi rescris la nivel de transport.

Această distincție contează pentru că multe configurații defecte sunt imposibile din punct de vedere logic, nu doar configurate greșit. Dacă te aștepți ca o regulă la nivel de transport să schimbe RCPT TO, Exim nu va face asta. Dacă te aștepți ca o regulă din secțiunea principală rewrite să modifice headere adăugate mai târziu de un router sau un transport, Exim nu va face nici asta. Odată ce internalizezi aceste limite, majoritatea eșecurilor de rewrite devin mult mai ușor de diagnosticat.

Cealaltă capcană este să presupui că rescrierea este un înlocuitor pentru routing. Exim suportă rescrierea, dar propria sa documentație avertizează explicit că folosirea rescrierii ca instrument de routing este puternic descurajată. Acela este instinctul corect. Dacă trebuie să alegi o destinație, gândește mai întâi în termeni de routere și transporturi. Folosește rescrierea pentru a regulariza adrese, a canoniza identități locale sau pentru schimbări atent limitate asupra headerelor.

Cum se întâmplă de fapt rescrierea în Exim

Cronologia de bază este partea pe care cei mai mulți administratori o înțeleg greșit. O regulă specială de rewrite la nivel SMTP care folosește flag-ul S poate schimba adresele din envelope-ul de intrare pe măsură ce Exim primește MAIL FROM sau RCPT TO. Regulile obișnuite de rewrite nu sunt același lucru. Pentru rescrierea normală, Exim aplică secțiunea principală rewrite adreselor din mesajele primite, iar rescrierea permanentă a envelope recipient se întâmplă după ce au fost primite headerele mesajului. Exim aplică de asemenea rescrierea și adreselor copil generate prin redirecționare, cu excepția cazului în care routerul este configurat cu no_rewrite.

Apoi există momentul transportului. Un transport poate aplica headers_rewrite chiar înainte ca mesajul să fie scris la ieșire, ceea ce afectează headerele originale și headerele adăugate de ACL-uri sau de un system filter. Nu afectează headerele adăugate de routere sau transporturi. De asemenea, nu afectează envelope-ul. Dacă ai nevoie ca envelope sender-ul de ieșire să fie diferit, folosește return_path pe transport. Dacă ai nevoie ca envelope recipient-ul de ieșire să fie diferit, rezolvă asta în routing, redirecționare sau generarea adresei înainte de faza de transport.

begin rewrite

# Canonicalize sender identities from an internal host to the public domain.
# Applies to envelope From plus From:, Reply-To:, and Sender: headers.
*@legacy.example.net  ${local_part}@example.com  Ffrs

Acest exemplu este în mod intenționat îngust. Nu atinge câmpurile de recipient. Nu încearcă să reruteze emailul. Pur și simplu regularizează identitatea expeditorului pentru un domeniu intern cunoscut. Acesta este genul de rewrite pe care Exim îl gestionează curat.

Ce înseamnă cu adevărat flag-urile de rewrite

O regulă de rewrite nu este doar un pattern și un replacement. Flag-urile determină dacă regula este măcar luată în considerare pentru adresa procesată în acel moment. Aici multe reguli aparent corecte eșuează în tăcere. Dacă scrii o regulă doar pentru sender și apoi testezi o cale de recipient, regula nu este stricată. Este sărită pentru că flag-urile nu se potrivesc.

Flag-urile de mare valoare pe care trebuie să le ții minte sunt acestea:

• F rescrie câmpul envelope From.
• T rescrie câmpul envelope To.
• f, r, s, t, c, b țintesc headere specifice care poartă adrese.
• h înseamnă toate headerele care poartă adrese, nu fiecare header din mesaj.
• S este rescriere specială la nivel SMTP și trebuie tratată separat.
• q oprește procesarea ulterioară de rewrite odată ce regula este invocată.
• R reaplică regula reușită adresei deja rescrise, de până la zece ori.
• Q permite un local part necalificat ca rezultat rescris, pe care Exim îl califică apoi.

Dacă omiți toate flag-urile pentru headere și envelope într-o regulă principală de rewrite, regula se aplică larg tuturor headerelor care poartă adrese și ambelor câmpuri de envelope, sender și recipient. Asta poate fi util, dar poate fi și un instrument brutal. Pentru sisteme de email de producție, regulile înguste sunt de obicei mai sigure decât cele globale.

Motive comune pentru care o regulă de rewrite în Exim nu funcționează

1. Regula este în mecanismul greșit

Dacă pui o regulă în headers_rewrite și te aștepți să schimbe envelope recipient, va eșua deoarece acel mecanism nu atinge niciodată envelope-ul. Dacă pui o regulă în secțiunea principală rewrite și te aștepți să schimbe headere pe care un router le adaugă mai târziu, va eșua deoarece rescrierea globală de input se aplică doar headerelor originale de intrare.

2. Flag-urile nu se potrivesc cu tipul de adresă procesat

O regulă limitată la F și f nu va atinge destinatarii. O regulă limitată la t și c nu va schimba envelope-ul. Sună evident, dar este cea mai ușoară cale de a crea o regulă care pare validă și nu face nimic în scenariul pe care îl testezi.

3. Replacement-ul nu este o adresă completă când Exim cere una

Dacă nu folosești deliberat Q, rezultatul rescris trebuie să fie o adresă complet calificată. Un replacement care se extinde doar la un local part nu este acceptat ca rezultat normal de rewrite.

4. Confunzi rescrierea cu routing-ul sau redirecționarea

Dacă scopul tău este să faci emailul pentru un domeniu să se livreze altundeva, este posibil să ai nevoie de logică de router, redirecționare, aliasuri sau o decizie de transport în loc de un rewrite. Exim poate rescrie un șir de adresă, dar comportamentul de livrare este tot controlat de routing. Acestea nu sunt aceeași operațiune.

5. Un panou îți regenerează configurația

Pe DirectAdmin, cPanel și sisteme similare, editarea fișierului generat greșit este cea mai rapidă cale de a-ți pierde schimbările la următorul rebuild sau refresh de template. Dacă regula funcționează pentru scurt timp și apoi dispare, sau dacă configurația live nu este fișierul pe care l-ai editat, problema ta poate fi generarea configurației, nu logica Exim. Repară asta înainte să depanezi regula propriu-zisă.

O metodă mai sigură de a construi reguli de rewrite

Începe îngust. Fă prima regulă evidentă. Testeaz-o cu o adresă reală. Abia după aceea fă-o dinamică sau bazată pe lookup.

begin rewrite

# Step 1: prove the mechanics with a single explicit rewrite
alice@legacy.example.net  alice@example.com  Ffrs

# Step 2: generalize once the first rule behaves correctly
*@legacy.example.net      ${local_part}@example.com  Ffrs

Odată ce asta funcționează, poți trece la o regulă bazată pe map doar dacă chiar ai nevoie de remapare per utilizator în locul unei simple normalizări de domeniu.

begin rewrite

# /etc/exim/rewrite.map should return a fully qualified address in $value
*@*  ${lookup{$local_part@$domain}lsearch{/etc/exim/rewrite.map}{$value}fail}  Ffrs

Constrângerea importantă este că lookup-ul tău trebuie să returneze o adresă complet calificată. Dacă map-ul tău returnează doar alice în loc de alice@example.com, rewrite-ul este malformat, cu excepția cazului în care folosești în mod deliberat comportamentul Q și înțelegi rezultatul calificării.

Cum să testezi corect rescrierea

Folosește instrumentul Exim potrivit pentru stratul potrivit. Aici se irosește foarte mult timp.

• exim -brw testează direct regulile de input rewrite.
• exim -bt testează routing-ul unei adrese.
• exim -bv verifică un recipient folosind logica de router.
• exim -d-all+rewrite+route oferă output de debug focalizat pe comportamentul de rewrite și routing.

# Test how the rewrite section transforms an address in each possible context
exim -brw alice@legacy.example.net

# Test routing for a recipient, optionally with a realistic sender
exim -bt -f sender@example.com recipient@example.net

# Focus debug output on the logic that usually matters here
exim -d-all+rewrite+route -bt -f sender@example.com recipient@example.net

-brw este cea mai puțin folosită comandă în depanarea problemelor de rewrite din Exim. Ea arată cum ar fi transformată adresa în fiecare context posibil, inclusiv envelope sender, envelope recipient și headerele relevante. Asta o face mult mai utilă decât să te uiți la configurație și să speri. Dacă -brw arată deja comportamentul greșit, repară regula înainte să pierzi timpul urmărind routere sau transporturi.

-bt este diferit. El împinge adresa prin logica de routing. Asta contează deoarece un rewrite poate fi corect, iar calea finală de livrare să te surprindă totuși din cauza routerelor, aliasurilor, redirecționărilor sau comportamentului no-address-test. Dacă problema ta este de fapt „emailul tot ajunge în locul greșit”, probabil ai nevoie atât de -brw, cât și de -bt.

Când ar trebui să folosești în schimb headers_rewrite

Dacă scopul tău real este să rescrii headere care poartă adrese pe măsură ce mesajul pleacă printr-un anumit transport, headers_rewrite este adesea instrumentul mai bun. Este limitat la transport, ceea ce înseamnă că poate fi mai îngust și mai sigur decât o regulă globală de rewrite. De asemenea, vede headerele originale plus headerele adăugate de ACL-uri sau de un system filter, lucru pe care rescrierea globală de input nu îl face.

remote_smtp:
  driver = smtp
  headers_rewrite = *@legacy.example.net ${local_part}@example.com f : 
                    *@legacy.example.net ${local_part}@example.com r : 
                    *@legacy.example.net ${local_part}@example.com s

Folosește acest model atunci când vrei ca un anumit transport SMTP să regularizeze headerele vizibile ale expeditorului pe copia care pleacă prin acel transport. Nu îl folosi atunci când cerința reală este rescrierea envelope recipient. Acea cerință aparține unei etape mai timpurii din procesarea Exim.

Cum funcționează de fapt TLS pe partea de client în Exim

Pe partea de TLS, cea mai mare concepție greșită este să crezi că aceleași setări TLS guvernează atât comportamentul inbound, cât și cel outbound. Nu este așa. Comportamentul TLS al Exim pe partea de server este controlat de opțiunile principale de configurare. Comportamentul TLS outbound trăiește în transportul smtp. Această distincție este explicită în specificația Exim curentă.

Ca client SMTP, Exim va încerca STARTTLS automat atunci când serverul remote îl anunță, cu excepția cazului în care dezactivezi asta în mod deliberat pentru anumite gazde cu hosts_avoid_tls. Dacă vrei să impui criptarea pentru o gazdă, poți forța asta cu hosts_require_tls. Dacă negocierea TLS eșuează după ce STARTTLS a reușit, ce se întâmplă mai departe depinde de tls_tempfail_tryclear. Dacă este false, livrarea este amânată. Dacă este true, Exim se poate reconecta și poate încerca în clar pentru gazde care nu sunt în hosts_require_tls.

Acesta este motivul pentru care unii administratori cred că Exim „cade aleatoriu” în plaintext. Nu este aleatoriu. Urmează comportamentul de transport documentat. Dacă nu vrei fallback, spune asta explicit în transport.

O bază TLS sănătoasă pentru Exim în mod server

Pentru SMTP inbound, Exim trebuie să anunțe STARTTLS și să prezinte un certificat și o cheie privată. Documentația Exim curentă spune că STARTTLS este anunțat gazdelor care se potrivesc cu tls_advertise_hosts și că o configurare TLS funcțională pe partea de server are nevoie de tls_certificate și tls_privatekey setate către fișiere PEM lizibile, cu căi complete.

tls_advertise_hosts = *
tls_certificate = /etc/ssl/mail/mail.example.com.fullchain.pem
tls_privatekey = /etc/ssl/mail/mail.example.com.key

Aceasta este doar partea de server. Ajută MTA-urile remote să se conecteze în siguranță la tine. Nu definește, de una singură, cum verifică serverul tău certificatele remote atunci când Exim este clientul SMTP care trimite email în exterior.

O bază TLS sănătoasă pentru transportul smtp

Pentru SMTP outbound, păstrează configurația explicită. Dacă ai nevoie de verificarea certificatelor pentru anumiți peer-i, setează asta în transportul smtp. Nu presupune că setările globale de certificat folosite pentru SMTP inbound vor fi reutilizate automat și pentru modul client. Exim spune explicit că nu presupune asta.

remote_smtp:
  driver = smtp
  tls_verify_certificates = system
  tls_tempfail_tryclear = false

Aceasta este o bază conservatoare pentru o gazdă pe care vrei validare normală a certificatelor și pe care nu vrei ca Exim să reîncerce în tăcere aceeași gazdă în clar după o problemă temporară de negociere TLS. Dacă trebuie să impui TLS doar pentru un anumit relay sau smarthost, limitează acea cerință la lista reală de gazde în loc să forțezi o politică globală pe întregul Internet, pe care nu îl controlezi.

remote_smtp:
  driver = smtp
  hosts_require_tls = mail.relay.example.net
  tls_verify_certificates = system
  tls_tempfail_tryclear = false

Dacă setezi tls_require_ciphers, fă-o cu grijă. Documentația Exim curentă notează că atunci când este negociat TLS 1.3, acea opțiune este ignorată pentru selecția cifrurilor TLS 1.3. Reglajul prea agresiv al cifrurilor tinde de asemenea să creeze probleme de compatibilitate mai repede decât rezolvă, mai ales pe livrare generală către Internet.

De ce Gmail îți expune adesea primul problemele TLS

Google nu este singura destinație căreia îi pasă de igiena SMTP, dar este adesea primul loc unde configurațiile slabe devin vizibile. Ghidul Google pentru expeditori spune că expeditorii către Gmail ar trebui să folosească o conexiune TLS pentru transmiterea emailului și cere de asemenea autentificare și igienă DNS sănătoase, cum ar fi SPF sau DKIM și forward și reverse DNS valide. Dacă stack-ul tău este la limită, Gmail este un loc comun în care vezi simptomele înainte să se plângă providerii mai mici.

Asta nu înseamnă că fiecare problemă de livrare către Gmail este o problemă de versiune TLS. Înseamnă că Gmail este o destinație cu semnal puternic. Dacă emailul către alți destinatari mai mici reușește, dar Gmail arată eșecuri de TLS sau de trust, asta îți spune adesea că stack-ul tău este doar marginal compatibil în altă parte.

Cum să testezi corect un endpoint SMTP remote cu TLS

Cea mai rapidă verificare externă este openssl s_client cu STARTTLS pentru SMTP. OpenSSL documentează s_client ca un client TLS de diagnostic, și este exact instrumentul potrivit pentru a verifica ce negociază în realitate un server remote.

openssl s_client -starttls smtp 
  -connect gmail-smtp-in.l.google.com:25 
  -servername gmail-smtp-in.l.google.com

Ceea ce vrei să vezi este simplu: un handshake reușit, un lanț de certificate utilizabil și un protocol și un cifru negociate. Dacă conexiunea moare înainte ca STARTTLS să se finalizeze, sau dacă lanțul de certificate este invalid, ai deja dovezi înainte să atingi Exim. Dacă partea remote arată bine cu s_client dar Exim tot eșuează, următorul pas este să inspectezi setările proprii de transport și output-ul de debug al Exim.

Dacă primești un mesaj precum wrong version number, nu sări direct la concluzia „serverul remote suportă doar TLS vechi”. Acea familie specifică de erori OpenSSL indică adesea o nepotrivire de protocol, de exemplu încerci să vorbești TLS direct cu un serviciu sau proxy care în acel moment vorbește SMTP în clar, sau testezi portul greșit ori traseul greșit printr-un load balancer. Tratează-l mai întâi ca pe o problemă de formă a handshake-ului, nu ca pe o plângere garantată despre cifruri.

Cum să depanezi erorile TLS de client în Exim fără să ghicești

Atunci când eșecul este în Exim și nu este evident din s_client, pornește categorii țintite de debug în loc să descarci totul.

exim -d-all+tls+route+transport -bt recipient@gmail.com

Asta nu este o încercare completă de livrare, dar este o metodă curată de a focaliza modul în care gândește Exim. Pentru emailuri aflate la coadă sau pentru o livrare de test controlată, folosește o abordare etapizată. Verifică logul principal, apoi crește debug-ul doar atât cât este nevoie. Pe sisteme ocupate, output-ul de debug Exim fără discriminare devine foarte repede zgomot.

Acordă atenție deosebită acestor întrebări:

• Serverul remote a anunțat STARTTLS?
• Exim a încercat STARTTLS și a eșuat înainte de finalizarea handshake-ului?
• Verifică Exim certificatul serverului și față de ce trust store?
• Eșecul apare doar pentru o gazdă de destinație, sau pentru mai mulți destinatari moderni?
• Packaging-ul sau panoul tău a schimbat recent OpenSSL, GnuTLS, Exim sau fișierele de certificat?

Dacă problema a început după o schimbare majoră de pachete, trateaz-o ca pe o problemă de upgrade, nu de mentenanță de rutină. Această distincție contează. Update vs. upgrade de server: Care este diferența și de ce este importantă merită citit înainte să mai faci încă o rundă de schimbări TLS live pe un host de email de producție.

Ce merge de obicei prost în producție

Aceleași greșeli operaționale apar iar și iar.

• O regulă de rewrite este validă sintactic, dar atașată fazei greșite.
• Administratorul testează routing-ul cu -bt dar nu testează niciodată rescrierea cu -brw.
• Un panou regenerează configurația Exim și aruncă în tăcere modificările manuale.
• Serverul prezintă un certificat inbound valid, dar transportul smtp outbound are setări de trust diferite sau incomplete.
• Un stack TLS vechi încă funcționează cu peer-i permisivi, dar eșuează când sunt implicați destinatari mai stricți.
• Un fallback în clar este permis de politica transportului, așa că operatorul înțelege greșit postura reală de securitate.
• Simptomele de livrare a emailului sunt puse pe seama Exim când problema reală este DNS, reverse DNS, SPF, DKIM sau postura generală de livrabilitate.

Ultimul punct contează mai mult decât vor să admită mulți administratori. Dacă serverul tău de email este construit custom și este critic pentru business, nu mai administrezi doar Exim. Administrezi întregul lanț: certificate, DNS, comportamentul cozii, autentificare, reputație și compatibilitate cu politicile remote. Ghidul livrării emailurilor: De ce găzduirea web îți poate garanta succesul în comunicare este relevant aici pentru că multe „probleme TLS” se dovedesc a fi parte a unei probleme mai largi de igienă a emailului outbound.

Când are sens ajutorul administrat

Dacă problema este o singură greșeală de tipar într-o configurație Exim întreținută manual, repar-o singur și mergi mai departe. Dacă problema se întinde peste rescriere Exim, TLS outbound, DNS, trust-ul certificatelor, starea cozii și configurația generată de panou, atunci nu mai este o reparație într-o singură linie. Este inginerie operațională pentru email.

Acolo este punctul în care Administrare Linux ServerSpan sau Management DirectAdmin ServerSpan are sens, în funcție de faptul dacă sistemul este un stack Linux custom sau un server administrat prin DirectAdmin. Dacă ceea ce vrei de fapt este să încetezi complet să deții un stack Exim self-managed, Găzduire eMail ServerSpan este răspunsul mai curat. Este mai bine să admiți că un server de email nu mai merită ajustat manual decât să continui să peticești unul fragil doar pentru că deja ai investit în el.

Checklist final de depanare

• Testează rescrierea în sine cu exim -brw.
• Testează separat routing-ul cu exim -bt.
• Confirmă dacă schimbarea pe care o vrei aparține în rewrite, headers_rewrite, return_path sau într-un router.
• Verifică dacă flag-urile tale se potrivesc tipului real de adresă pe care îl testezi.
• Folosește selectori de debug focalizați precum rewrite, route, tls și transport.
• Testează independent peer-ul remote cu openssl s_client -starttls smtp.
• Verifică dacă cerințele TLS, validarea certificatelor sau politica de fallback sunt definite în transportul smtp, nu doar în setările globale Exim.
• Dacă hostul este administrat prin panou, confirmă că modificările tale supraviețuiesc regenerării configurației.

Concluzie

Rescrierea adreselor în Exim încetează să mai fie misterioasă odată ce nu o mai tratezi ca pe o singură funcție. Există input-time rewriting, SMTP-time rewriting, transport-time header rewriting și schimbări de return-path la nivel de transport. Ele rezolvă probleme diferite. Erorile TLS de client în Exim încetează și ele să mai pară aleatorii odată ce separi TLS pe partea de server de politica pe partea de client a transportului smtp și verifici ce oferă de fapt endpoint-ul remote. Majoritatea configurațiilor defecte nu sunt defecte pentru că Exim este inconsecvent. Sunt defecte pentru că operatorul cere unui mecanism Exim să facă treaba altui mecanism.

Dacă depanezi un host de email de producție și eșecul nu mai este izolat la o regulă evidentă sau la o problemă evidentă de certificat, oprește improvizațiile sub trafic live. Folosește Administrare Linux ServerSpan dacă ai nevoie de ajutor de specialitate pe un stack custom, sau mută-te la Găzduire eMail ServerSpan dacă deținerea stack-ului de email nu mai merită costul operațional.