Serverul Postfix SMTP primește e-mailuri din rețea și este expus spammerilor și virușilor. Acest document descrie metode Postfix încorporate și externe care indică ce e-mail SMTP ar trebui să primească. De asemenea, veți afla ce erori ar trebui evitate și cum să vă testați configurația.
Subiecte incluse în document:
Majoritatea funcțiilor care permit controlul accesului la serverul SMTP Postfix sunt destinate combaterii spam-ului.
Orientat spre liste negre. Unele acces la controalele de server SMTP interogheze liste negre (liste negre), care stochează informații despre site-urile „rele“, cum ar fi relei deschis (relee de mail deschise), open-WEB server proxy compromise computerele de acasă, care sunt controlate de la distanță de către infractori. Eficacitatea listelor negre depinde de completitudinea lor și de informațiile actualizate.
Din păcate, toate mijloacele de combatere a spamului pot fi greșite, respingând scrisori legitime. Aceasta poate fi o problemă gravă pentru un server care procesează poșta pentru un număr mare de utilizatori. Pentru unii utilizatori inacceptabil să primească cel puțin un tip spam de e-mail-uri, în timp ce celălalt a respins în mod eronat mesajul legitim se poate transforma într-o tragedie. Deoarece nu există o politică specifică care să satisfacă dorințele tuturor utilizatorilor fără excepție, Postfix suportă restricții diferite privind accesul la serverul SMTP pentru diferiți utilizatori. Această caracteristică este descrisă în documentul RESTRICTION_CLASS_README.
Pe lângă restricțiile care pot fi configurate pentru clienți sau utilizatori individuali, Postfix implementează mai multe restricții care afectează toate mesajele SMTP.
Embedded header_checks conținut limită (verificați antet) și body_checks (test de scriere conținutului) descrise în documentul BUILTIN_FILTER_README. Aceste verificări se efectuează în timpul primirii corespondenței, înainte ca mesajul să fie plasat în coada de intrare (coada de intrare).
Externe (prin programe terță parte) verifică conținutul înainte de al pune în coadă, care este descris în documentul SMTPD_PROXY_README. Această verificare se efectuează la momentul primirii corespondenței, înainte de a plasa mesajul în coada de intrare.
Solicitați clienților să trimită comanda HELO sau EHLO înainte de a utiliza comanda MAIL FROM sau ETRN. Acest lucru poate provoca probleme când lucrați cu clienții de e-mail "home-grown". Din acest motiv, restricția este dezactivată implicit ("smtpd_helo_required = no").
Împiedicați sintaxa incorectă în comenzile MAIL FROM sau RCPT TO. Acest lucru poate provoca probleme atunci când se ocupă cu "homegrown" sau clienți străini de e-mail. Din acest motiv, cerința este dezactivată în mod implicit ("strict_rfc821_envelopes = no").
Postfix vă permite să specificați liste de constrângeri pentru fiecare etapă a dialogului SMTP. Restricții separate sunt descrise în pagina de documentare postconf (5).
Exemple de liste de constrângeri simple:
Fiecare listă este procesat de la stânga la dreapta restricții, atâta timp cât orice limitare a nu da PERMISULUI rezultat (rezolva), REJECT (respingere) sau DEFER (amâna pentru a reîncerca mai târziu). Atingerea capătului listei este echivalentă cu obținerea rezultatului PERMIT. Arătând restricție PERMIS înainte de REJECT restricție puteți face o excepție pentru anumiți clienți sau utilizatori (așa-numitele liste albe, Whitelisting). Exemplul de mai jos vă permite să trimiteți e-mailuri clienților locali, dar alți utilizatori nu pot trimite poștă către destinatari arbitrari.
Mai jos este un tabel care explică scopul tuturor listelor de restricții de acces la SMTP. Sintaxa listelor de scriere este aceeași, diferă numai în timpul aplicării și în efectul care are ca rezultat rezultatele REJECT sau DEFER.
Numele listei de restricții
Efectul rezultatului REJECT sau DEFER
Respingeți comanda ETRN
Versiunile anterioare ale Postfix au efectuat cât mai curând posibil acțiunile oferite de listele de restricții de acces către SMTP. Lista de restricții pentru clienți a fost verificată înainte ca Postfix să trimită un "nume de utilizator 220 $". Salut la clientul SMTP. Lista smtpd_helo_restrictions a fost procesată înainte ca Postfix să răspundă la comanda HELO (EHLO). Lista de restricții smtpd_sender_restrictions a fost procesată înainte de răspunsul la comanda MAIL FROM. Și așa mai departe. Această practică sa dovedit a fi foarte dificil de aplicat.
Versiunile actuale ale Postfix amână procesarea listelor de constrângeri pentru clienți, expeditori și HELO înainte de a primi comanda RCPT TO sau ETRN. Acest comportament este controlat de parametrul smtpd_delay_reject. Listele de limită sunt procesate în ordinea corectă (client, helo, etrn) sau (client, helo, expeditor, destinatar, date, sfârșit de date). Atunci când o listă de constrângeri (de exemplu, clientul) returnează rezultatul REJECT sau DEFER, nu se efectuează procesarea listelor ulterioare (exemplu: helo, expeditor etc.).
În timp ce parametrul smtpd_delay_reject a fost adăugat. Postfix a introdus, de asemenea, suport pentru liste de constrângeri mixte care combină informații despre client, expeditor, destinatar și informații din comenzile helo, etrn.
Avantajele procesării amânate a listelor de restricții și a listelor mixte:
Unii clienți SMTP nu așteaptă răspunsuri negative în primele etape ale sesiunii SMTP. Atunci când veștile proaste sunt amânate până când răspunsul la rcpt TO, frunzele de client, după cum este necesar, și nu atârnă înainte de secționarea conexiunea a expirat, sau mai rău, intră într-o conexiune de buclă infinită, erori de conexiune.
Cititorul se poate întreba acum de ce sunt necesare liste de constrângeri ale clientului, helei sau expeditorului, dacă procesarea lor este întârziată înainte de comanda RCPT TO sau ETRN. Unii oameni recomandă introducerea TOATE restricții în lista smtpd_recipient_restrictions. Din păcate, acest lucru poate duce la un comportament prea încrezător al serverului SMTP Postfix. Cum este posibil acest lucru?
Iată un exemplu care ilustrează situația de mai sus:
Problema cu această configurație este că lista smtpd_recipient_restrictions ieșiri rezultate pentru PERMISUL orice gazdă, care se anunță ca „localhost.localdomain“. Ca rezultat, Postfix devine un releu deschis pentru toate aceste mașini.
Postfix are câteva caracteristici care vă ajută să testați regulile de acces SMTP:
Acest instrument înlocuiește acțiunile serverului SMTP REJECT cu DEFER (încercați din nou mai târziu). Acest lucru vă permite să lăsați mesaje în coadă, care altfel ar fi returnate expeditorului. Specificați "soft_bounce = yes" în fișierul principal.cf pentru a preveni respingerea permanentă a mesajelor SMTP de către serverul Postfix. În acest scop, Postfix înlocuiește toate codurile de răspuns 5xx cu 4xx.
Această caracteristică vă permite să înlocuiți acțiunile SMTP ale serviciului REJRCT cu avertismente. În loc să respingă comanda clientului, Postfix înregistrează ce urma să respingă. Specificați "warn_if_reject" în lista de restricții de acces SMTP înainte de restricția pe care doriți să o testați fără a respinge efectiv e-mailul.
Trimiteți-le prietenilor: