Cum se configurează smartphone-uri și PC-uri. Portal informativ
  • Acasă
  • Recenzii
  • Configurarea e-mailului (fără e-mailuri spam). Pierderea mesajelor de e-mail

Configurarea e-mailului (fără e-mailuri spam). Pierderea mesajelor de e-mail

Configurarea trimiterii de e-mailuri fără a le introduce în spam.

Nu voi lua în considerare opțiunea de a trimite scrisori prin servere SMTP terțe (Mandrill, Mailgun, Yandex) și prin adresele personale ale serviciilor de e-mail (totul este foarte simplu acolo dacă urmați instrucțiunile de instalare furnizate) - voi lua în considerare doar opțiunea că avem propriul nostru server, pe care este instalat un server de mail corespunzător, de exemplu Exim (ca majoritatea hoster-urilor).

Avem nevoie de acces pentru a edita înregistrările DNS și de proprietate minimă a consolei pentru a configura DKIM (dacă ISPmanager este disponibil, acest element devine irelevant). În total, trebuie să configurați (adăugați) 4 înregistrări noi în înregistrările DNS ale domeniului dvs.: PTR, SPF, DKIMși DMARC.

  • PTR- așa-numita înregistrare DNS „inversată”. Ar trebui să fie obligatoriu, deoarece un număr foarte mare de servicii de poștă sunt intolerabile la indicarea lui incorectă. În teorie, ar trebui să fie instalat de furnizorul dvs. de găzduire, de exemplu DigitalOcean face acest lucru automat. - dar există o opțiune pentru setarea sa manuală.
  • SPF- o înregistrare care indică faptul că serverul dumneavoastră are permisiunea de a trimite scrisori din acest domeniu și IP. Dacă această intrare este absentă, intrarea în spam este aproape garantată. Instalarea este foarte simplă - puteți obține informații complete cu exemple de configurare la (informații din plăcuța verde) sau la.
  • DKIM- semnătura electronică a scrisorilor dumneavoastră. Dacă aveți două înregistrări anterioare, vă oferă domeniul și literele din acesta „greutate”, datorită cărora același Yandex, de exemplu, marchează literele cu o bifă verde frumoasă.

Configurarea acestei semnături este poate cea mai dificilă - drept urmare, 90% dintre site-uri nu o au, dar este foarte recomandată. Este foarte ușor să-l configurați în ISPmanager: activați suportul DKIM în fila caracteristici, când editați un domeniu de e-mail, bifați caseta DKIM și ridicați o înregistrare gata făcută în proprietățile domeniului (NS). Dacă ISPmanager nu este disponibil, vă sfătuiesc să folosiți acest articol destul de simplu:.

  • DMARC- standardul este complet nou, dar este deja introdus activ de către serviciile poștale, iar anul acesta este deja 100% obligatoriu. Configurarea este cea mai simplă dintre toate intrările de mai sus, trebuie doar să adăugați unul dintre exemplele prezentate pe această pagină mai jos: - Recomand pe al doilea.
Serverul dvs. este acum configurat și dacă totul este făcut corect, nici o singură literă nu va ajunge la spam. De exemplu, confirmarea unei capturi de ecran de la oficiul poștal mail.ru (o situație similară cu absența completă a definiției literelor ca spam și pentru Yandex):

Configurarea colectorului de e-mail de returnare.

XenForo are un mecanism absolut uimitor care nu este folosit aproape niciodată de nimeni - colectorul de e-mailuri de respingere. Cred că toată lumea s-a confruntat cu situația că, după o corespondență în masă, la cutia poștală ajung un număr mare de scrisori de următorul tip:

Acest mesaj a fost creat automat de software-ul de livrare a corespondenței.

Un mesaj pe care l-ați trimis nu a putut fi livrat către unul sau mai multe dintre ele
destinatarii. E o eroare permanenta. Următoarele adrese nu au reușit:

***@rambler.ru
Eroare SMTP de la serverul de e-mail la distanță după RCPT TO:<***@rambler.ru>:
gazdă imx1.rambler.ru: 540 5.7.1<***@rambler.ru>:
Adresa destinatarului a fost respinsă: e-mailurile dvs. au fost returnate deoarece contul de e-mail al destinatarului a fost suspendat. Contul trebuie reactivat pentru a primi mesajele primite.

Aceste scrisori sunt un semnal că utilizatorii dvs. și-au depășit adresele de e-mail (cutiile poștale sunt blocate, șterse, debordând), ceea ce înseamnă că nu vor primi scrisori noi de la dvs. și, dacă este necesar, nu își vor putea restabili contul nici pe forum. . Mulți utilizatori nici măcar nu știu că folosesc o adresă de e-mail învechită, iar serviciile poștale, văzând un număr mare de e-mailuri trimise la adrese inexistente, vă pot pune în mod ciudat domeniul pe lista de spam.

Trebuie să luptăm cu asta, deoarece chiar și pe forumul meu, unde acest sistem a funcționat de mai mult decât prima listă de corespondență, există o mulțime de scrisori „returnite”, în comparație cu numărul de utilizatori:

  • Pentru început, creăm o adresă de corespondență la care vom trimite scrisorile returnate (căsuța poștală a sistemului nu trebuie utilizată în alte scopuri) - de exemplu unde google.com este domeniul dvs.
  • Accesați secțiunea de administrare Setări - Setări de e-mail... În câmpul adresa pentru returnarea scrisorilor, indicați căsuța poștală pe care ați creat-o. Bifăm procesarea automată a scrisorilor nelivrate și indicăm datele pentru introducerea căsuței poștale de serviciu pe care ați creat-o anterior: adresa (în cazul propriului server SMTP, specificați-l pe al dvs.), login (adresa creată de dvs.) și parola pentru căsuța poștală. Voi da un exemplu de setări - am e-mail de afaceri de la Mail.ru - prin urmare, mă conectez la serverul lor pentru a primi e-mail de la o cutie de servicii

