Postfix: configurarea trimiterii e-mailurilor în Asterisk. Postfix. Trimiterea de e-mailuri prin SMTP extern

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ă între paranteze drepte este folosită pentru a vă 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 utilizat 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- o listă de verificări în etapa de stabilire a conexiunii În acest caz, sunt permise conexiunile din rețele de încredere, iar celelalte 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ță la port non-standard, trebuie adăugat (dacă intenționați să primiți mail regulat) 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, trebuie să configurați TLS 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 amprentă a certificatului 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ărei posibile metode de 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ă modificarea versiunii 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 Serviciu poștal, este posibil să întâmpinați diverse restricții. Deci, de exemplu, unii servicii poștale 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]) voi
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 ș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 sub sancțiuni de la major 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 în fișierul de configurare TOR (/etc/tor/torrc sau /usr/local/etc/tor/torrc pentru FreeBSD) pentru a accepta conexiunile de intrare (documentația opțiunilor):

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 ar accepta acest tip proxy. Cel mai într-un mod simplu este să încă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

Aici este 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 lui n în câmpul chroot - pe Debian este setat la - (sau da) în mod implicit, ceea ce va împiedica încărcarea bibliotecii libtsocks.so fără setari aditionale medii chroot

Scrisorile trimise de pe site prin funcția mail() în 99% din cazuri ajung în spam, dacă dvs Server SMTP nu profesionist. Adesea există o nevoie urgentă de instalare și amendă Setări SMTP Webmasterul nu, și chiar mai des, este doar 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ă. , deoarece Există foarte puține solicitări pentru funcția"? Și este cu adevărat 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șa, dacă nu puteți face motorul să funcționeze SMTP extern, atunci trebuie să faceți ca funcția standard mail() să funcționeze cu ea. 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: Server sub Ubuntu 12.04 cu gazdă host.domain.name, Numele domeniului 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]:parola
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 apache rulează pe gazda virtuală și în numele căruia CMS-ul 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ă dvs. și Google Apps aveți totul configurat corect și o semnătură digitală este atribuită domeniului, atunci 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.

| |

Postfix este un Agent de transfer de e-mail (MTA), o aplicație pentru trimiterea și primirea E-mail. Acest ghid arată cum să instalați și să configurați Postfix pentru a trimite mesaje numai către aplicațiile locale (adică aplicațiile instalate pe același server ca Postfix).

De ce este necesar acest lucru?

Când utilizați un furnizor de servicii de e-mail terță parte, nu este nevoie să rulați propriul dvs server de mail. Dacă pe serverul cloud sunt instalate aplicații care trebuie să trimită notificări prin e-mail, atunci server SMTP local Transferul de mesaje va fi o alternativă excelentă la un furnizor de servicii de e-mail terț și la un server SMTP complet.

Un exemplu excelent de aplicație de alertă este OSSEC; acest sistem poate trimite alerte la orice adresă de e-mail specificată. La fel ca multe alte aplicații de acest gen, OSSEC poate folosi fie un server SMTP terță parte, fie un server local de transfer de mesaje SMTP pentru a trimite notificări.

Notă: Dacă trebuie să primiți notificări de la server la o singură adresă, este recomandat să creați o listă albă de adrese de e-mail care pot ajunge accidental în spam.

Dacă serverul trebuie să trimită notificări către potențialii utilizatori ai site-ului (de exemplu, confirmări electroniceînregistrare), trebuie să vă protejați domeniul de spammeri; atunci este mai puțin probabil ca notificările de server să fie marcate ca spam.

Cerințe

Pentru a finaliza acest ghid veți avea nevoie de:

Și Cont utilizator cu privilegii sudo extinse;
Un nume de domeniu valid (acest ghid folosește domeniul fictiv example.com).

Numele de gazdă al serverului trebuie să se potrivească cu acest domeniu sau subdomeniu. Pentru a verifica numele de gazdă a serverului, introduceți Linie de comanda nume de gazdă. Ieșirea ar trebui să se potrivească cu numele serverului care a fost dat când a fost creat (de exemplu, example.com).

1: Instalați Postfix

Pentru a instala Postfix, precum și o serie de alte programe necesare pentru configurarea e-mailului, pur și simplu instalați pachetul mailutils:

sudo apt-get install mailutils

Postfix și dependențele sale vor fi instalate cu pachetul mailutils. Ieșirea comenzii arată cam așa:

Următoarele pachete NOI vor fi instalate:
guile-2.0-libs libgsasl7 libkyotocabinet16 libltdl7 liblzo2-2 libmailutils4 libmysqlclient18 libntlm0 libunistring0 mailutils mailutils-common mysql-common postfix ssl-cert
0 actualizate, 14 nou instalate, 0 de eliminat și 3 neactualizate.
Trebuie să obțineți 5.481 kB de arhive.
După această operațiune, se vor folosi 26,9 MB de spațiu suplimentar pe disc.
Doriți să continuați?

Pentru a instala toate pachetele de mai sus, apăsați ENTER. La sfârșitul instalării va apărea o fereastră Setări Postfix, în care trebuie să selectați tipul de setări de e-mail; Opțiunea implicită este Site Internet, care se potrivește mai bine cerințelor acestui ghid (apăsați TAB și ENTER pentru a confirma).

