Postfix: configurarea trimiterii e-mailurilor în Asterisk. Refuzul modului chroot. Teancul de livrare poștală

Postfix este agentul de transfer de e-mail (MTA) implicit în Ubuntu. Este conceput pentru a fi rapid, ușor de administrat și sigur. Este compatibil MTA sendmail . Această secțiune descrie cum se instalează și se configurează postfix. De asemenea, explică cum să îl transformi într-un server SMTP folosind conexiuni sigure(pentru transmiterea securizată a mesajelor).

Instalare

Pentru a instala postfix rulați următoarea comandă:

Sudo apt-get install postfix

Doar apăsați enter când procesul de instalare pune întrebări, configurarea foarte detaliată se va face în pasul următor.

Configurare de bază

Pentru a configura postfix, rulați următoarea comandă:

Sudo dpkg-reconfigure postfix

Va fi lansat interfata utilizator. Pe fiecare ecran, selectați următoarele:

    mail.example.com

    Steve

    mail.example.com , localhost.localdomain, localhost

    127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/24

Înlocui mail.example.com către domeniul pentru care configurați e-mail, 192.168.0.0/24 la subrețeaua și masca curente pentru serverul dvs. de e-mail și Steve la numele de utilizator corespunzător.

Acum este momentul să decideți ce format cutie poştală vrei să folosești. În mod implicit, postfix folosește formatul mbox. În loc să editați direct fișierul de configurare, puteți utiliza comanda postconf pentru a configura parametrii postfix. Setările vor fi salvate în fișierul /etc/postfix/main.cf. În viitor, dacă decideți să reconfigurați parametrii individuali, puteți fie să rulați comanda, fie să editați manual fișierul.

Pentru a seta formatul căsuței poștale pentru Maildir:

Sudo postconf -e "home_mailbox = Maildir/"

Autentificare SMTP

SMTP -AUTH permite clientului să se identifice printr-un mecanism de autentificare (SASL). Transport Layer Security (TLS) va fi folosit pentru a cripta procesul de autentificare. După Autentificare SMTP serverul va permite clientului să transmită e-mail.

1. Configurați Postfix la SMTP -AUTH utilizând SASL (Dovecot SASL):

Sudo postconf -e "smtpd_sasl_type = dovecot" sudo postconf -e "smtpd_sasl_path = private/auth-client" sudo postconf -e "smtpd_sasl_local_domain =" sudo postconf -e "smtpd_sasl_security_options"_do = postconf da" sudo postconf -e "smtpd_sasl_auth_enable = yes" sudo postconf -e "smtpd_recipient_restrictions = \permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination"

Setări smtpd_sasl_path este o cale relativă la directorul de solicitări Postfix.

3. După ce aveți certificatul, configurați Postfix pentru a utiliza criptarea TLS atât pentru e-mailurile primite, cât și pentru cele trimise:

Sudo postconf -e "smtp_tls_security_level = may" sudo postconf -e "smtpd_tls_security_level = may" sudo postconf -e "smtp_tls_note_starttls_offer = yes" sudo postconf -e "smtpd_tls_security_level =/postconf. e" smtpd_tls_cert_file = /etc/ssl/certs/server.crt" sudo postconf -e "smtpd_tls_loglevel = 1" sudo postconf -e "smtpd_tls_received_header = yes" sudo postconf -e "examplename.com mail.

4. Dacă utilizați propriul centru de certificare , pentru a semna certificatul, introduceți:

Sudo postconf -e "smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem"

Din nou, consultați secțiunea Certificate pentru detalii.

După rularea tuturor comenzilor, Postfix este configurat la SMTP -AUTH și este creat un certificat autosemnat pentru criptarea TLS.

Configurarea inițială a postfix este completă. Rulați următoarea comandă pentru a reporni serviciul postfix:

Postfix acceptă SMTP -AUTH așa cum este descris în RFC2554. Se bazează pe SASL. Cu toate acestea, mai trebuie să configurați autentificarea înainte de a putea utiliza SMTP -AUTH.

Configurarea SASL

Postfix acceptă două implementări SASL: Cyrus SASL Şi Dovecot SASL . Pentru a permite Dovecot SASL, pachetul trebuie instalat porumbel-comun. Pentru a face acest lucru, introduceți următoarele din terminal:

Sudo apt-get install dovecot-common

Socket listen ( #master ( # Socket-ul principal oferă acces la informațiile userdb. De obicei # este folosit pentru a oferi agentului de livrare local Dovecot acces la userdb, astfel încât # să poată găsi locațiile cutiei poștale. #path = /var/run/dovecot/ auth-master #mode = 0600 # Utilizatorul/grupul implicit este cel care a pornit dovecot-auth (rădăcină) #user = #group = #) client ( # Socket-ul clientului este în general sigur de exportat către toată lumea. Utilizarea tipică # este să exportați-l pe serverul dvs. SMTP, astfel încât să poată face căutări SMTP AUTH # folosind calea = /var/spool/postfix/private/auth-client mode = 0660 user = postfix group = postfix ) ).

Pentru a permite clienților Outlook să utilizeze SMTP -AUTH, în secțiunea autentificare implicită fișierul /etc/dovecot/dovecot.conf adăugați „login”:

Mecanisme = autentificare simplă

Odată ce Dovecot este configurat, reporniți-l:

Sudo /etc/init.d/dovecot restart

Teancul de livrare poștală

O altă opțiune de a configura Postfix pentru SMTP -AUTH este utilizarea pachetului livrarea-stivă-poștă(denumit anterior porumbel-postfix). Acest pachet va instala Dovecot și va configura Postfix să-l folosească împreună cu autentificarea SASL și ca agent de livrare a e-mailului (MDA). Pachetul va configura și Dovecot pentru IMAP, IMAPS, POP3 și POP3S.

Este posibil să doriți sau nu să utilizați IMAP, IMAPS, POP3 sau POP3S pe serverul dvs. de e-mail. De exemplu, dacă vă configurați serverul ca gateway de e-mail, filtru de spam și viruși etc. În acest caz, poate fi mai ușor să utilizați comenzile de mai sus pentru a configura Postfix la SMTP _AUTH.

Pentru a instala pachetul, introduceți într-un terminal:

Sudo apt-get install mail-stack-delivery

Acum aveți un server de e-mail funcțional, dar există câteva opțiuni pe care poate doriți să le schimbați în viitor. De exemplu, pachetul folosește certificatul și cheia din pachetul ssl-cert, iar într-un mediu de producție, ați folosi certificatul și cheia generate pentru gazdă. Consultați secțiunea Certificate pentru detalii suplimentare.

Odată ce ați primit certificatul comandat pentru server, înlocuiți următoarea opțiune în /etc/postfix/main.cf:

Smtpd_tls_cert_file = /etc/ssl/certs/ssl-mail.pem smtpd_tls_key_file = /etc/ssl/private/ssl-mail.key

Reporniți Postfix:

Sudo /etc/init.d/postfix restart

Testare

Configurarea SMTP -AUTH este completă. Acum este momentul să vă verificați setările.

Pentru a verifica dacă SMTP -AUTH și TLS funcționează corect, rulați următoarea comandă:

Telnet mail.example.com 25

După stabilirea unei conexiuni cu server de mail postfix introduceți:

Ehlo mail.example.com

Dacă, printre altele, vedeți următoarele rânduri, totul funcționează excelent. Intră renunta a iesi.

250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250 8BITMIME

Rezolvarea problemelor

Această secțiune descrie mai multe metode comune determinarea cauzelor problemelor emergente.

Refuzul modului chroot

Pungă de plastic postfixîn Ubuntu este instalat implicit în mediu chroot din motive de securitate. Acest lucru poate complica și mai mult procesul de găsire a soluțiilor la probleme.

Pentru a dezactiva funcționalitatea chroot, găsiți următoarea linie în fișierul de setări /etc/postfix/master.cf:

Smtp inet n - - - - smtpd

Și înlocuiți cu următoarele:

Smtp inet n - n - - smtpd

După aceasta, va trebui să reporniți Postfix pentru a utiliza noile setări. Din terminal introduceți următoarele:

Sudo /etc/init.d/postfix restart

Fișiere jurnal

Postfix trimite toate mesajele la /var/log/mail.log. Cu toate acestea, mesajele de eroare și avertismentele se pot pierde uneori în jurnalul normal, așa că sunt stocate separat în /var/log/mail.err și, respectiv, /var/log/mail.warn.

Pentru a vizualiza mesajele de jurnal în timp real, puteți utiliza comanda coada -f:

Coada -f /var/log/mail.err

Numărul de detalii înregistrate în jurnal poate fi mărit. Mai jos sunt câteva opțiuni de personalizare pentru a crește nivelul de detaliu în unele dintre zonele descrise mai sus.

1. A crește TLSînregistrați activitatea, setați opțiuni smtpd_tls_loglevel valoare de la 1 la 4.

Sudo postconf -e "smtpd_tls_loglevel = 4"

2. Dacă întâmpinați dificultăți la trimiterea sau primirea e-mailurilor de la un anumit domeniu, îl puteți activa în setare lista_debug_peer_list.

Sudo postconf -e "debug_peer_list = problem.domain"

3. Puteți crește granularitatea oricărui serviciu Postfix prin editarea /etc/postfix/master.cf, adăugând -v după înregistrarea corespunzătoare. De exemplu, să schimbăm intrarea smtp:

Smtp unix - - - - - smtp -v

Este important să rețineți că, după efectuarea modificărilor setărilor de înregistrare a procesului, Postfix trebuie repornit pentru a accepta configurație nouă: sudo /etc/init.d/postfix reload

4. Pentru a crește cantitatea de informații de jurnal atunci când depanați problemele SASL, puteți seta următoarele opțiuni în /etc/dovecot/dovecot.conf:

Auth_debug=da auth_debug_passwords=da

Ca și în cazul Postfix, dacă modificați setările Dovecot, procesul trebuie repornit: sudo /etc/init.d/dovecot reload

Unele dintre opțiunile de mai sus pot crește serios cantitatea de informații trimise către fișierele jurnal. Nu uitați să readuceți nivelul de verbozitate al jurnalului la normal după rezolvarea problemelor. Apoi reporniți serviciul corespunzător pentru ca modificările setărilor să aibă efect.

Legături

Administrarea serverului Postfix poate fi foarte sarcină provocatoare. La un moment dat, poate fi necesar să apelați la comunitatea Ubuntu pentru ajutor mai calificat.

Pentru o scufundare profundă în informațiile Postfix, este foarte recomandat să citiți Cartea Postfix.

În cele din urmă, site-ul web Postfix conține și o mulțime de informații despre toate opțiunile de configurare posibile.

În plus, pagina Ubuntu Wiki Postfix conține informații suplimentare.

E-mailurile trimise de pe un site web prin intermediul funcției mail() ajung în spam în 99% din cazuri dacă serverul dvs. SMTP nu este configurat profesional. Adesea, webmasterul nu are o nevoie urgentă de a instala și de a regla fin SMTP și, chiar mai des, este prost de leneș. Multe CMS-uri au o opțiune sau pluginuri terțe, care vă permit să ocoliți această problemă utilizând servicii externe SMTP. Dar dacă CMS-ul nu are o astfel de opțiune sau este prost proiectat și funcționează cu restricții de port sau alte surprize? Este deranjant mai ales dacă acesta este un proiect comercial, iar dezvoltatorul motorului, pentru care s-au plătit mulți bani și de care, în mare, toată lumea este mulțumită, spune că „opțiunea este planificată, dar prioritatea este scăzută. , pentru că Există foarte puține solicitări pentru funcția"? Și este foarte trist dacă aflați acest lucru din arhivele forumului de asistență, unde această sarcină „neprioritară” a fost discutată cu câțiva ani în urmă, iar lucrurile sunt încă acolo. Nu știu de ce prioritatea este scăzută... Poate că în RuNet nu deranjează pe nimeni că scrisorile cu confirmări, facturi și altele ajung în spam. Mă stresează.
Și așadar, dacă nu puteți face ca motorul să funcționeze cu SMTP extern, atunci trebuie să faceți ca funcția standard mail() să funcționeze cu el. Vom trimite e-mail prin serverul SMTP al Google. În exemplu, am un domeniu conectat la Google Apps, dar același lucru se poate face cu un cont Gmail obișnuit.
Avem: Un server care rulează Ubuntu 12.04 cu o gazdă host.domain.name, un nume de domeniu domain.name, conectat la Google Apps și un CMS care trimite e-mail numai prin mail(). Acesta din urmă nu este important, deoarece nu vom atinge deloc CMS-ul.
Instalați Postfix. Când instalați, când sunteți întrebat despre utilizare, răspundeți „Site de internet”.
aptitude install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules
Apoi, editați fișierul de configurare /etc/postfix/main.cf. Ștergem totul din el și, în schimb, scriem următoarele:
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no append_dot_mydomain = nu readme_directory = nu myhostname = host.domain.name alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin =/desetcname =/myhostname host.domain.name, localhost.net, localhost mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all relayhost= :587 smche_destinations_catchp = :587 smtp_use_tls = da smtp_tls_security_level = criptare smtp_sasl_auth_enable = da smtp_sasl_password_maps = hash:/etc/postfix/mailpass smtp_sasl_security_security_options ent_relay host_maps = hash:/etc/postfix/sender_relay smtp_generic_maps = hash:/etc/postfix/generic smtp_tls_CAfile = /etc/postfix/cacert.pem soft_bounce = da default_destination_concurrency_limit = 1 smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
Unde câmpurile „myhostname = host.domain.name” și „mydestination = host.domain.name” indică numele dvs. de gazdă. Adică trebuie înlocuit.
Salva. Copiați certificatul.
cat /etc/ssl/certs/Thawte_Premium_Server_CA.pem | tee -a /etc/postfix/cacert.pem
Apoi, în același loc, în /etc/postfix, creați un fișier mailpass și scrieți următoarele în el:
:587 [email protected]:parolă
Unde [email protected] Avem un cont de e-mail, iar parola este parola pentru acesta.
Îl salvăm și refuzăm accesul la el tuturor, cu excepția super-utilizatorului.
chmod 600 /etc/postfix/mailpass
Și 400 este mai bun, deoarece root nu va trebui să editeze nimic altceva acolo.
Salvați și creați un fișier generic cu următorul conținut:
www-data [email protected]
„www-data” este utilizatorul nostru sub care rulează apache gazdă virtualăși în numele căruia CMS generează conținut. Dacă apache-ul dvs. este configurat corect și rulează în numele utilizatorului care deține directorul în care se află CMS-ul, atunci în loc de „www-data” ar trebui să îl specificați. A doua parte este, respectiv, e-mail-ul din care vor veni e-mailurile de la utilizatorul www-data.
Salvați și creați un fișier sender_relay cu următorul conținut:
[email protected] :587 [email protected] :587
Aici cred că totul este clar. Există doi utilizatori în sistem (rădăcină și utilizator) și ambele e-mailuri trec prin SMTP extern.
Salvați și creați fișierul tls_policy. Scriem în el următoarele:
:587 criptează
De fapt, jocul cu fișierul „tls_policy” nu este necesar. Se spune că funcționează fără el, dar nu a funcționat pentru mine. Dacă nu creați acest fișier, atunci linia „smtp_tls_policy_maps = hash:/etc/postfix/tls_policy” ar trebui eliminată din configurație.
Apoi rulați următoarele comenzi:
postmap /etc/postfix/tls_policy
(Inutil dacă „tls_policy” nu este utilizat).
postmap /etc/postfix/generic postmap /etc/postfix/mailpass postmap /etc/postfix/sender_relay
Apoi repornim Postfix.
/etc/init.d/postfix restart
Toate. Puteți verifica cu următoarea comandă:
echo „Testează e-mailul din postfix” | mail -s "Test Postfix" [email protected]
Unde [email protected] Avem o adresă de e-mail la care tocmai am trimis o scrisoare.
Avem loguri în /var/log/mail.log. Dacă totul este făcut corect, atunci există un raport despre operațiune. Dacă o tăiați oblic, atunci există informații despre eroare.
Dacă aveți totul configurat corect în Google Apps și domeniul este alocat semnătură digitală, apoi scrisorile trimise prin funcția standard mail() nu vor ajunge niciodată în spam.
Și în sfârșit, o muscă în unguent. Nu știu cum este acum, dar conturile Gmail aveau o limită de 500 de e-mailuri trimise pe zi. Combaterea spamului. Nu știu dacă aceste limite se aplică Google Apps (nu le-am depășit niciodată), dar merită să fii atent. Dar dacă există limite, atunci folosind această schemă puteți oricând să vă închideți e-mailul prin servicii mai lipsite de griji dacă aveți o audiență mare și toată lumea este abonată la fiecare strănut auzit pe site.

Pe în această etapă configurație, observatorii din afara pot ghici unde și câte scrisori trimitem, cu toate acestea, nu pot afla conținutul mesajelor. Dar ce se va întâmpla dacă vor instala un „post de bloc” pe traseul conexiunii, asemănător celui descris în prefață, sau vor face din când în când „raiduri”? Nu există multe opțiuni:

  • Afișați conținutul mesajului și treceți mai departe - acesta este scenariul care va fi implementat pe baza setărilor din secțiunea anterioară (parametru smtp_tls_security_level setat la valoare mai)
  • Reveniți cu un mesaj de eroare - acest scenariu va fi implementat pentru domeniul gmail.com pe baza setărilor din secțiunea anterioară
  • Utilizați un drum „secret” de ocolire

Să ne uităm la ultimele două opțiuni. În general, cea mai sigură soluție este să te întorci și să încerci să trimiți din nou la anumite intervale. Apoi, după expirarea timpului de așteptare a blocării, eliminați mesajul din coada de mesaje de ieșire. Acest scenariu este potrivit pentru ocolirea raidurilor periodice, dar nu are sens dacă există un punct de control permanent - toate scrisorile vor fi returnate și distruse.

Utilizarea rutelor de ocolire este posibilă doar până când acestea sunt descoperite și blocate de inamic (așa-numita securitate prin obscuritate sau „securitate prin ascundere”), însă, în cazul unui punct de control permanent, această măsură este singura alternativă posibilă. la o dezvăluire completă a conținutului mesajului

Configurare inițială

În cel mai simplu caz, redirecționarea tuturor e-mailurilor către un intermediar de încredere (în ce măsură putem vorbi chiar de încredere în acest context) este configurată pe client după cum urmează:

relayhost = :8025

Aici relayhost specifică numele (sau adresa IP) al serverului de releu și numărul portului către care este trimisă toată corespondența. Specificarea unui nume sau adresă în paranteze pătrate folosit pentru a se asigura că redirecționarea este efectuată direct către gazda specificată. În caz contrar, Postfix va redirecționa corespondența către înregistrarea MX a gazdei specificate. Numărul de port non-standard este folosit pentru a simplifica configurarea releului și pentru a ocoli filtrele instalate pe porturile standard (deși portul alternativ obișnuit pentru SMTP este 587). Configurația mediatorului Rayleigh poate fi reprezentată ca:

rețelele mele = 127.0.0.1, [::1], 1.2.4.5 smtpd_client_restrictions = permit_mynetworks, respinge
  • rețelele mele- o listă de rețele de încredere la care se adaugă adresa IP a gazdei de redirecționare
  • smtpd_client_restrictions- lista verificărilor la etapa de stabilire a racordării.B în acest caz, conexiunile din rețele de încredere sunt permise și alte conexiuni sunt respinse. Listele de verificare sunt descrise mai detaliat în documentul SMTPD_ACCESS_README, dintre care unele vor fi discutate mai jos

În plus, pentru a primi corespondență pe un port non-standard, trebuie să adăugați (dacă intenționați să primiți poștă obișnuită) sau modificați (în cazul în care corespondența va fi acceptată de la o singură gazdă) transportul în master.cf:

8025 inet n - - - - smtpd

Redirecționare folosind TLS

Utilizarea unui releu nu înlocuiește necesitatea de a transmite conținutul mesajelor pe un canal securizat în cazul în care este detectat un port non-standard. Pentru a face acest lucru, TLS trebuie configurat pe serverul de redirecționare. Configurarea unui server TLS este foarte asemănătoare cu configurarea unui client TLS:

tls_high_cipherlist = HIGH:@STRENGTH smtpd_tls_loglevel = 1 smtpd_tls_security_level = mai smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_cache smtpd_tls_cert_file = /etc/ssl/example.com.crt smtpd_tls_key_file = /etc/ssl/example.com.key smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_ciphers = mare smtpd_tls_exclude_ciphers = aNULL, MD5, CAMELLIA

Aici avem doi parametri noi - smtpd_tls_cert_fileŞi smtpd_tls_key_file, care sunt, respectiv, numele fișierelor de certificat și cheie privată

Se presupune că certificatul a fost achiziționat de la o autoritate de certificare de încredere, iar certificatele autosemnate vor fi discutate mai târziu. Vă rugăm să rețineți că, de obicei, proprietarul certificatului și al cheii private este utilizatorul rădăcină, drepturile asupra cheii private sunt de obicei setate la 0400 sau 0600, la certificatul 0444 sau 0644

Întrucât clientul înaintează întotdeauna mesajele intermediarului, el știe sigur că intermediarul are un certificat și știe exact care. Pentru ca clientul să se asigure că intermediarul este cine pretinde că este sau pentru a întrerupe trimiterea în cazul unei erori de verificare, este necesar să modifice setările TLS din partea clientului:

smtp_tls_security_level = amprentă smtp_tls_fingerprint_digest = sha1 smtp_tls_fingerprint_cert_match = XX:XX:XX:...
  • amprenta- nivel de securitate crescut la stabilirea unei conexiuni TLS - indicație explicită că este necesară verificarea amprentei certificatului
  • smtp_tls_fingerprint_digest
  • - lista de amprente certificate ale serverelor de încredere

Pentru a obține amprenta certificatului de server, trebuie să rulați comanda:

Amprenta SHA1=XX:XX:XX:…

Secvența de caractere rezultată după SHA1 Fingerprint= va fi valoarea necesară pentru smtp_tls_fingerprint_cert_match

Autorizare folosind TLS

Din păcate, nu este întotdeauna posibilă indicarea unei liste de rețele de încredere pe releu. De exemplu, această situație este posibilă atunci când expeditorul este un server virtual și adresa IP de ieșire poate să nu corespundă cu cea de intrare, dar se folosește adresa hypervisorului, prin care se realizează toate conexiunile de ieșire de la toate serverele virtuale pe care acesta îl servește - în această situație, adăugați adresa IP de ieșire a clientului la lista rețelelor de încredere este o decizie pripită și este necesară autorizarea

Pe partea clientului, conectarea unui certificat de autorizare la releu se realizează după cum urmează:

smtp_tls_cert_file = /etc/ssl/example.com.crt smtp_tls_key_file = /etc/ssl/example.com.key

Aici smtp_tls_cert_fileŞi smtp_tls_key_file numele de fișier al certificatului de client și, respectiv, cheia privată

Deoarece redirecționarea e-mailului se efectuează pe un port non-standard, se recomandă activarea verificării certificatelor client pe releu în configurația de transport (master.cf) pentru a nu afecta mesajele primite obișnuite (dacă este de așteptat):

8025 inet n - - - - smtpd -o smtpd_tls_req_ccert=yes -o smtpd_tls_security_level=criptare -o smtpd_tls_CAfile=/etc/ssl/certs/ca-certificates.crt -o smtpd_tls_fingerprint_digest=sha1 -o relay_clientcerts=hash:/etc/postfix/relay_clientcerts
  • smtpd_tls_req_ccert- cerere de certificat de client obligatorie
  • smtpd_tls_security_level- nivelul maxim de verificare a certificatului
  • smtpd_tls_CAfile- un fișier cu o listă de certificate ale autorităților de certificare de încredere (pentru FreeBSD de obicei /usr/local/share/certs/ca-root-nss.crt)
  • smtpd_tls_fingerprint_digest- verificați amprenta SHA1 în loc de MD5 implicit
  • relay_clientcerts- o hartă cu o listă de amprente ale certificatelor de client permise (cheie/valoare), unde este verificată doar cheia (amprenta)

Tabelul de amprente digitale pentru certificatele clientului /etc/postfix/relay_clientcerts este specificat ca:

XX:XX:XX:... exemplu.com

Unde XX:XX:XX:… - amprenta certificatului SHA1 obținută prin executarea comenzii
Da:

# openssl x509 -noout -fingerprint -in example.com.crt

Amprenta SHA1=XX:XX:XX:…

Secvența de caractere rezultată după SHA1 Fingerprint= va fi valoarea necesară, iar example.com va fi orice nume de client (nu este verificat de server). După modificarea versiunii text a hărții, trebuie să creați baza de date în sine executând comanda:

# postmap /etc/postfix/relay_clientcerts

Verificarea valabilității certificatului de client și a amprentei acestuia nu este suficientă pentru ca Postfix să permită redirecționarea e-mailurilor (rețineți lista de verificări smtpd_client_restrictions la începutul secţiunii). Pentru a activa redirecționarea, trebuie să permiteți clienților autorizați prin certificat să trimită în lista de verificare smtpd_recipient_restrictions:

smtpd_recipient_restrictions = permit_mynetworks, permit_tls_clientcerts, respinge

În acest caz, sunt permise conexiunile din rețele de încredere și conexiunile de la clienți autorizați printr-un certificat ( permit_tls_clientcerts), iar alte conexiuni sunt respinse. Listele de verificare sunt descrise mai detaliat în documentul SMTPD_ACCESS_README

Autorizare folosind login și parola

Utilizarea autorizației pe un releu folosind un nume de conectare și o parolă poate fi necesară dacă nu aveți control asupra releului pentru a configura autorizarea folosind certificate sau când destinatarii sunt distribuiți pe un număr mic de servere de e-mail pentru care expeditorul are conturi. În ambele cazuri, pentru autorizare trebuie să configurați clientul după cum urmează:

smtp_sasl_security_options = smtp_sasl_auth_enable = da smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
  • smtp_sasl_security_options- optiuni de autorizare. Valoare goală presupune utilizarea oricărui cale posibilă autorizare, deoarece opțiunile implicite pot fi incompatibile cu setările releului (de exemplu, gmail.com)
  • smtp_sasl_auth_enable- activați autorizarea prin autentificare și parolă
  • smtp_sasl_password_maps- card de autorizare
:587 gmail_user:gmail_parola :587 yandex_user:yandex_parola ...

Cheia pentru cardul de autorizare este numele releului (cum va fi folosit) și portul releu (portul 587 este un port alternativ pentru SMTP). Numele de utilizator și parola sunt specificate separate prin două puncte pentru releul corespunzător. După ce modificați versiunea text a hărții, trebuie să creați baza de date în sine și să setați drepturile de acces rulând comenzile:

# postmap /etc/postfix/sasl_passwd # chmod 0600 /etc/postfix/sasl_passwd # chmod 0600 /etc/postfix/sasl_passwd.db

În cazul utilizării unui singur releu, redirecționarea poate fi specificată sub forma:

relayhost = :587

Dacă trebuie să utilizați relee diferite în funcție de domeniul destinatar, trebuie să specificați o hartă de transport hărți_transport:

transport_maps = hash:/etc/postfix/transport

Unde să setați corespondența domeniului destinatarului cu transportul și retransmisul destinatarului (mai multe informații despre formatul hărții pot fi găsite la linkul formatului tabelului de transport Postfix):

gmail.com smtp::587 yandex.ru smtp::587... * eroare: transportul nu a fost găsit

După modificarea versiunii text a hărții, trebuie să creați baza de date în sine:

# postmap /etc/postfix/transport

La trimiterea de corespondență, unde unul public acționează ca un releu serviciul postal, este posibil să întâmpinați diverse restricții. Deci, de exemplu, unii servicii postale cere ca numele expeditorului scrisorii să se potrivească cu numele utilizatorului autorizat pe releu

Pentru a rescrie adresa expeditorului, utilizați parametrul smtp_generic_maps:

smtp_generic_maps = hash:/etc/postfix/generic

Unde harta de rescriere a adresei /etc/postfix/generic arată astfel:

@example.com [email protected]

Iată toate adresele din domeniul @example.com (de exemplu, [email protected]) va
suprascris cu adresa [email protected]. După modificarea versiunii text a hărții, trebuie să creați baza de date în sine:

# postmap /etc/postfix/generic

Pentru a lucra cu mai multe relee, atunci când trebuie să schimbați adresa expeditorului în funcție de domeniul destinatarului, trebuie să „divizați” transportul smtp pentru mai multe transporturi virtuale, pentru fiecare dintre acestea setând propriul parametru smtp_generic_maps. În acest caz, harta de transport /etc/postfix/transport poate fi reprezentată ca:

gmail.com gmail: yandex.ru yandex: ... * eroare: transportul nu a fost găsit

Aici, diferite domenii destinatare corespund transporturilor virtuale diferite. Transporturile virtuale în sine sunt configurate în master.cf:

gmail unix - - n - - smtp -o transport_maps= -o relayhost=:587 -o smtp_generic_maps=hash:/etc/postfix/generic_gmail yandex unix - - n - - smtp -o transport_maps= -o relayhost=:587 -o smtp_generic_maps=hash:/etc/postfix/generic_yandex

În exemplul de mai sus, pentru fiecare transport virtual, harta de transport este dezactivată (pentru a evita recursiunea nesfârșită), portul gazdă al releului corespunzător este setat și un card virtualîn fiecare dintre acestea puteți (ar trebui) să rescrieți toate adresele din domeniul @example.com la adresa utilizatorului din domeniile @gmail.com și, respectiv, @yandex.ru

Proxy prin TOR

O modalitate de a ocoli un punct de control permanent este folosind TOR- „rețele de rutare ceapă”. TOR poate fi folosit numai împreună cu un releu de încredere - serverul dvs. de e-mail propriu sau public, deoarece încercarea de a trimite e-mail direct prin TOR va eșua cel mai probabil - marea majoritate a ieșirilor SMTP provin de la rețele TOR este sancționat de marile sisteme poștale. De asemenea, utilizarea rețelei TOR nu oferă nicio garanție cu privire la prezența sau absența unor puncte de control suplimentare la punctul de ieșire, dar schimbarea periodică a rutelor oferă șansa de a găsi un punct de ieșire necontrolat.

Pentru a rula un proxy SOCKS, trebuie doar să setați adresa și portul pentru acceptarea conexiunilor de intrare în fișierul de configurare TOR (/etc/tor/torrc sau /usr/local/etc/tor/torrc pentru FreeBSD): (documentația despre opțiuni):

SocksPort 9050 SocksListenAddress 127.0.0.1

Pentru a trimite traficul Postfix către un proxy SOCKS, va trebui să introduceți un transport suplimentar care să accepte acest tip de proxy. Cel mai simplu mod este să descărcați o aplicație cu o bibliotecă care redirecționează în mod transparent toate conexiunile TCP către proxy. O astfel de bibliotecă, de exemplu, este șosete

Configurația parametrilor de funcționare a bibliotecii tsocks este specificată în fișierul /etc/tsocks.conf (sau /usr/local/etc/tsocks.conf pentru FreeBSD):

local = 127.0.0.1/255.255.255.255 server = 127.0.0.1 server_ENGINE= 5 server_port = 9050

Iată parametrul local este o listă de gazde care sunt accesibile fără a utiliza un proxy, parametrii rămași indică adresa și portul proxy-ului SOCKS-5 TOR

Pentru a crea un transport Postfix, trebuie să creați un script numit /usr/lib/postfix/smtp_socks, cum ar fi:

#!/bin/sh export LD_PRELOAD=/usr/lib/libtsocks.so exec /usr/lib/postfix/smtp $@

și acordați-i drepturi de execuție (chmod 0755 smtp_socks). Pe FreeBSD fișiere executabile transporturile sunt situate în directorul /usr/local/libexec/postfix, iar biblioteca este în /usr/local/lib

smtp unix - - n - - smtp_socks

Aici ar trebui să acordați atenție valorii n din câmpul chroot - în Debian este setat la - (sau da) în mod implicit, ceea ce va împiedica încărcarea bibliotecii libtsocks.so fără setări suplimentare de mediu chroot

Postfix este agentul de transfer de e-mail (MTA) implicit în Ubuntu. Încearcă să fie rapid și ușor de administrat și sigur. Este compatibil cu MTA sendmail. Această secțiune explică cum se instalează și se configurează postfix. De asemenea, explică cum să îl configurați ca server SMTP utilizând o conexiune securizată (pentru a trimite e-mailuri în siguranță).

Instalare

Pentru a instala postfix, rulați următoarea comandă:

sudo apt install postfix

Pur și simplu apăsați return când procesul de instalare pune întrebări, configurarea se va face mai detaliat în etapa următoare.

Configurație de bază

Pentru a configura postfix, rulați următoarea comandă:

sudo dpkg-reconfigure postfix

Va fi afișată interfața cu utilizatorul. Pe fiecare ecran, selectați următoarele valori:

  • mail.example.com

    mail.example.com, localhost.localdomain, localhost

    127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/24

Înlocuiți mail.example.com cu domeniul pentru care veți accepta e-mail, 192.168.0.0/24 cu rețeaua reală și gama de clasă a serverului dvs. de e-mail și Steve cu numele de utilizator corespunzător.

Acum este un moment bun pentru a decide ce format de cutie poștală doriți să utilizați. În mod implicit, Postfix va folosi mbox pentru formatul căsuței poștale.

În loc să editați direct fișierul de configurare, puteți utiliza comanda postconf pentru a configura toți parametrii postfix. Parametrii de configurare vor fi stocați în fișierul /etc/postfix/main.cf. Mai târziu, dacă doriți să reconfigurați un anumit parametru, puteți fie să rulați comanda, fie să o modificați manual în fișier.

Pentru a configura formatul cutiei poștale pentru Maildir:

sudo postconf -e "home_mailbox = Maildir/"

Acest lucru va plasa e-mailuri noi în /home/nume utilizator /Maildir, așa că va trebui să configurați Agentul de livrare a e-mailurilor (MDA) pentru a utiliza aceeași cale.

Autentificare SMTP

    SMTP-AUTH permite unui client să se identifice printr-un mecanism de autentificare (SASL).

    Transport Layer Security (TLS) ar trebui utilizat pentru a cripta procesul de autentificare.

    Odată autentificat, serverul SMTP va permite clientului să retransmită corespondența.

    Configurați Postfix pentru SMTP-AUTH utilizând SASL (Dovecot SASL): sudo postconf -e "smtpd_sasl_type = porumbel" sudo postconf -e "smtpd_sasl_path = private/auth" sudo postconf -e "smtpd_sasl_local_domain =" sudo postconf -e "smtpd_sasl_security_options = noanonymous_auth" " sudo postconf - e "smtpd_sasl_auth_enable = yes" sudo postconf -e "smtpd_recipient_restrictions = \permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination" Configurația smtpd_sasl_path este o cale relativă la directorul de coadă Postfix. Apoi, generați sau obțineți un certificat digital pentru TLS. Vedea Certificate pentru detalii..

    MUA-urile care se conectează la serverul dvs. de e-mail prin TLS vor trebui să recunoască certificatul utilizat pentru TLS. Acest lucru se poate face fie folosind un certificat de la o CA comercială, fie cu un certificat autosemnat pe care utilizatorii îl instalează/accepta manual. Pentru MTA la MTA, certificările TLS nu sunt niciodată validate fără acordul prealabil al organizațiilor afectate. Pentru MTA la MTA TLS, cu excepția cazului în care politica locală o cere, nu există niciun motiv pentru a nu utiliza un certificat autosemnat. Consultați Crearea unui certificat autosemnat

    pentru mai multe detalii.

    După ce aveți un certificat, configurați Postfix pentru a furniza criptare TLS atât pentru e-mailurile primite, cât și pentru cele trimise:

    sudo postconf -e "smtp_tls_security_level = mai" sudo postconf -e "smtpd_tls_security_level = poate" sudo postconf -e "smtp_tls_note_starttls_offer = yes" sudo postconf -e "smtpd_tls_server_tls/postconf -e" e" smtpd_tls_cert_file = /etc/ssl/certs/server.crt" sudo postconf -e "smtpd_tls_loglevel = 1" sudo postconf -e "smtpd_tls_received_header = yes" sudo postconf -e "examplename.com mail.

    Dacă utilizați propria autoritate de certificare pentru a semna certificatul, introduceți:

sudo postconf -e "smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem" După rularea tuturor comenzilor, Postfix este configurat pentru SMTP-AUTH și un certificat autosemnat a fost

creat pentru criptarea TLS.

# Consultați /usr/share/postfix/main.cf.dist pentru o versiune comentată și mai completă # smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no # appending .domain is job's MUA. append_dot_mydomain = no # Descomentați următoarea linie pentru a genera avertismente „e-mail întârziat” #delay_warning_time = 4h numele gazdăului meu = server1.example.com hărți_alias = hash:/etc/aliases baza de date alias = hash:/etc/aliases myorigin = /etc/mailname mydestination = server1.example. com, localhost.example.com, localhost relayhost = mynetworks = 127.0.0.0/8 mailbox_command = procmail -a „$EXTENSION” mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all smtpd_sasl_local_domain = smtpd_sasl_local_domain = smtpd_asl_local_domain = smtpd_assl_size_options _sasl_auth_clients = yes smtpd_recipient_restrictions = permit_sasl_authenticated ,permit_mynetworks,reject _unauth_destination smtpd_tls_auth_only = nu smtp_tls_security_level = poate smtpd_tls_security_level = poate smtp_tls_note_starttls_offer = yes/stls_tls_security_level d.key smtpd_ tls_cert_file = /etc/ssl/certs/smtpd.crt smtpd_tls_CAfile = /etc/ssl/certs / cacert.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = da smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom

Configurația inițială postfix este completă. Rulați următoarea comandă pentru a reporni demonul postfix:

Postfix acceptă SMTP-AUTH așa cum este definit în RFC2554.

Se bazează pe SASL. Cu toate acestea, este încă necesar să configurați autentificarea SASL înainte de a putea utiliza SMTP-AUTH.

Configurarea SASL

Postfix acceptă două implementări SASL Cyrus SASL și Dovecot SASL. Pentru a activa Dovecot SASL, va trebui instalat pachetul dovecot-core. Dintr-un prompt de terminal, introduceți următoarele:

sudo apt install dovecot-core În continuare va trebui să editați/etc/dovecot/conf.d/10-master.conf

. Schimbați următoarele:

Pentru a permite clienților Outlook să utilizeze SMTP-AUTH, în secțiunea mecanisme de autentificare din /etc/dovecot/conf.d/10-auth.conf modificați această linie:

auth_mechanisms = plain

auth_mechanisms = autentificare simplă

După ce ați configurat Dovecot, reporniți-l cu:

sudo systemctl reporniți dovecot.service

Livrare prin stiva de corespondență

O altă opțiune pentru configurarea Postfix pentru SMTP-AUTH este utilizarea pachetului mail-stack-delivery (ambalat anterior ca dovecot-postfix).

Acest pachet va instala Dovecot și va configura Postfix să-l folosească atât pentru autentificarea SASL, cât și ca agent de livrare a corespondenței (MDA).

Este posibil să doriți sau nu să rulați IMAP, IMAPS, POP3 sau POP3S pe serverul dvs. de e-mail. De exemplu, dacă vă configurați serverul pentru a fi o poartă de e-mail, filtru de spam/virus etc. Dacă acesta este cazul, poate fi mai ușor să utilizați comenzile de mai sus pentru a configura Postfix pentru SMTP-AUTH decât utilizarea mail-stack-delivery .

Pentru a instala pachetul, dintr-un prompt de terminal introduceți:

sudo apt install mail-stack-delivery sudo postconf -e "smtpd_sasl_type = porumbel" sudo postconf -e "smtpd_sasl_path = private/auth" sudo postconf -e "smtpd_sasl_local_domain =" sudo postconf -e "smtpd_sasl_security_options = noanonymous_auth" " sudo postconf - e "smtpd_sasl_auth_enable = yes" sudo postconf -e "smtpd_recipient_restrictions = \permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination" Crearea unui certificat autosemnat

Acum ar trebui să aveți un server de e-mail funcțional, dar există câteva opțiuni pe care poate doriți să le personalizați în continuare. De exemplu, pachetul folosește certificatul și cheia din pachetul ssl-cert (autosemnat), iar într-un mediu de producție ar trebui să utilizați un certificat și cheia generate pentru gazdă.

Vedea

După ce aveți un certificat și o cheie personalizate pentru gazdă, modificați următoarele opțiuni pentru postfix în /etc/postfix/main.cf pentru a se potrivi cu noile chei: smtpd_tls_cert_file = #yourcertfile# smtpd_tls_key_file = #yourkeyfile#:

Și pentru Dovecot în<#yourcertfile# ssl_key = <#yourkeyfile#

/etc/dovecot/conf.d/10-ssl.conf

ssl_cert =

Apoi reporniți Postfix:

sudo systemctl restart postfix.service

Testare

Configurarea SMTP-AUTH este finalizată. Acum este timpul să testați configurația.

Pentru a vedea dacă SMTP-AUTH și TLS funcționează corect, rulați următoarea comandă:

telnet mail.example.com 25

După ce ați stabilit conexiunea la serverul de e-mail postfix, tastați:

250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250 8BITMIME

ehlo mail.example.com

Dacă vedeți următoarele rânduri printre altele, atunci totul funcționează perfect. Tastați ieșire pentru a ieși.

Depanare

Această secțiune prezintă câteva modalități comune de a determina cauza în cazul în care apar probleme.

Scăpat de chroot

Pachetul Ubuntu postfix se va instala în mod implicit într-un mediu chroot din motive de securitate. Acest lucru poate adăuga o complexitate mai mare la depanarea problemelor.

Pentru a dezactiva operația chroot, găsiți următoarea linie în fișierul de configurare /etc/postfix/master.cf:

smtp inet n - - - - smtpd

Va trebui apoi să reporniți Postfix pentru a utiliza noua configurație. Dintr-un prompt de terminal, introduceți:

ssl_cert =

Dacă aveți nevoie de smtps, editați /etc/postfix/master.cf și decomentați următoarea linie:

smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daINA_MACRO_DAINA

Fișiere jurnal

Postfix trimite toate mesajele de jurnal la /var/log/mail.log .

  • Cu toate acestea, mesajele de eroare și de avertizare se pot pierde uneori în ieșirea normală a jurnalului, așa că sunt înregistrate și în /var/log/mail.err și, respectiv, /var/log/mail.warn.

    un fel de recenzie „scurtă”... de parcă s-ar grăbi undeva