Practic, asta e toată configurația. Forumul se va conecta automat la căsuța poștală de serviciu pe care ați specificat-o la anumite intervale, va descărca copii ale scrisorilor returnate pe care le-a primit și le va șterge de acolo. În capitolul Instrumente - Jurnal de respingere a livrării e-mailului puteți vizualiza aceste statistici. Subliniez că această cutie poștală nu poate fi folosită în alte scopuri, altfel riscați să obțineți câteva bug-uri destul de amuzante în jurnalele panoului de administrare.

Conform condițiilor pe care le-ați stabilit, atunci când, de exemplu, sunt returnate 3 scrisori de la o adresă, utilizatorul va fi trimis pentru reactivare automată - i se va cere să introducă o adresă de email validă și să reactiveze contul. Participarea dvs. nu este necesară în niciun fel - utilizatorii își vor indica ei înșiși adresele de e-mail reale și, prin urmare, problema va dispărea cu timpul. Și cu e-mailuri, utilizatorii cu o adresă de e-mail incorectă pot fi excluși din aceasta - evitând astfel o posibilă cădere în listele de spam.

S-a scris mult text, dar, de fapt, configurarea totul - atât serverul, cât și colectorul de corespondență, durează câteva minute, dacă urmați întocmai instrucțiunile. Configurați-o o dată și uitați că mesajele de pe forumul dvs. nu au ajuns undeva sau că domeniul dvs. a fost inclus în listele de spam pentru irelevanța bazei de date.

Pentru a simplifica unele dintre sarcinile descrise mai sus, puteți utiliza oricare - orice vă place mai mult. Eu îl folosesc pe primul - dar alegerea este complet a ta. Adăugarea de domenii acolo va oferi cutii poștale convenabile, de dimensiuni nelimitate, cu filtre de spam deja încorporate + o oarecare simplificare a configurației serverului (unele dintre înregistrările vor fi furnizate automat (cu excepția DKIM, care trebuie generat manual într-un mod sau altul pentru a trimite). mail de pe serverul dvs.)).

Exemple de scrisori:

550 5.7.1 Acest mesaj nu a fost acceptat din cauza politicii DMARC a proprietarului domeniului (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc

550-5.7.1 E-mailul neautentificat de la mail.ru nu este acceptat din cauza politicii DMARC 550-5.7.1 a domeniului. Vă rugăm să contactați administratorul domeniului mail.ru dacă acest 550-5.7.1 a fost un e-mail legitim. Vă rugăm să vizitați 550 -5.7.1 https://support.google.com/mail/answer/2451690 pentru a afla despre DMARC

550 5.7.1 E-mail respins conform politicii DMARC pentru...

Problemă de livrare a mesajelor legată de aplicarea noii politici DMARC legate de înăsprirea regulilor de trecere a filtrelor de spam.

DMARC Este un protocol de protecție împotriva spam-ului și împotriva distribuirii neautorizate de e-mail în numele unui domeniu, bazat pe mecanismele existente DKIM și SPF... Site oficial: dmarc.org.

Dacă primiți mesaje similare celor de mai sus, cel mai probabil, e-mailurile de pe site-ul dvs. sunt trimise în numele unei căsuțe poștale bazate pe @ mail.ru, @ bk.ru, @ list.ru sau @ inbox.ru... Mail.Ru nu acceptă mesaje trimise prin phpmail dacă antetul e-mailului conține o căsuță poștală aparținând mail.ru. Astfel de mesaje, conform politicii implementate de Mail.Ru DMARC sunt respinse.

Cum se rezolvă problema

Există două moduri de a rezolva problema:

Metoda 1: schimbați căsuța poștală din care sunt trimise mesajele

De obicei, e-mailul în numele căruia sunt trimise mesajele de e-mail este înregistrat în partea administrativă a CMS. De asemenea, poate fi schimbat direct în scriptul de trimitere a mesajelor (câmpul „De la”).

Este necesar ca mesajele să fie trimise dintr-o cutie poștală pe baza numelui dumneavoastră de domeniu, de exemplu « [email protected]» , unde domain.ru este domeniul dvs. ...

De asemenea, cutia poștală trebuie schimbată în fișierul php.ini:

Schimbarea căsuței poștale în php.ini

  1. 1 intrați în panoul de control al găzduirii și deschideți fișierul php.ini pentru editare:;
  2. 2

    găsiți o linie ca:

    sendmail_path = "/ usr / sbin / sendmail -t -i -f [email protected]"

    În această linie, în loc de « [email protected]» specificați o cutie poștală care nu are legătură cu domenii @ mail.ru, @ bk.ru, @ list.ruși @ inbox.ru.
    Este recomandabil să specificați o cutie poștală pe domeniul dvs., de exemplu, « [email protected]» , unde domain.ru este domeniul dvs.

    În plus, cutia poștală înregistrată în php.ini trebuie să existe. Dacă utilizați e-mail pe o găzduire, creați o cutie poștală pe domeniu și scrieți-o în fișierul php.ini.

Metoda 2: utilizați autentificarea SMTP

Puteți trimite mesaje în numele căsuței dvs. poștale bazate pe Mail.Ru prin configurarea autorizației SMTP. În acest caz, toate mesajele prin intermediul site-ului dvs. vor fi trimise direct de pe serverele Mail.Ru.

Erorile sistemului de e-mail sunt coduri care sunt atribuite mesajelor în timpul primirii sau refuzării primirii. Codul de eroare vă permite să aflați motivul pentru care mesajul e-mail nu a putut fi livrat. De obicei, codul de eroare este un număr, cum ar fi # 550 sau # 2001. Codurile de eroare sunt descrise mai jos.

Mesaje fără coduri

Adresă nedirecționabilă

Nu s-a putut determina serverul către care doriți să redirecționați mesajul e-mail. Motive posibile:

  • Domeniul către care este trimis e-mailul nu există sau nu este delegat
  • Nici înregistrările MX, nici A nu sunt înregistrate pentru domeniu
  • Înregistrarea MX indică un nume inexistent

utilizator necunoscut

Cutia poștală dată nu există sau adresa de corespondență a fost specificată cu o eroare

Transmisie în curs. Rămâneți aproape

Mesajul apare atunci când clientul de mail trimite scrisori. Acest mesaj nu provine din sistemul nostru de e-mail. Înseamnă că utilizatorul din rețeaua locală are un antispam sau un firewall care verifică toate mesajele trimise.

Peste cotă

Eroare LMTP după încheierea datelor: 552 5.2.2 Cotă depășită
Eroarea apare dacă căsuța poștală a destinatarului este plină.

Mesaje cu coduri

#1005

Înștiințarea de verificare a expeditorului a eșuat
Verificarea expeditorului scrisorii. Eroarea poate fi fie completă, după cum se indică mai jos, fie abreviată: „Verificarea expeditorului a eșuat [# 1005]”. Eroarea este trimisă de un server care a făcut o încercare nereușită de a trimite un e-mail către serverul nostru. Serverul nostru este listat în rândul „... în timp ce vorbim cu mx3.site .:”.

Adresele următoare au avut erori fatale permanente ----- (motiv: 550-Verificarea eșuată pentru ) ----- Urmează transcrierea sesiunii ----- ... în timp ce vorbiți cu mx3. Site .: >>> MAIL De la: DIMENSIUNE = 523<<< 550-Verification failed for <<< 550-User unknown (200) <<< 550 Sender verify failed [#1005]. 554 5.0.0 Service unavailable

Adresa [email protected]- aceasta este adresa destinatarului scrisorii, este dată doar de dragul caracterului complet.
Adresa expeditorului [email protected] nu a trecut testul, ceea ce spune mesajul.

Expeditorul este verificat pentru fiecare scrisoare. Pentru a face acest lucru, serverul nostru încearcă să se conecteze la un server care acceptă e-mail pentru domeniul expeditorului (în exemplu, example.com) și trimite un e-mail de la adresa "<>„La adresa expeditorului (în exemplu [email protected]). Aceste e-mailuri ar trebui să fie întotdeauna acceptate, deoarece așa arată mesajele de livrare nereușită. Dacă serverul răspunde că o astfel de cutie poștală nu există (în exemplu, serverul care deservește domeniul example.com a răspuns „550-Utilizator necunoscut (200)”) sau din alte motive respinge încercarea, atunci scrisoarea de la adresa [email protected] inacceptabil.

Verificarea adresei de retur nu reprezintă protecție împotriva spam-ului (deși ajută la filtrarea unei părți a acesteia). Serverul trebuie să poată trimite un mesaj expeditorului în cazul în care acesta nu a putut să livreze scrisoarea destinatarului. Pentru a vă asigura că acest lucru este posibil, adresa de retur este verificată.
În acest caz, ați aflat despre problemă, deoarece serverul nostru nu a primit mesajul (semnalizare despre probleme de comunicare cu domeniul expeditorului), iar serverul expeditor a raportat expeditorului acest lucru. Dacă serverul nostru ar accepta mesajul fără a verifica posibilitatea livrării returului, nu ați ști despre problemă.

O scrisoare cu o adresă de retur incorectă este o problemă care trebuie rezolvată, dar în niciun caz prin oprirea mijloacelor care o semnalează.

#1004

Ne pare rău, nu acceptăm mesaje de la gazde fără o înregistrare PTR
Eroarea apare atunci când nodul expeditor nu are o înregistrare PTR.

#1007

Nu acceptăm adrese IP dinamice, vă rugăm să utilizați smtp-ul furnizorului dvs. [# 1007] sau ip dinamic respins [# 1007]
Această eroare apare pentru utilizatorii care utilizează un grup de adrese dinamice pentru conexiunea lor. Verificarea se efectuează pe baza adresei IP a utilizatorului (prezența cuvintelor dial, ppp, pool, dsl, dynamic, static și alte intrări în ea).

#1008

Verificarea expeditorului a eșuat
Antetul e-mailului de sesiune smtp de la conține o adresă de retur nevalidă (un domeniu inexistent, de exemplu).

#1009

Nu acceptăm adrese IP dinamice, vă rugăm să utilizați smtp-ul furnizorului dvs. [# 1009]
Această eroare apare în principal în rândul utilizatorilor care folosesc conexiuni DSL sau DialUp și trimit e-mail de pe computerele lor locale, cu alte cuvinte, nu folosesc serverul SMTP al ISP-ului lor. Verificarea se efectuează pe baza unei expresii regulate pentru:
^ ((1,3) \ D +) (2) ((1,3) [^ \ d \.] *). * \. (\ W | -) + \. \ W (2,4) $
Dacă dintr-un motiv oarecare nu puteți utiliza serverul SMTP al ISP-ului dvs. - scrieți o solicitare la asistența tehnică indicând adresa dvs. IP, aceasta va fi adăugată pe lista albă.

#1014

E-mail respins, vezi http://www.spamcop.net/w3m?action=checkblock&ip=IP-address [# 1014]
Folosim listele negre DNS spamcop.net pentru protecția împotriva spamului. Adresa expeditorului este pe lista neagră de spamcop.net

#1020

Releul nu este permis
S-a încercat să trimitem o scrisoare către un domeniu care nu este deservit de serverele noastre de e-mail.

#1024

Verificarea destinatarului a eșuat
Verificarea destinatarului scrisorii. Eroarea apare dacă domeniul este deservit de serverele noastre, dar o astfel de adresă nu există în domeniu.

#1025

Înștiințarea de verificare a destinatarului a eșuat
Verificarea destinatarului scrisorii. Apare o eroare dacă serverul la distanță răspunde că nu există un astfel de destinatar.

#1305

Trimiți prea multe mesaje
Limita pentru trimiterea de e-mailuri prin smtp a fost depășită. Pentru a crește limita, trebuie să contactați serviciul de asistență tehnică.

#2002

Autentificare necesara
Pentru a trimite, trebuie să treceți autentificarea prin autentificare și parolă.
Pot fi vizualizate exemple de configurare corectă a clienților de e-mail

Combaterea spam-ului este o durere de cap pentru toți administratorii responsabili de e-mail. Ce nu inventează ei pentru a face utilizatorilor lor iubiți o viață mai bună. Cu toate acestea, după cum a arătat practica de comunicare cu mulți administratori de sistem, din anumite motive nu toată lumea știe cum să filtreze corect spam-ul.

Cea mai comună abordare este „adăugați o grămadă de RBL (DNSBL) și bucurați-vă de viață”. Abordarea nu este corectă puțin mai mult decât complet. Al doilea cel mai popular sunt filtrele de conținut, adesea cumpărate pentru mulți bani. Această abordare este, de asemenea, complet nejustificată în majoritatea cazurilor.

Dar totul este atât de simplu, pentru o viață liniștită este suficient doar să te uiți îndeaproape la cele trei anteturi ale sesiunii SMTP primite. După ce am scotocit prin Habré și pe străzile din spate ale internetului, nu am găsit un articol exhaustiv despre setarea corectă a serverului SMTP în ceea ce privește combaterea spam-ului. Prin urmare, am decis să pictez eu însumi tot ce știu pe această temă și ce folosesc cu succes.

Apropo: acest articol se adresează, desigur, în primul rând administratorilor care doresc să creeze un filtru de spam de înaltă calitate. Cu toate acestea, pe de altă parte, conține informații foarte importante pentru cei care trebuie doar să lucreze cu poșta, dar care sunt slab versați în toate complexitățile procesului de redirecționare a e-mailului.

Deci, dacă doriți să vă protejați utilizatorii de spam, sau invers, dacă doriți ca cineva să nu protejeze accidental utilizatorii de e-mailurile dvs. - bine ați venit sub cat.

O mică notă: articolul a fost scris cu scopul de a configura un server de e-mail Postfix, dar în general este mai degrabă de natură teoretică. Opțiunile Postfix descrise trebuie specificate în documentul corespunzător * _restricție parametrii fișierului de configurare, consultați orice ghid de configurare Postfix pentru detalii.

Câteva despre protocolul SMTP

E-mailul are multe analogii cu poșta obișnuită. Cel mai important lucru pentru noi acum este că toate informațiile de pe „plicul” electronic sunt doar două adrese: destinatarul și expeditorul, precum și ștampila poștașului care a livrat plicul.

Să ne abatem puțin: imaginați-vă că o persoană cu aspect extrem de respingător vine la dvs. și vă predă un colet bine sigilat cu adresa de retur „Tryam din Tilimilitramdia”. Ai îndrăzni să accepți și să deschizi? Improbabil. Așadar, e-mailul poate fi, de asemenea, verificat și sortat cu ușurință pe baza informațiilor despre adresă, iar domeniul de aplicare a posibilelor acțiuni aici este mult mai larg.

După cum ar trebui să știți, corespondența de pe Internet este transferată între servere de e-mail folosind protocolul SMTP. Orice comunicare care utilizează acest protocol începe cu trei anteturi necesare: HELO, POSTA DE LAși RCPT TO... Adică, înainte de a începe să transmită orice date, serverul se prezintă mai întâi (HELO), apoi raportează adresa de retur a expeditorului (MAIL FROM) și apoi - adresa destinatarului (RCPT TO). Aceste trei anteturi sunt semnătura de pe plicul de e-mail și aproape tot spamul poate fi filtrat doar pe baza analizei lor. Majoritatea încercărilor de a trimite ceva către serverul meu nu merg mai departe de MAIL FROM, adică scrisorile sunt filtrate chiar înainte de a fi acceptate efectiv, ceea ce reduce semnificativ încărcarea. Adică, în loc să deschid pachetul de la Tryam și să găsesc acolo spori de antrax, îl trimit imediat pe poștaș în iad.

Deci, ce ar trebui să faceți pentru a nu accepta mesaje despre care se știe că sunt spam? Să mergem în ordine.

Un pic despre DNS

Pe vremuri, în zorii Internetului, corespondența era livrată direct la nodurile specificate în adresa poștală. Adică să livreze o scrisoare pt [email protected] serverul de e-mail a căutat adresa IP a domain.com și a încercat să trimită un pachet către IP-ul găsit. Apoi au apărut înregistrările MX, care au rezolvat imediat majoritatea problemelor unei astfel de organizații de interacțiune prin e-mail. Cu toate acestea, unele programe pot funcționa în continuare cu înregistrări A la livrarea corespondenței. Dar, desigur, aveți cel puțin o înregistrare MX pentru domeniul dvs., nu?

Înregistrările MX conțin adrese de server, pe care ar trebui să fie livrate scrisori pentru domeniul specificat. Cu toate acestea, pentru a combate spam-ul, a apărut o tehnologie care face posibilă indicarea adreselor serverelor în DNS, Cu care poate primi scrisori din domeniul specificat. Numele său este Sender Policy Framework.

Nu voi intra în detaliu în toate detaliile tehnologiei, voi spune doar acel record TXT

V = spf1 + mx -all

Scrieți întotdeauna o înregistrare SPF pentru domeniul dvs. și, de asemenea, activați verificarea SPF pe serverele dvs. de e-mail. Vă recomand să interziceți cu fermitate trimiterea de e-mailuri de pe domeniul dvs. de la toate gazdele, cu excepția serverelor dvs. MX. Împreună cu verificarea SPF pe serverul dvs., o astfel de setare va tăia imediat toate scrisorile trimise de la gazde terțe în numele utilizatorilor domeniului dvs. la adresele utilizatorilor propriului domeniu. Și există aproape jumătate din astfel de spam, deoarece, de obicei, serverele SMTP sunt foarte slab protejate de scrisorile din propriul domeniu, iar spammerii folosesc acest lucru în mod activ. SPF te va salva odată pentru totdeauna de scrisorile către Vasya Pupkin, scrise după plic de Vasya Pupkin, dar care provin de la un server din Nicaragua.

Google vă va spune cum să configurați SPF în Postfix, sunt multe informații și nu puteți greși, așa că să nu pierdem timpul cu detalii tehnice.

Mai sunt câteva note extrem de importante despre DNS. Cel mai probabil știți că înregistrările DNS de bază, așa-numitele înregistrări A, traduc un nume într-o adresă IP. Pe lângă acestea, există și înregistrări CNAME care atribuie un alias unui nume deja existent. Aceste două tipuri de înregistrări formează baza întregului sistem de nume de domeniu.

Dar puțini dintre utilizatori știu că există și înregistrări inverse care convertesc un IP într-un nume de domeniu. Se numesc PTR. Deci, există două reguli nescrise (strict vorbind) pe care toată lumea le urmează:

  • Pentru fiecare înregistrare A trebuie să existe oglindăÎnregistrare PTR, adică după numele gazdei prin DNS obținem IP, iar prin IP - înapoi același nume de gazdă.
  • Adresa din înregistrarea MX ar trebui să fie întotdeauna Nume(nu IP!) gazdă pentru care există o înregistrare A. Adică, nu puteți avea un IP sau o poreclă (CNAME) în înregistrarea MX.

Dacă nu respectați una dintre aceste cerințe, fiți pregătiți pentru faptul că cel puțin un sfert din e-mailurile din domeniul dvs. vor fi recunoscute ca spam. Acest lucru se datorează unei teze simple: un expeditor de încredere stabilește întotdeauna totul respectând regulile, respectiv, dacă regulile nu sunt respectate, atunci expeditorul nu trebuie să fie de încredere și, prin urmare, primește și e-mail de la el.

Ei bine, pentru a activa verificarea PTR pentru dvs., utilizați opțiunea

Reject_unknown_client_hostname

Necesită ca IP-ul de la care se face conexiunea să fie rezolvat într-un nume prin PTR, iar acest nume să fie rezolvat la rândul său înapoi la IP-ul dorit.

Există, de asemenea, o limitare mai puțin strictă stabilită de opțiune

Reject_unknown_reverse_client_hostname

În acest caz, serverul va verifica doar existența unei înregistrări PTR, dar nu va solicita existența unei înregistrări A corespunzătoare.

Verificarea salutului

Deci, cineva a vrut să trimită un e-mail serverului tău. Transmiterea începe cu un salut - antetul HELO. Numele de domeniu complet (FQDN) al expeditorului trebuie indicat în HELO, respectiv, dacă nu este cazul, puteți refuza în siguranță să îl acceptați imediat. Postfix are două opțiuni pentru aceasta:

Reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname

Primul interzice primirea de scrisori de la gazde care transmit salutări cu sintaxă incorectă, al doilea - de la gazde care transmit un non-FQDN într-o solicitare HELO.

Cu toate acestea, doar cei mai proști spammeri (și produsele MS, dar, după cum știți, nu le scriu legi) nu transmit FQDN-ul, până la urmă nu este greu să vă prezentați pe gmail.com. Prin urmare, trebuie să aruncăm o privire mai atentă la HELO. Pentru a face acest lucru, utilizați opțiunea

Reject_unknown_helo_hostname

Ceea ce interzice primirea scrisorilor de la servere care reprezintă o adresă pentru care nu există înregistrare A sau MX.

Expeditorul - ar trebui să ai încredere în el?

Deci, serverul s-a prezentat cu succes în fața dvs., următorul articol din program este adresa expeditorului. Din el pot fi extrase și o mulțime de informații utile. Vreau să observ imediat că adresa expeditorului nu trebuie să fie din același domeniu cu serverul însuși. Aceasta este o concepție greșită comună, așa că rețineți că nu este. Un server de e-mail poate servi cu ușurință mai multe domenii.

Cu toate acestea, dacă adresa expeditorului conține un domeniu care nu există deloc, atunci scrisoarea nu merită în mod clar acceptată. Și cu siguranță nu ar trebui să acceptați o scrisoare în care ceva este indicat ca adresă de retur, care nu este deloc o adresă. Există două opțiuni pentru refuzul de a accepta astfel de e-mailuri:

Reject_non_fqdn_sender
reject_unknown_sender_domain

Primul este de a verifica adresa pentru ortografie, al doilea este de a verifica existența domeniului.

Nu e rău deja, dar poți face mai mult. Puteți interoga serverul care deservește adresa de expeditor specificată pentru existența unui utilizator cu această adresă pe el. Într-adevăr, pare o idee bună să ne asigurăm că adresa de retur chiar există, altfel s-ar putea să primim o scrisoare de la o fantomă efemeră despre care nimeni nu a auzit vreodată.

Din punct de vedere tehnic, este foarte simplu de implementat: serverul nostru deschide o sesiune SMTP contor, încercând să trimită o scrisoare la adresa expeditorului. Dacă puteți trece cu succes de etapa trimiterii RCPT TO cu această adresă, adică. dacă serverul de primire nu declară brusc că cutia poștală specificată nu se află pe el, atunci se consideră că adresa de retur care ne-a fost trimisă există. Desigur, în timpul verificării nu se transmit date (adică o scrisoare), sesiunea este întreruptă după RCPT TO.

Opțiunea este responsabilă pentru această verificare a adresei de retur.

Reject_unverified_sender

Din cele de mai sus rezultă că pentru orice adresă de la care trimiți e-mail de pe domeniul tău, trebuie să existe o cutie poștală pe serverul tău. În caz contrar, scrisorile dumneavoastră nu vor trece de verificarea adresei de retur din partea destinatarului și, în consecință, nu vor fi livrate la destinație. Acest lucru este relevant pentru orice corespondență și alte tipuri de comunicare unidirecțională care nu necesită un răspuns. Creați întotdeauna cutii poștale pentru toate adresele de la care trimiteți e-mail. Dacă nu doriți să primiți răspunsuri la o anumită adresă, trimiteți-i pur și simplu scrisori în / dev / null, dar veți primi aceste scrisori. sunt obligați.

Destinatarul chiar exista?

Așa că am ajuns la ultimul antet al plicului - la destinatar. Totul este simplu aici: în primul rând, ar fi bine să verificăm dacă informațiile transmise către noi sunt în general o adresă de e-mail. Acest lucru se face prin directivă

Reject_non_fqdn_recipient

În plus, nu am dori să primim e-mail la adrese pentru care nu avem căsuțe poștale. Pentru a configura acest comportament, trebuie mai întâi să creați o listă de cutii poștale acceptate, apoi să spuneți Postfix despre aceasta printr-una dintre * _hărți_destinatarii parametrii fișierului de configurare, bine, atunci fie utilizați parametrul fișierului de configurare

Smtpd_reject_unlisted_recipient = da

Sau o opțiune de interzicere care are același efect:

Reject_unlisted_recipient

Postfix nu va mai accepta oricum e-mailuri pentru domeniile acceptate dacă nu există nicio căsuță poștală a destinatarului. Cu toate acestea, această restricție nu va afecta în niciun fel transmiterea corespondenței către adrese care nu se află în domeniile acceptate.

Și, în sfârșit, puteți interzice, în general, redirecționarea deschisă a scrisorilor prin Postfix, lăsând doar posibilitatea de a primi scrisori către adrese cunoscute. În aceste scopuri, se utilizează opțiunea

Reject_unauth_destination

Interzice trimiterea de e-mailuri către toți utilizatorii neînregistrați (da, va trebui să configurați autorizarea SMTP). Folosește întotdeauna această opțiune!În caz contrar, vei intra rapid în tot felul de DNSBL.

Ca subtotal

Acesta este modul în care puteți filtra o cantitate uriașă de spam numai pe baza analizei a trei anteturi de plic. Cu toate acestea, spammerii sunt vicleni, așa că acest lucru încă nu este suficient.

Listare gri

Uneori, serverele de e-mail sunt supraîncărcate și nu pot primi o scrisoare. Crezi că răspund solicitărilor primite în acest caz? Destul de ciudat, ei răspund - server temporar indisponibil, vă rugăm să încercați mai târziu. Niciun expeditor normal nu va considera vreodată în acest caz că scrisoarea nu poate fi livrată cu toate consecințele care decurg. Dimpotrivă, expeditorul va încerca să livreze ulterior scrisoarea, punând-o pe rând pentru trimitere. Acest fapt poate (și fără îndoială ar trebui să fie!) Folosit foarte eficient: la fiecare primă încercare de conectare de la o gazdă necunoscută, serverul nostru va trimite un mesaj despre o eroare temporară și va sări peste scrisoarea abia a doua oară. Acest lucru va filtra aproape tot spam-ul rămas simultan, deoarece serverele de spam aproape niciodată nu fac mai mult de o încercare de a livra un mesaj (altfel pur și simplu s-ar „crasa” dintr-o coadă depășită). Această tehnologie se numește Greylisting și este pur și simplu necesar să o folosești în realitățile moderne.

Dezavantajul acestei aplicații este o întârziere mică (de obicei nu mai mult de jumătate de oră) în livrarea scrisorilor la primul conexiune de la o gazdă necunoscută. Adică, dacă un server care nu este încă cunoscut postfixului nostru dorește să trimită o scrisoare, atunci la prima încercare de conectare, i se trimite o eroare despre indisponibilitatea temporară. Dacă serverul a încercat să se conecteze din nou, atunci scrisoarea este acceptată, iar serverul este introdus în noduri de încredere și alte scrisori de la acesta sunt acceptate fără întârziere.

De asemenea, vă sugerez să citiți despre configurarea listei gri în Postfix în Google, este ușor și nu puteți greși.

Blocklists, sau cum să nu o faci

Unii administratori de e-mail se bazează pe așa-numitele DNSBL (RBL) pentru a filtra spam-ul, care sunt liste negre de site-uri văzute trimițând spam. Asa de, nu nu adăuga fără verificări DNSBL către serverele dvs. de e-mail. Există două motive pentru aceasta: primul, și cel mai elementar, este acoperit în a doua parte a primei propoziții a acestei secțiuni. Nodurile sunt introduse în aceste liste complet aleatoriu și nu există nicio garanție că o gazdă normală nu va ajunge acolo (pe care, poate, la un moment dat s-a instalat un virus care trimite spam, dar acum virusul a fost deja vindecat sau, mai simplu și mult mai realist, un IP extern pentru o rețea mare în care a ajuns spammer-ul). Al doilea motiv este mai banal: mecanismul de filtrare propus mai sus este mult mai eficient decât orice DNSBL și nu se bazează pe date neverificate de la terți.

Cu susul în jos, sau priviți din cealaltă parte a baricadelor

Am învățat cum să filtram spam-ul, acum voi încerca să adun toate informațiile pe tema ce trebuie făcut pentru nu intra in spam.

Pentru administratorii de servere de mail:

  • Faceți întotdeauna ca înregistrările MX să se refere la înregistrările A.
  • Înregistrarea A pentru serverul de e-mail trebuie să aibă întotdeauna o înregistrare PTR în oglindă.
  • Gazda din antetul HELO trebuie să aibă o înregistrare A sau MX.
  • Creați întotdeauna înregistrări SPF (da, acest lucru nu este necesar, ci doar o regulă de bună formă).
  • Pentru toate e-mailurile trimise dintr-un domeniu acceptat, trebuie să existe o casetă cu adresă de retur și să primească e-mail.
Pentru cei care trimit mail (din programe, de pe site-uri etc.):
  • Trimiteți întotdeauna e-mail numai cu o adresă de retur existentă.
  • Nu trimiteți niciodată e-mailuri dintr-un domeniu pe care nu îl controlați fără a verifica regulile SPF pentru acesta. De exemplu, gmail.com vă permite în prezent să trimiteți scrisori în numele său către orice server, dar yandex.ru și mail.ru informează prin SPF că trimiterea în numele lor de pe servere terțe ar trebui să atragă atenția, ceea ce este interpretat de smart. filtrele de spam ca o creștere a ratingului de spam pentru un anumit e-mail.
  • Nu trimiteți niciodată e-mailuri prin servere SMTP configurate greșit. Verificarea serverului pentru păduchi conform listei de mai sus este o chestiune de 5 minute, utilitarul vă va ajuta săpa sau nslookup.

rezumat

Desigur, setările sugerate nu filtrează tot spamul. Prin urmare, este foarte posibil să fie necesar să utilizați suplimentar un filtru de context care va analiza conținutul literelor, de exemplu,

Când sunteți plecat de acasă și trimiteți un mesaj de e-mail folosind contul de e-mail de acasă, e-mailul poate reveni cu erori 550, 553 sau erori de retransmitere. Același lucru se poate întâmpla atunci când sunteți în afara biroului încercând să trimiteți un mesaj de e-mail folosind contul de e-mail de la serviciu.

Descriere

Retransmiterea are loc atunci când un mesaj de e-mail este trimis la o adresă de e-mail al cărei domeniu (nume după simbolul @, cum ar fi adatum.com) nu este procesat de SMTP sau de către serverul de e-mail de ieșire care primește o cerere de livrare a mesajului de la expeditor. Serverul SMTP trebuie să se conecteze la un alt server SMTP pentru a transmite mesajul.

Dacă apare o eroare de retransmitere în timpul trimiterii unui mesaj de e-mail, serverul SMTP (e-mail de ieșire) poate returna mesajul împreună cu un mesaj de eroare ca acesta:

    Subiect:<тест>, Cont:<тест>, Server: , protocol: SMTP, răspuns server: „550 Releu interzis ", port: 25, securitate (SSL): nu, eroare server: 550, număr eroare: 0x800CCC79".

    „Mesajul nu a putut fi trimis deoarece serverul a refuzat să accepte adresa unuia dintre destinatari. Mesajul conținea adresa:<адрес эл. почты>... Subiect:<тест>, Cont:<тест>, Server: , protocol: SMTP, răspuns server: „553, din păcate, acest domeniu nu este în lista mea de gazde permise (# 5.7.1)”, port: 25, securitate (SSL): nu, eroare server: 553, număr eroare: 0x800CCC79 „ ...

Textul exact al mesajului de eroare va depinde de ISP-ul dumneavoastră. Unii furnizori nu returnează un mesaj de eroare atunci când identifică mesajele de ieșire ca reclame nedorite. În aceste cazuri, totul pare că mesajul dvs. este trimis normal (în Outlook, acesta rămâne în Căsuță de ieșireși apare în folder Trimis), dar nu este livrat destinatarului.

Mesajul dvs. a fost respins deoarece serverul SMTP (de ieșire) nu v-a recunoscut ca utilizator autorizat.

SMTP este un protocol (standardele pe care computerele le folosesc pentru a comunica) care este folosit de majoritatea serverelor de e-mail pentru a trimite mesaje pe Internet. Dacă utilizați un program de e-mail (cum ar fi Outlook) care vă permite să stocați mesaje pe computer, aveți nevoie de acces la un server SMTP pentru a trimite mesaje.

Notă: Sistemele de e-mail bazate pe web (cum ar fi Windows Live Mail sau Yahoo! Mail) funcționează diferit și nu sunt tratate în acest articol.

Mesaje nedorite și relee deschise

Mesajele publicitare care sunt distribuite fără solicitări se numesc mesaje nedorite sau spam. Volumul de spam continuă să crească pentru că nu costă aproape nimic să-l trimiți celor care îl trimit. De fapt, expeditorul nici măcar nu trebuie să trimită spam prin serverul SMTP (outbound) al ISP-ului său.

În crearea structurii de bază a Internetului, nimeni nu a prevăzut implicațiile de a putea trimite milioane de mesaje nesolicitate pentru costuri neglijabile. Datorită capacității de retransmitere a serverelor SMTP, expeditorii de spam maschează originea spam-ului trecându-l prin servere terțe care permit o astfel de retransmitere deschisă. Drept urmare, spam-ul pare să provină de la un site care transmite mesajul și ascunde identitatea expeditorului real.

Până de curând, majoritatea serverelor de e-mail SMTP operau pe un sistem deschis de încredere. Într-un astfel de sistem, oricine de oriunde poate trimite un mesaj de e-mail către un server SMTP, iar serverul trebuie să-l accepte și să-l redirecționeze către destinatar sau către alt server de e-mail unde se află căsuța poștală a destinatarului. Cu acest releu deschis, nu există restricții care să împiedice pe cineva să trimită e-mail prin serverul SMTP.

Restricții de la furnizorul de servicii de internet privind retransmiterea corespondenței

Pe măsură ce volumul de spam a crescut, administratorii de rețea (persoanele însărcinate cu gestionarea serverelor unui ISP) au început să impună restricții asupra serverelor lor de e-mail SMTP. Aceste restricții împiedică toată lumea să folosească serverul de e-mail. Imaginați-vă că în holul organizației dumneavoastră există un telefon care este accesibil tuturor, inclusiv celor care nu fac parte din organizație. Acum doar angajații au voie să folosească telefonul.

Mai multe tipuri de constrângeri sunt utilizate astăzi.

    Necesită autentificare SMTP. Așa cum utilizați un nume de utilizator și o parolă pentru a accesa serverul POP3 (e-mail-uri primite) și e-mailurile dvs., trebuie să introduceți un nume de utilizator și o parolă pentru a trimite e-mailuri prin serverul SMTP. Acesta este de obicei același nume de utilizator și parolă ca și pentru serverul POP3, dar poate fi unic.

    Mai întâi trebuie să vă conectați la serverul POP3 (e-mail primite) al furnizorului dvs. de servicii de internet. Pentru a primi noile mesaje de e-mail, de obicei vă conectați la un server POP3 (e-mail de intrare). Pentru a vă accesa căsuța poștală, trebuie să introduceți numele de utilizator și parola. Administratorul dvs. de rețea poate configura serverul astfel încât, dacă vă conectați mai întâi la un server POP3 de intrare și vă autentificați, acesta va aproba toate solicitările de trimitere a e-mailurilor prin serverul SMTP de ieșire, care altfel ar fi restricționat.

    Necesită o conexiune de la o locație de rețea autorizată. Dacă vă conectați de acasă la un furnizor de servicii de internet folosind o linie telefonică, cablu sau modem DSL, conexiunea se duce direct la rețeaua furnizorului. Sunteți de încredere deoarece aveți un cont cu un nume de utilizator și o parolă furnizate de furnizorul dvs. de servicii de internet. În calitate de client, aveți voie să utilizați un server SMTP pentru a trimite e-mail.

    Necesită o conexiune de la o anumită adresă IP sau un interval de adrese IP. ISP-ul dvs. poate permite persoanelor care nu sunt conectate direct la rețea să acceseze serverul SMTP. De exemplu, ar putea fi un utilizator de la distanță din birou. Problema principală este că adresele IP dinamice sunt folosite în multe locuri. Cu toate acestea, nu puteți fi sigur că aveți aceeași adresă IP de fiecare dată când vă conectați. Unele organizații pot avea un bloc sau o serie de adrese IP rezervate. ISP-ul poate considera pe cei care se conectează de la aceste adrese IP ca fiind verificați de utilizatori. El poate oferi informații suplimentare.

Există o mulțime de scenarii de retransmitere posibile. Mai jos sunt cele mai frecvente situații. Poate că unul dintre ele este asemănător cu al tău.

Situatie

Acesta este un releu?

Sunteți acasă și aveți un cont de furnizor de servicii de internet care se termină în @ proseware.com la care vă conectați printr-o linie telefonică, cablu sau modem DSL. Trimiți un mesaj unei alte persoane a cărei adresă de e-mail se termină și în @ proseware.com.

La fel ca în prima situație, doar tu trimiți un mesaj unei persoane a cărei adresă de corespondență se termină cu @adatum.com.

Da, dar nu este blocat. Vă conectați direct la furnizorul de servicii de internet și obțineți astfel autoritatea de a trimite e-mail prin serverul său SMTP (e-mail de ieșire) la orice adresă, indiferent de locația căsuței poștale a destinatarului.

Esti la serviciu. Adresa dvs. poștală de serviciu se termină în @thephone-company.com și aveți un cont de acasă ISP care se termină în @proseware.com și la care vă conectați printr-o linie telefonică, cablu sau modem DSL... În Outlook, aveți aceleași setări de server SMTP configurate ca și acasă. Trimiți un mesaj unei persoane a cărei adresă de e-mail se termină și în @ proseware.com.

Nu. Poșta ta este procesată în mod obișnuit.

Sunteți cazat la un hotel sau utilizați un terminal de internet din aeroport care oferă acces la internet. Aveți un cont de acasă de furnizor de servicii de internet (ISP) care se termină în @ proseware.com la care vă conectați prin dial-up, cablu sau modem DSL. În Outlook, aveți aceleași setări de server SMTP configurate ca și acasă. Trimiți un mesaj unei alte persoane a cărei adresă de e-mail se termină și în @ proseware.com.

Nu. Poșta ta este procesată în mod obișnuit.

La fel ca în situația anterioară, doar tu trimiți un mesaj unei persoane a cărei adresă de corespondență se termină în @adatum.com.

Da, iar acest mesaj poate fi blocat ca e-mail retransmis. Încercați să utilizați serverul de acasă SMTP (e-mail de ieșire) al ISP-ului dvs., deși nu sunteți conectat la rețeaua lor. Serverul SMTP nu vă poate autentifica ca abonat autorizat la un ISP. În plus, îi cereți serverului SMTP să accepte mesajul și să se conecteze la un alt server SMTP pentru a-l livra în căsuța poștală a destinatarului.

Soluții

Dacă situația dvs. este considerată retransmisă, trebuie să trimiteți un mesaj prin serverul la care vă conectați în prezent. Adică, dacă sunteți la serviciu sau departe de casă și nu vă folosiți ISP-ul pentru a vă conecta la Internet, dar doriți să trimiteți un mesaj din contul dvs. de acasă furnizat de furnizorul respectiv, trebuie să modificați setările contului de e-mail pentru a specifica faptul că Serverul SMTP pe care îl utilizați acolo unde vă aflați (de exemplu, un server SMTP funcțional). Pentru instrucțiuni pas cu pas, consultați articolul.

Dacă acest lucru nu funcționează sau dacă preferați să utilizați un cont de acasă, trebuie să vă contactați ISP-ul și să întrebați dacă opțiunile descrise mai devreme sunt disponibile pentru dvs. În ceea ce privește primele două restricții (necesită autentificare SMTP și necesită mai întâi conectarea la serverul de e-mail de intrare POP3 al ISP-ului), puteți face modificări la Setările contuluiîn Outlook. Pentru instrucțiuni, consultați Modificarea setărilor contului de e-mail.

Încă nu trimiți mesaje?

Ați modificat setările SMTP în Outlook sau ați găsit o opțiune care vă va permite să trimiteți mesaje e-mail. Dar tot nu puteți trimite e-mail și primi un mesaj de eroare.

Este posibil să fi făcut totul corect, dar administratorii de rețea folosesc o altă funcție de securitate pentru a preveni falsificarea identității. Falsificarea identității este pur și simplu o modalitate de a trimite mesaje e-mail în care ascundeți cine sunteți.

În Outlook, ca și în cazul majorității programelor de e-mail, puteți furniza un „nume afișat” și adresa poștală de retur care apare atunci când răspundeți la mesaj. În spam, aceste câmpuri conțin aproape întotdeauna informații false. Chiar crezi că mesajele despre îmbogățirea rapidă au venit de la un supermodel sau un lider mondial?

Pentru a preveni falsificarea identității, unii ISP restricționează capacitatea de a introduce informații false în câmpul de adresă în răspunsuri. De exemplu, dacă numele de domeniu al ISP-ului dvs. se termină în proseware.com, este posibil ca ISP-ul să nu vă permită să furnizați o adresă de retur. [email protected]... Această limitare nu este utilizată la fel de larg ca descris anterior, dar poate fi aplicată tuturor utilizatorilor, indiferent de locația lor sau metoda de conectare. În acest caz, nu există alternativă. Dacă administratorul serverului folosește această metodă, trebuie să specificați domeniul corespunzător conexiunii dvs. curente în adresa de retur.

Top articole similare