După aceasta, va apărea o nouă fereastră de configurare Postfix cu câmpul System mail name. Acest câmp trebuie să se potrivească cu numele serverului pe care l-ați ales când l-ați creat. Introduceți un nume, apoi apăsați TAB și ENTER.

Notă: Dacă în șir apare un subdomeniu precum first.example.com, scurtați-l la example.com.

2: Configurarea Postfix

Această secțiune vă va arăta cum să configurați Postfix pentru a trimite mesaje de pe serverul pe care este instalat (adică localhost).

Pentru a face acest lucru, Postfix trebuie configurat să asculte numai pe interfața loopback - aceasta este o interfață de rețea virtuală care este utilizată de server pentru comunicarea internă. Deschideți fișierul de configurare Postfix folosind editorul nano:

sudo nano /etc/postfix/main.cf

Găsiți următorul bloc de cod în el:

cutie_poștală_size_limit = 0
destinatar_delimiter = +
inet_interfaces = all

Înlocuiți linia inet_interfaces = all cu linia inet_interfaces = loopback-only. Acum acest bloc arată astfel:

cutie_poștală_size_limit = 0
destinatar_delimiter = +
inet_interfaces = doar loopback

În loc de doar loopback, puteți utiliza și localhost:

cutie_poștală_size_limit = 0
destinatar_delimiter = +
inet_interfaces = localhost

După ce ați terminat de editat fișierul, salvați modificările și închideți-l (CTRL+X, apoi Y și ENTER). După aceasta, reporniți Postfix:

sudo service postfix restart

3: Testarea serverului SMTP

Acum trebuie să verificați dacă Postfix poate trimite mesaje la o adresă de e-mail externă. Pentru a face acest lucru, utilizați comanda mail, care este, de asemenea, inclusă în pachetul mailutils.

Deci, pentru a trimite un mesaj de testare, tastați:

echo „Acesta este corpul e-mailului” | mail -s „Acesta este subiectul” [email protected]

Notă: În loc de [email protected] Vă rugăm să utilizați o adresă de e-mail validă.

Verificați căsuța poștală la care a fost trimis mesajul. Dacă mesajul trimis nu apare, verificați folderul de spam.

Notă: Acest manual folosește o adresă fictive [email protected], unde gunter este numele utilizator Linux, iar domeniul este numele gazdei serverului (această linie trebuie specificată în câmpul De la).

4: Redirecționarea e-mailului

În cele din urmă, trebuie să configurați redirecționarea (sau redirecționarea) e-mailurilor astfel încât serverul să poată redirecționa mesajele trimise utilizator root, la adresa dumneavoastră externă personală.

Pentru ca Postfix să trimită mesaje generate de sistem către dvs adresa poștală, editați /etc/aliases.

sudo nano /etc/aliases

ÎN instalare standard Ubuntu 14.04 acest fișier arată astfel:

postmaster: rădăcină

Această setare redirecționează mesajele de sistem către utilizatorul root. Acum trebuie să vă asigurați că mesajele sunt redirecționate către adresa dvs. de e-mail. Pentru a face acest lucru, adăugați linia în fișier:

# Vedeți aliasurile man 5 pentru format
postmaster: rădăcină
rădăcină: [email protected]

A inlocui [email protected] cu adresa ta personală de e-mail. Salvați și închideți fișierul. Pentru ca modificările să intre în vigoare, executați următoarea comandă:

Acum testați redirecționarea trimițând un mesaj utilizatorului root:

echo „Acesta este corpul e-mailului” | mail -s Rădăcina „Acesta este linia de subiect”.

Acest mesaj ar trebui să apară în dvs cutie poștală(dacă nu, verificați folderul de spam).

Etichete: ,

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ătoarele comanda:

sudo apt install postfix

Pur și simplu apăsați revenire 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 fișierul de configurare direct, 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/"

Aceasta 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ă transmită e-mail.

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. Consultați Certificate pentru detalii. Acest exemplu folosește și o Autoritate de Certificare (CA). Pentru informații despre generarea unui certificat CA, consultați Autoritatea de certificare.

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 a fost creat un certificat autosemnat pentru criptarea TLS.

Acum, fișierul /etc/postfix/main.cf ar trebui să arate astfel:

# 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. Modificați următoarele:

service auth ( # auth_socket_path indică în mod implicit către acest socket userdb. Este de obicei # folosit de dovecot-lda, doveadm, eventual procesul imap etc. Permisiunile implicite # fac să fie citit numai de root, dar poate fi necesar să le relaxați # permisiuni Utilizatorii care au acces la acest socket sunt capabili să obțină o listă # cu toate numele de utilizator și să obțină rezultate ale căutărilor userdb ale tuturor. /var/spool/postfix/private/auth (mod = 0660 utilizator = grup postfix = postfix)

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).

Puteți sau poate nu doriți 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

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 cheie din pachetul ssl-cert (autosemnat), iar într-un mediu de producție ar trebui să utilizați un certificat și o cheie generate pentru gazdă. Consultați Certificate pentru mai multe detalii.

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 /etc/dovecot/conf.d/10-ssl.conf:

ssl_cert =<#yourcertfile# ssl_key = <#yourkeyfile#

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:

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.

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

Depanare

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

Scăpând 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

și modificați-l după cum urmează:

smtp inet n - n - - smtpd

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

sudo systemctl restart postfix.service

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, în /var/log/mail.warn.