Kako podesiti pametne telefone i računare. Informativni portal
  • Dom
  • Recenzije
  • Podešavanje e-pošte (bez neželjene pošte). Gubitak mail poruka

Podešavanje e-pošte (bez neželjene pošte). Gubitak mail poruka

Podešavanje slanja e-pošte bez njihovog ubacivanja u neželjenu poštu.

Neću razmatrati opciju slanja pisama preko SMTP servera trećih strana (Mandrill, Mailgun, Yandex) i putem ličnih adresa poštanskih servisa (tamo je sve vrlo jednostavno ako slijedite upute za instalaciju) - uzeću u obzir samo opcija da imamo svoj server, na kojem je instaliran odgovarajući mail server, na primjer Exim (kao i većina hostera).

Potreban nam je pristup za uređivanje DNS zapisa i minimalno vlasništvo konzole da konfigurišemo DKIM (ako je ISPmanager dostupan, ova stavka postaje nevažna). Ukupno, potrebno je da konfigurišete (dodate) 4 nova zapisa u DNS zapisima vaše domene: PTR, SPF, DKIM i DMARC.

  • PTR- takozvani "obrnuti" DNS zapis. Trebao bi biti obavezan, jer je vrlo veliki broj poštanskih servisa nepodnošljiv za njegovu netačnu indikaciju. U teoriji, trebao bi ga instalirati vaš hosting provajder, na primjer DigitalOcean to radi automatski. - ali postoji opcija za njegovo ručno podešavanje.
  • SPF- zapis koji pokazuje da je vašem serveru dozvoljeno slanje pisama sa ovog domena i IP-a. Ako ovaj unos izostane, ulazak u neželjenu poštu je gotovo zagarantovan. Instalacija je vrlo jednostavna - možete dobiti sveobuhvatne informacije sa primjerima za postavljanje na (informacije na zelenoj ploči), ili na.
  • DKIM- elektronski potpis vaših pisama. Ako imate dva prethodna zapisa, on vašoj domeni i slovima sa njega daje "težinu", zahvaljujući kojoj isti Yandex, na primjer, označava slova lijepom zelenom kvačicom.

Podešavanje ovog potpisa je možda najteže - kao rezultat toga, 90% sajtova ga nema, ali se toplo preporučuje. Vrlo je lako podesiti ga u ISPmanager-u: uključite DKIM podršku na kartici sa funkcijama, kada uređujete mail domen, označite DKIM polje i pokupite gotov zapis u svojstvima domena (NS). Ako ISPmanager nije dostupan, savjetujem vam da koristite ovaj prilično jednostavan članak:.

  • DMARC- standard je potpuno nov, ali ga poštanske službe već aktivno uvode, a ove godine ga već 100% mora imati. Podešavanje je najjednostavnije od svih gore navedenih unosa, samo trebate dodati jedan od primjera prikazanih na ovoj stranici ispod: - Preporučujem drugi.
Vaš server je sada konfigurisan i ako je sve urađeno kako treba, ni jedno slovo neće otići u neželjenu poštu. Na primjer, potvrda snimka ekrana iz pošte mail.ru (slična situacija s potpunim odsustvom definicije pisama kao neželjene pošte i za Yandex):

Konfiguriranje sakupljača povratne pošte.

XenForo ima apsolutno neverovatan mehanizam koji skoro niko ne koristi - sakupljač e-pošte. Mislim da su se svi susreli sa situacijom da nakon masovnog slanja u poštansko sanduče dolazi veliki broj pisama sljedećeg tipa:

Ovu poruku je automatski kreirao softver za dostavu pošte.

Poruka koju ste poslali nije mogla biti isporučena na jedan ili više njih
primaocima. Ovo je trajna greška. Sljedeća adresa (e) nije uspjela:

***@rambler.ru
SMTP greška sa udaljenog servera pošte nakon RCPT DO:<***@rambler.ru>:
host imx1.rambler.ru: 540 5.7.1<***@rambler.ru>:
Adresa primaoca je odbijena: Vaša e-pošta je vraćena jer je nalog e-pošte ciljanog primaoca suspendovan. Nalog se mora ponovo aktivirati da bi primao dolazne poruke.

Ova pisma su signal da su vaši korisnici zastarjeli svoje e-mail adrese (poštanski sandučići su blokirani, izbrisani, prepuni), što znači da neće primati nova pisma od vas, a ako je potrebno, neće moći ni vratiti svoj račun na forumu . Mnogi korisnici ni ne znaju da koriste zastarjelu e-mail adresu, a mail servisi, kada vide veliki broj e-mailova poslatih na nepostojeće adrese, mogu otrcano staviti vašu domenu na spam listu.

Moramo se boriti protiv toga, jer čak i na mom forumu, gdje ovaj sistem radi više od prve mailing liste, ima dosta „vraćenih“ pisama, u poređenju sa brojem korisnika:

  • Za početak kreiramo poštansku adresu na koju ćemo slati vraćena pisma (sistemsko poštansko sanduče ne bi trebalo koristiti u druge svrhe) - npr. gdje je google.com vaša domena.
  • Idite na odjeljak administratora Postavke - Postavke e-pošte... U polju adresa za vraćanje pisama navedite poštansko sanduče koje ste kreirali. Stavljamo kvačicu na automatsku obradu neisporučenih pisama i označavamo podatke za unos Vašeg servisnog sandučeta koje ste prethodno kreirali: adresu (u slučaju vašeg SMTP servera navedite svoju), login (adresu koju ste kreirali) i lozinku za poštansko sanduče. Navest ću primjer svojih postavki - imam poslovnu poštu od Mail.ru - stoga se povezujem na njihov server da primam poštu iz servisne kutije

U suštini, to je cijela postavka. Forum će se automatski u određenim intervalima prijavljivati ​​u servisno sanduče koje ste naveli, preuzimati kopije vraćenih pisama koje je primio i odatle ih brisati. U poglavlju Alati - Dnevnik odbijanja isporuke pošte možete pogledati ove statistike. Naglašavam da se ovaj poštanski sandučić ne može koristiti u druge svrhe, inače rizikujete da dobijete nekoliko prilično zabavnih grešaka u logovima admin panela.

U skladu sa uslovima koje ste postavili, kada se na primer vrate 3 pisma sa jedne adrese, korisnik će biti poslat na automatsku reaktivaciju - od njega će se tražiti da unese ispravnu email adresu i ponovo aktivira nalog. Vaše učešće ni na koji način nije potrebno - korisnici će sami naznačiti svoje stvarne e-mail adrese, pa će problem s vremenom nestati. A kod slanja e-pošte, korisnici s pogrešnom e-mail adresom mogu biti isključeni iz nje - čime se izbjegava mogućnost pada na spam liste.

Napisano je dosta teksta, ali u stvari, podešavanje svega - i servera i sakupljača pošte traje nekoliko minuta, ako tačno pratite uputstva. Podesite ga jednom i zaboravite da poruke sa vašeg foruma nisu stigle negde ili da je vaš domen uvršten na spam liste zbog nebitnosti baze podataka.

Da biste pojednostavili neke od gore opisanih zadataka, možete koristiti bilo koji - šta god želite. Koristim prvi - ali izbor je potpuno na vama. Dodavanje vaših domena tamo će dati zgodne poštanske sandučiće neograničene veličine sa već ugrađenim filterima za neželjenu poštu + određeno pojednostavljenje konfiguracije servera (neki zapisi će biti obezbeđeni automatski (osim DKIM-a, koji se na ovaj ili onaj način mora generisati ručno za slanje pošte sa vašeg servera)).

Primjeri slova:

550 5.7.1 Ova poruka nije prihvaćena zbog DMARC politike vlasnika domene (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc

550-5.7.1 Neautorizirana e-pošta s mail.ru nije prihvaćena zbog domene 550-5.7.1 DMARC politike. Molimo kontaktirajte administratora mail.ru domene ako je ovaj 550-5.7.1 bio legitiman mail. Molimo posjetite 550 -5.7.1 https://support.google.com/mail/answer/2451690 da saznate više o DMARC-u

550 5.7.1 E-pošta odbijena prema DMARC politici za ...

Problem isporuke poruke vezan za novu politiku koja se primjenjuje DMARC vezano za pooštravanje pravila za prolazak spam filtera.

DMARC Je protokol za zaštitu od neželjene pošte i od neovlaštene distribucije pošte u ime domene, zasnovan na postojećim mehanizmima DKIM i SPF... Zvanična stranica: dmarc.org.

Ako primate poruke slične gore navedenim, najvjerovatnije se pošta sa vaše stranice šalje u ime poštanskog sandučeta na osnovu @ mail.ru, @ bk.ru, @ list.ru ili @ inbox.ru... Mail.Ru ne prihvata poruke poslate putem phpmail-a ako zaglavlje pošte sadrži poštansko sanduče koje pripada mail.ru. Takve poruke, prema politici koju provodi Mail.Ru DMARC su odbijeni.

Kako riješiti problem

Postoje dva načina za rješavanje problema:

Metoda 1: promijenite poštansko sanduče iz kojeg se šalju poruke

Obično se e-mail u ime kojeg se šalju poruke registruje u administrativnom dijelu CMS-a. Također se može promijeniti direktno u skripti za slanje poruka (polje "Od").

Neophodno je da se poruke šalju iz poštanskog sandučeta na osnovu imena vašeg domena, na primjer « [email protected]» , gdje je domain.ru vaša domena. ...

Takođe, potrebno je promijeniti poštansko sanduče u datoteci php.ini:

Promjena poštanskog sandučeta u php.ini

  1. 1 uđite u kontrolnu tablu hostinga i otvorite datoteku php.ini za uređivanje:;
  2. 2

    pronađi liniju poput:

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

    U ovom redu, umjesto « [email protected]» navedite poštanski sandučić koji nije povezan s domenama @ mail.ru, @ bk.ru, @ list.ru i @ inbox.ru.
    Preporučljivo je odrediti poštanski sandučić na svojoj domeni, npr. « [email protected]» , gdje je domain.ru vaša domena.

    Osim toga, poštansko sanduče registrovano u php.ini mora postojati. Ako koristite poštu na hostingu, kreirajte poštansko sanduče na domeni i upišite ga u datoteku php.ini.

Metoda 2: koristite SMTP autentifikaciju

Možete slati poruke u ime svog poštanskog sandučeta na osnovu Mail.Ru postavljanjem SMTP autorizacije. U tom slučaju, sve poruke preko vaše stranice bit će poslane direktno sa Mail.Ru servera.

Greške sistema pošte su kodovi koji se dodeljuju porukama tokom prijema ili odbijanja prijema. Šifra greške vam omogućava da saznate razlog zašto poruka ne može biti isporučena. Tipično, kod greške je broj, kao što je # 550 ili # 2001. Šifre grešaka su opisane u nastavku.

Poruke bez kodova

Neusmjerljiva adresa

Nije moguće odrediti server na koji želite proslijediti poruku pošte. Mogući razlozi:

  • Domena na koju se šalje pošta ne postoji ili nije delegirana
  • Ni MX ni A zapisi nisu registrovani za domen
  • MX zapis ukazuje na nepostojeće ime

Korisnik nepoznat

Dato poštansko sanduče ne postoji ili je poštanska adresa navedena sa greškom

Prijenos u toku. Ostanite sa nama

Poruka se pojavljuje kada klijent e-pošte šalje pisma. Ova poruka nije sa našeg mail sistema. To znači da korisnik na lokalnoj mreži ima antispam ili firewall koji provjerava sve odlazne poruke.

preko kvote

LMTP greška nakon završetka podataka: 552 5.2.2 Prekoračenje kvote
Greška se javlja ako je poštansko sanduče primaoca puno.

Poruke sa kodovima

#1005

Oblačić za potvrdu pošiljaoca nije uspio
Provjeravamo pošiljaoca pisma. Greška može biti ili potpuna, kao što je dolje naznačeno, ili skraćeno: "Provjera pošiljatelja nije uspjela [# 1005]". Grešku šalje neki server koji je bezuspješno pokušao poslati email na naš server. Naš server je naveden u redu "... dok razgovaram sa mx3.site .:".

Sljedeće adrese su imale trajne fatalne greške ----- (razlog: 550-Verifikacija nije uspjela za ) ----- Slijedi transkript sesije ----- ...u razgovoru sa mx3 Site .: >>> MAIL Od: VELIČINA = 523<<< 550-Verification failed for <<< 550-User unknown (200) <<< 550 Sender verify failed [#1005]. 554 5.0.0 Service unavailable

Adresa [email protected]- ovo je adresa primaoca pisma, data je samo radi kompletnosti.
Adresa pošiljaoca [email protected] nije prošao test, što piše u poruci.

Pošiljalac se provjerava za svako pismo. Da bi to uradio, naš server pokušava da se poveže sa serverom koji prihvata poštu za domen pošiljaoca (u primeru, example.com) i pošalje e-poštu sa adrese "<>„Na adresu pošiljaoca (u primjeru [email protected]). Ove e-poruke uvijek treba prihvatiti jer ovako izgledaju poruke neuspjele isporuke. Ako server odgovori da takvo poštansko sanduče ne postoji (u primjeru, server koji opslužuje example.com domenu je odgovorio "550-User unknown (200)") ili iz drugih razloga odbije pokušaj, tada će pismo sa adrese [email protected] nije prihvatljivo.

Provjera povratne adrese nije zaštita od neželjene pošte (iako pomaže u filtriranju njenog dijela). Server mora biti u mogućnosti da pošalje poruku pošiljaocu u slučaju da nije bio u mogućnosti da isporuči pismo primaocu. Kako bismo osigurali da je to moguće, povratna adresa se provjerava.
U ovom slučaju, saznali ste za problem, jer naš server nije primio poruku (signalizirajući o problemima u komunikaciji sa domenom pošiljaoca), a server koji šalje to je prijavio pošiljaocu. Da je naš server prihvatio poruku bez provjere mogućnosti povratne isporuke, ne biste znali za problem.

Pismo sa pogrešnom povratnom adresom je problem koji se mora riješiti, ali ni u kojem slučaju isključivanjem sredstva koje ga signalizira.

#1004

Nažalost, ne prihvatamo poruke od domaćina bez PTR zapisa
Greška se javlja kada pošiljateljski čvor nema PTR zapis.

#1007

Ne prihvatamo dinamičke ip adrese, molimo koristite smtp vašeg provajdera [# 1007] ili dinamički IP odbijen [# 1007]
Ova greška se javlja za korisnike koji koriste dinamičko spremište adresa za svoju vezu. Provjera se vrši na osnovu IP adrese korisnika (prisustvo riječi dial, ppp, pool, dsl, dynamic, static i drugih unosa u njoj).

#1008

Provjera pošiljatelja nije uspjela
Zaglavlje e-pošte smtp sesije sadrži nevažeću povratnu adresu (na primjer, nepostojeći domen).

#1009

Ne prihvatamo dinamičke ip adrese, molimo koristite smtp vašeg provajdera [# 1009]
Ova greška se uglavnom javlja među korisnicima koji koriste DSL ili DialUp veze i šalju poštu sa svojih lokalnih računara, drugim riječima, ne koriste SMTP server svog ISP-a. Provjera se vrši na osnovu regularnog izraza za:
^ ((1,3) \ D +) (2) ((1,3) [^ \ d \.] *). * \. (\ W | -) + \. \ W (2,4) $
Ako iz nekog razloga ne možete koristiti SMTP server vašeg ISP-a - napišite zahtjev tehničkoj podršci navodeći vašu IP adresu, ona će biti dodana na bijelu listu.

#1014

Mail odbijen, pogledajte http://www.spamcop.net/w3m?action=checkblock&ip=IP-address [# 1014]
Koristimo spamcop.net DNS crne liste za zaštitu od neželjene pošte. Adresa pošiljaoca je na crnoj listi spamcop.net

#1020

Relej nije dozvoljen
Učinjen je pokušaj slanja pisma na domenu koju ne opslužuju naši mail serveri.

#1024

Provjera primatelja nije uspjela
Provjeravamo primaoca pisma. Greška se javlja ako domenu opslužuju naši serveri, ali takva adresa ne postoji u domeni.

#1025

Oblačić za potvrdu primaoca nije uspio
Provjeravamo primaoca pisma. Greška se javlja ako udaljeni server odgovori da takav primalac ne postoji.

#1305

Šaljete previše poruka
Prekoračeno je ograničenje slanja e-pošte putem smtp-a. Da biste povećali ograničenje, morate kontaktirati službu tehničke podrške.

#2002

Potrebna je autentifikacija
Za slanje, potrebno je proći autentifikaciju putem prijave i lozinke.
Možete pogledati primjere ispravne konfiguracije mail klijenata

Borba protiv neželjene pošte je glavobolja za sve odgovorne administratore pošte. Šta samo ne izmišljaju da svojim voljenim korisnicima učine boljim životom. Međutim, kako je praksa komunikacije s mnogim sistemskim administratorima pokazala, iz nekog razloga ne znaju svi kako pravilno filtrirati neželjenu poštu.

Najčešći pristup je "dodajte gomilu RBL-a (DNSBL) i uživajte u životu." Pristup nije ispravan malo više nego potpuno. Drugi najpopularniji su filteri sadržaja, koji se često kupuju za mnogo novca. I ovaj pristup je u većini slučajeva potpuno neopravdan.

Ali sve je tako jednostavno, za miran život dovoljno je samo pažljivo pogledati tri zaglavlja nadolazeće SMTP sesije. Preturajući po Habré-u i zabačenim internetskim ulicama, nisam našao iscrpan članak o ispravnom podešavanju SMTP servera u smislu suzbijanja neželjene pošte. Stoga sam odlučio da sve što znam na ovu temu i sam oslikam i što uspješno koristim.

Usput: ovaj članak je naravno prvenstveno namijenjen administratorima koji žele napraviti visokokvalitetan filter za neželjenu poštu. Međutim, s druge strane, sadrži vrlo važne informacije za one koji samo moraju raditi s poštom, a koji su slabo upućeni u sve zamršenosti procesa prosljeđivanja elektroničke pošte.

Dakle, ako želite da zaštitite svoje korisnike od neželjene pošte, ili obrnuto, ako želite da neko slučajno ne zaštiti korisnike od vaših emailova - dobrodošli pod kat.

Mala napomena: članak je napisan s ciljem postavljanja mail servera Postfix, ali u cjelini je prilično teorijske prirode. Opisane Postfix opcije moraju biti specificirane u odgovarajućim * _restriction parametre konfiguracijske datoteke, pogledajte bilo koji vodič za konfiguraciju Postfixa za detalje.

Malo o SMTP protokolu

E-pošta ima mnogo analogija sa običnom poštom. Sada nam je najvažnije da su svi podaci na elektronskoj „koverti“ samo dve adrese: primaoca i pošiljaoca, kao i pečat poštara koji je kovertu uručio.

Da malo odstupimo: zamislite da vam dođe osoba izuzetno odbojnog izgleda i preda dobro zapečaćeni paket sa povratnom adresom "Tryam from Tilimilitramdia". Da li biste se usudili prihvatiti i otvoriti? Malo vjerovatno. Dakle, e-mail se takođe može lako provjeriti i procijediti samo na osnovu podataka o adresi, a opseg mogućih radnji ovdje je mnogo širi.

Kao što treba da znate, pošta na Internetu se prenosi između servera pošte koristeći SMTP protokol. Svaka komunikacija koja koristi ovaj protokol počinje s tri potrebna zaglavlja: ZDRAVO, POŠTA OD i RCPT TO... Odnosno, prije nego što počne sa prijenosom bilo kakvih podataka, server se prvo predstavlja (HELO), zatim javlja povratnu adresu pošiljaoca (MAIL FROM), a zatim - adresu primaoca (RCPT TO). Ova tri zaglavlja su potpis na koverti e-pošte i gotovo sav neželjeni sadržaj može se filtrirati samo na osnovu njihove analize. Većina pokušaja slanja nečega na moj server ne ide dalje od MAIL FROM, odnosno, pisma se filtriraju i prije nego što su stvarno prihvaćena, što značajno smanjuje opterećenje. Odnosno, umjesto da otvorim paket iz Tryama i tamo pronađem spore antraksa, odmah šaljem poštara u pakao.

Dakle, šta trebate učiniti kako ne biste prihvatili poruke za koje se zna da su neželjena pošta? Idemo redom.

Malo o DNS-u

Nekada davno, u zoru interneta, pošta se dostavljala direktno na čvorove navedene u poštanskoj adresi. Odnosno, dostaviti pismo za [email protected] mail server je tražio IP adresu domain.com i pokušao poslati paket na pronađenu IP adresu. Tada su se pojavili MX zapisi, koji su odjednom riješili većinu problema takve organizacije interakcije pošte. Međutim, neki programi mogu i dalje raditi sa A zapisima prilikom dostave pošte. Ali, naravno, imate barem jedan MX zapis za svoju domenu, zar ne?

MX zapisi sadrže adrese servera, na kojima treba dostaviti pisma za navedeni domen. Međutim, u cilju suzbijanja neželjene pošte pojavila se tehnologija koja omogućava navođenje adresa servera u DNS-u, With koji može primati pisma sa navedenog domena. Njegovo ime je Sender Policy Framework.

Neću ulaziti u sve detalje tehnologije u detalje, reći ću samo da je TXT zapis

V = spf1 + mx -sve

Uvijek napišite SPF zapis za svoju domenu, a također omogućite SPF provjeru na vašim serverima pošte. Preporučujem vam da strogo zabranite slanje e-pošte sa vaše domene sa svih hostova osim sa vaših MX servera. Zajedno sa SPF provjerom na vašem serveru, takva postavka će odmah prekinuti sva pisma koja se šalju sa hostova trećih strana u ime korisnika vaše domene na adrese korisnika vašeg domena. A takve neželjene pošte je skoro polovina, jer su obično SMTP serveri vrlo slabo zaštićeni od pisama sa vlastite domene, a spameri to aktivno koriste. SPF će vas jednom za svagda spasiti od pisama Vasyi Pupkinu, napisanih, sudeći po koverti od Vasje Pupkina, ali koja dolaze sa servera u nekoj Nikaragvi.

Google će vam reći kako da konfigurišete SPF u Postfixu, ima puno informacija i ne možete pogriješiti, tako da ne gubimo vrijeme na tehničke detalje.

Postoji još par izuzetno važnih napomena o DNS-u. Najvjerovatnije znate da osnovni DNS zapisi, takozvani A zapisi, prevode ime u IP adresu. Pored ovih, postoje i CNAME zapisi koji dodeljuju alias već postojećem imenu. Upravo ove dvije vrste zapisa čine osnovu cjelokupnog sistema naziva domena.

Ali malo korisnika zna da postoje i obrnuti zapisi koji pretvaraju IP u ime domene. Zovu se PTR. Dakle, postoje dva nepisana (strogo govoreći) pravila kojih se svi pridržavaju:

  • Za svaki A zapis mora postojati ogledalo PTR zapis, odnosno po imenu hosta preko DNS-a dobijamo IP, a po IP - nazad isto ime hosta.
  • Adresa u MX zapisu uvijek treba biti ime(ne IP!) host za koji postoji A zapis. To jest, ne možete imati IP ili nadimak (CNAME) u MX zapisu.

Ako ne ispunjavate jedan od ovih zahtjeva, budite spremni na činjenicu da će najmanje četvrtina pošte sa vaše domene biti prepoznata kao neželjena pošta. To je zbog jednostavne teze: pouzdan pošiljalac uvijek postavlja sve poštujući pravila, odnosno, ako se pravila ne poštuju, onda pošiljaocu ne treba vjerovati, pa samim tim i primati poštu od njega.

Pa, da biste omogućili PTR provjeru za sebe, koristite opciju

Reject_unknown_client_hostname

Zahtijeva da se IP sa kojeg se uspostavlja konekcija razriješi u ime putem PTR-a, a ovo ime se opet razriješi na željenu IP adresu.

Postoji i manje strogo ograničenje koje postavlja opcija

Reject_unknown_reverse_client_hostname

U ovom slučaju, server će samo provjeriti postojanje PTR zapisa, ali neće zahtijevati postojanje odgovarajućeg A zapisa.

Provjeravam pozdrav

Dakle, neko je htio poslati e-mail na vaš server. Prijenos počinje pozdravom - HELO zaglavljem. Puno ime domene (FQDN) pošiljaoca mora biti navedeno u HELO-u, odnosno, ako to nije slučaj, možete sigurno odbiti da ga prihvatite odmah. Postfix ima dvije opcije za ovo:

Reject_invalid_helo_hostname
odbaciti_non_fqdn_helo_hostname

Prvi zabranjuje primanje pisama od hostova koji šalju pozdrave s neispravnom sintaksom, drugi - od hostova koji prenose ne-FQDN u HELO zahtjevu.

Međutim, samo najgluplji spameri (i MS proizvodi, ali, kao što znate, ne pišete zakone za njih) ne prenose FQDN, na kraju nije teško predstaviti se gmail.com. Stoga, moramo detaljnije pogledati HELO. Da biste to učinili, koristite opciju

Odbaciti_nepoznato_helo_hostname

Što zabranjuje prijem pisama sa servera koji predstavljaju adresu za koju ne postoji A ili MX zapis.

Pošiljalac - treba li mu vjerovati?

Dakle, server vam se uspešno predstavio, sledeća stavka u programu je adresa pošiljaoca. Iz njega se također može izvući mnogo korisnih informacija. Odmah želim da napomenem da adresa pošiljaoca ne mora biti sa istog domena kao i sam server. Ovo je uobičajena zabluda, pa imajte na umu da nije. Jedan mail server može lako opsluživati ​​više domena.

Međutim, ako adresa pošiljaoca sadrži domenu koja uopće ne postoji, onda pismo očito nije vrijedno prihvaćanja. I svakako ne treba prihvatiti pismo u kojem je nešto naznačeno kao povratna adresa, a koja uopće nije adresa. Postoje dvije opcije za odbijanje prihvatanja ovakvih emailova:

Reject_non_fqdn_sender
reject_unknown_sender_domain

Prvi je da se proveri pravopis adrese, a drugi da se proveri postojanje domena.

Već nije loše, ali možete učiniti više. Možete da upitate server koji opslužuje navedenu adresu pošiljaoca za postojanje korisnika sa ovom adresom na sebi. Zaista, čini se kao dobra ideja da se uvjerimo da povratna adresa zaista postoji, inače bismo mogli dobiti pismo od efemernog fantoma za kojeg niko nikada nije čuo.

Tehnički, vrlo je jednostavan za implementaciju: naš server otvara šaltersku SMTP sesiju, pokušavajući poslati pismo na adresu pošiljaoca. Ako možete uspješno proći fazu slanja RCPT-a NA sa ovom adresom, tj. ako server za prijem iznenada ne izjavi da navedeno poštansko sanduče nije na njemu, onda se smatra da povratna adresa koja nam je poslata postoji. Naravno, nikakvi podaci (tj. pismo) se ne prenose tokom verifikacije, sesija se prekida nakon RCPT TO.

Opcija je odgovorna za ovu provjeru povratne adrese.

Reject_unverified_sender

Iz navedenog proizilazi da za bilo koju adresu sa koje šaljete poštu sa svoje domene mora postojati poštanski sandučić na vašem serveru. U suprotnom, vaša pisma neće proći provjeru povratne adrese na strani primatelja i, shodno tome, neće biti isporučena na odredište. Ovo je relevantno za bilo koju poštu i drugu vrstu jednosmjerne komunikacije koja ne zahtijeva odgovor. Uvijek kreirajte poštanske sandučiće za sve adrese sa kojih šaljete poštu. Ako ne želite da primate odgovore na neku adresu, onda jednostavno pošaljite pisma na nju u /dev/null, ali ćete ta pisma primati. su dužni.

Da li primalac uopće postoji?

Tako smo došli do posljednjeg zaglavlja koverte - do primaoca. Ovdje je sve jednostavno: prvo, bilo bi lijepo provjeriti da li su informacije koje nam se šalju uglavnom adresa e-pošte. To se radi direktivom

Reject_non_fqdn_recipient

Osim toga, ne bismo željeli primati poštu na adrese za koje nemamo poštanske sandučiće. Da biste konfigurirali ovo ponašanje, prvo morate kreirati listu podržanih poštanskih sandučića, a zatim obavijestiti Postfix o tome putem jednog od * _recipient_maps parametre konfiguracijske datoteke, pa, onda ili koristite parametar konfiguracijske datoteke

Smtpd_reject_unlisted_recipient = da

Ili opcija zabrane koja ima isti učinak:

Reject_unlisted_recipient

Postfix će ionako prestati primati e-poštu za prihvaćene domene ako ne postoji poštansko sanduče primaoca. Međutim, ovo ograničenje ni na koji način neće utjecati na prosljeđivanje korespondencije na adrese koje nisu u prihvaćenim domenima.

I konačno, možete općenito zabraniti otvoreno prosljeđivanje pisama putem vašeg Postfixa, ostavljajući samo mogućnost primanja pisama na poznate adrese. U ove svrhe se koristi opcija

Reject_unauth_destination

Zabranjuje slanje e-pošte svim neregistrovanim korisnicima (da, moraćete da konfigurišete SMTP autorizaciju). Uvijek koristite ovu opciju! U suprotnom, brzo ćete ući u sve vrste DNSBL-a.

Kao međuzbroj

Ovako možete filtrirati ogromnu količinu neželjene pošte samo na osnovu analize tri zaglavlja koverte. Međutim, spameri su lukavi, pa to još uvijek nije dovoljno.

Greylisting

Ponekad su serveri pošte preopterećeni i ne mogu primiti pismo. Mislite li da odgovaraju na pristigle zahtjeve u ovom slučaju? Čudno, oni odgovaraju - server privremeno nedostupno, pokušajte kasnije. Niti jedan normalan pošiljalac u ovom slučaju nikada neće uzeti u obzir da pismo ne može biti uručeno sa svim posljedicama koje proizilaze. Naprotiv, pošiljalac će pokušati da dostavi pismo kasnije, stavljajući ga na red za slanje. Ova činjenica se može (i bez sumnje treba!) iskoristiti vrlo efikasno: svaki prvi pokušaj povezivanja sa nepoznatog hosta, naš server će poslati poruku o privremenoj grešci, a preskočiti pismo tek drugi put. Ovo će filtrirati skoro svu preostalu neželjenu poštu odjednom, pošto serveri za neželjenu poštu skoro nikada ne pokušavaju više od jednog pokušaja da isporuče poruku (inače bi se jednostavno "srušili" od prelivanja reda). Ova tehnologija se zove Greylisting i jednostavno ju je neophodno koristiti u modernim stvarnostima.

Nedostatak ove aplikacije je malo (obično ne više od pola sata) kašnjenje u isporuci pisama na prvom vezu sa nepoznatog hosta. Odnosno, ako server koji još nije poznat našem postfixu želi poslati pismo, tada mu se pri prvom pokušaju povezivanja šalje greška o privremenoj nedostupnosti. Ako se server pokuša ponovo povezati, pismo je prihvaćeno, a server se unosi u pouzdane čvorove i daljnja pisma s njega se prihvataju bez odlaganja.

Također predlažem da pročitate o postavljanju sivih lista u Postfix-u u Googleu, lako je i ne možete pogriješiti.

Blocklists, ili kako to ne učiniti

Neki administratori e-pošte se oslanjaju na takozvane DNSBL-ove (RBL) za filtriranje neželjene pošte, a to su crne liste lokacija na kojima se vidi da šalju neželjenu poštu. dakle, nikad ne dodaj nema DNSBL provjera na vaše mail servere. Dva su razloga za to: prvi, i najosnovniji, obrađen je u drugom dijelu prve rečenice ovog odjeljka. Čvorovi se u ove liste unose potpuno nasumično i nema garancije da običan host neće stići tamo (na kojem se, možda, u nekom trenutku nastanio virus koji šalje neželjenu poštu, ali sada je virus već izliječen, ili jednostavnije i mnogo realnije, jedna eksterna IP adresa za veliku mrežu u kojoj je spamer završio). Drugi razlog je uobičajeniji: gore predloženi mehanizam filtriranja je mnogo efikasniji od bilo kojeg DNSBL-a i ne oslanja se na neprovjerene podatke trećih strana.

Naopako, ili pogledajte s druge strane barikada

Naučili smo kako da filtriramo neželjenu poštu, sada ću pokušati da objedinim sve informacije na temu šta treba učiniti da ne ući u neželjenu poštu.

Za administratore mail servera:

  • Uvek neka se MX zapisi odnose na A zapise.
  • A zapis za mail server mora uvijek imati preslikani PTR zapis.
  • Host iz HELO zaglavlja mora imati A ili MX zapis.
  • Uvek kreirajte SPF zapise (da, ovo jednostavno nije neophodno, već samo pravilo dobre forme).
  • Za svu poštu poslanu sa prihvaćene domene, mora postojati okvir za povratnu adresu i primati poštu.
Za one koji šalju poštu (iz programa, sa sajtova itd.):
  • Uvijek šaljite poštu samo s postojećom povratnom adresom.
  • Nikada ne šaljite poštu sa domene koju ne kontrolišete bez provjere SPF pravila za to. Na primjer, gmail.com trenutno dozvoljava slanje pisama u njegovo ime na bilo koji server, ali yandex.ru i mail.ru obavještavaju preko SPF-a da slanje u njihovo ime sa servera trećih strana treba da privuče veliku pažnju, što se tumači pametnim filteri za neželjenu poštu kao povećanje ocjene neželjene pošte za datu e-poštu.
  • Nikada nemojte slati poštu preko pogrešno konfigurisanih SMTP servera. Provjera servera na vaške prema gornjoj listi je pitanje od 5 minuta, uslužni program će vam pomoći dig ili nslookup.

Sažetak

Naravno, predložene postavke ne filtriraju svu neželjenu poštu. Stoga je sasvim moguće da ćete morati dodatno koristiti kontekstni filter koji će analizirati sadržaj slova, na primjer,

Kada ste odsutni od kuće i šaljete poruku e-pošte koristeći svoj kućni račun e-pošte, e-pošta se može vratiti s greškom 550, 553 ili greškama releja. Ista stvar se može desiti kada ste van kancelarije pokušavajući da pošaljete e-poruku koristeći svoj poslovni nalog e-pošte.

Opis

Do prosljeđivanja dolazi kada se poruka e-pošte pošalje na adresu e-pošte čiji domen (ime nakon simbola @, kao što je adatum.com) ne obrađuje SMTP ili server odlazne pošte koji prima zahtjev za isporuku poruke od pošiljaoca. SMTP server se mora povezati sa drugim SMTP serverom da bi prenio poruku.

Ako dođe do greške releja prilikom slanja e-mail poruke, vaš SMTP (odlazna pošta) server može vratiti vašu poruku zajedno s porukom o grešci poput ove:

    Tema:<тест>, račun:<тест>, server: , protokol: SMTP, odgovor servera: "550 Relej je zabranjen ", port: 25, sigurnost (SSL): ne, greška servera: 550, broj greške: 0x800CCC79".

    "Poruku nije bilo moguće poslati jer je server odbio da prihvati adresu jednog od primalaca. Poruka je sadržavala adresu:<адрес эл. почты>... Tema:<тест>, račun:<тест>, server: , protokol: SMTP, odgovor servera: "553 nažalost ovaj domen nije na mojoj listi dozvoljenih hostova (# 5.7.1)", port: 25, sigurnost (SSL): ne, greška servera: 553, broj greške: 0x800CCC79 " ...

Tačan tekst poruke o grešci ovisit će o vašem ISP-u. Neki dobavljači ne vraćaju poruku o grešci kada identifikuju odlazne poruke kao neželjene oglase. U tim slučajevima sve izgleda kao da se vaša poruka normalno šalje (u Outlooku ostaje u Outbox i pojavljuje se u folderu Poslano), ali se ne isporučuje primaocu.

Vaša poruka je odbijena jer vas (odlazni) SMTP server nije prepoznao kao ovlaštenog korisnika.

SMTP je protokol (standardi koje računari koriste za komunikaciju) koji koristi većina servera e-pošte za slanje poruka na Internetu. Ako koristite program za e-poštu (kao što je Outlook) koji vam omogućava čuvanje poruka na računaru, potreban vam je pristup SMTP serveru da biste slali poruke.

Bilješka: Sistemi e-pošte zasnovani na vebu (kao što su Windows Live Mail ili Yahoo! Mail) rade drugačije i nisu obuhvaćeni u ovom članku.

Neželjena pošta i otvoreni releji

Reklamne poruke koje se distribuiraju bez upita nazivaju se neželjena pošta ili neželjena pošta. Količina neželjene pošte nastavlja da raste jer je slanje onima koji je šalju gotovo ništa. U stvari, pošiljalac čak i ne mora da šalje neželjenu poštu preko SMTP (odlaznog) servera svog ISP-a.

U stvaranju osnovne strukture interneta, niko nije predvidio implikacije mogućnosti slanja miliona neželjenih poruka uz zanemarljive troškove. Zahvaljujući sposobnosti prenošenja SMTP servera, pošiljaoci neželjene pošte maskiraju porijeklo neželjene pošte tako što je propuštaju kroz servere trećih strana koji dozvoljavaju takvo otvoreno prenošenje. Kao rezultat toga, izgleda da neželjena pošta dolazi sa stranice koja prenosi poruku i skriva identitet pravog pošiljaoca.

Do nedavno, većina SMTP servera pošte radila je na pouzdanom otvorenom sistemu. U takvom sistemu, svako sa bilo kojeg mjesta može poslati mail poruku na SMTP server, a server je mora prihvatiti i proslijediti primaocu ili drugom mail serveru gdje se nalazi poštansko sanduče primaoca. Sa ovim otvorenim relejem, nema ograničenja koja sprečavaju bilo koga da šalje poštu preko SMTP servera.

Ograničenja provajdera internetskih usluga za prenošenje pošte

Kako se količina neželjene pošte povećavala, mrežni administratori (ljudi zaduženi za upravljanje serverima ISP-a) počeli su da nameću ograničenja na svoje SMTP servere pošte. Ova ograničenja sprečavaju sve da koriste mail server. Zamislite da se u predvorju vaše organizacije nalazi telefon koji je dostupan svima, uključujući i one koji nisu dio organizacije. Sada samo zaposleni mogu koristiti telefon.

Danas se koristi nekoliko vrsta ograničenja.

    Zahtijeva SMTP autentifikaciju. Baš kao što koristite korisničko ime i lozinku za pristup POP3 serveru (dolazna pošta) i svojim porukama, potrebno je da unesete korisničko ime i lozinku za slanje pošte preko SMTP servera. Ovo je obično isto korisničko ime i lozinka kao za POP3 server, ali može biti jedinstveno.

    Prvo se morate povezati sa POP3 serverom (dolazna pošta) vašeg Internet provajdera. Da biste primali nove poruke pošte, obično se povezujete na POP3 (dolaznu pošta) server. Da biste pristupili svom poštanskom sandučetu, potrebno je da unesete svoje korisničko ime i lozinku. Vaš mrežni administrator može konfigurirati server tako da ako se prvo povežete na ulazni POP3 server i izvršite autentifikaciju, on će odobriti sve zahtjeve za slanje pošte preko odlaznog SMTP servera, koji bi inače bio ograničen.

    Zahtijeva vezu s ovlaštene mrežne lokacije. Ako se od kuće povežete na internet provajdera koristeći telefonsku liniju, kablovsku ili DSL modem, veza ide direktno na mrežu provajdera. Pouzdani ste jer imate nalog sa korisničkim imenom i lozinkom koje vam je obezbedio vaš internet provajder. Kao klijentu, dozvoljeno vam je da koristite SMTP server za slanje pošte.

    Zahtijeva vezu sa određene IP adrese ili raspona IP adresa. Vaš ISP može dozvoliti ljudima koji nisu direktno povezani na mrežu da pristupe SMTP serveru. Na primjer, to može biti udaljeni korisnik u kancelariji. Glavni problem je što se dinamičke IP adrese koriste na mnogim mjestima. Međutim, ne možete biti sigurni da imate istu IP adresu svaki put kada se povežete. Neke organizacije mogu imati rezerviran blok ili raspon IP adresa. ISP može smatrati one koji se povezuju sa ovih IP adresa verifikovanim od strane korisnika. On može dati dodatne informacije.

Postoji mnogo mogućih scenarija prenošenja. Ispod su najčešće situacije. Možda je jedan od njih sličan vašem.

Situacija

Je li ovo relej?

Kod kuće ste i imate nalog Internet provajdera koji završava na @ proseware.com na koji se povezujete preko telefonske linije, kabla ili DSL modema. Šaljete poruku drugoj osobi čija adresa e-pošte također završava na @ proseware.com.

Isto kao u prvoj situaciji, samo što šaljete poruku osobi čija poštanska adresa završava sa @adatum.com.

Da, ali nije blokiran. Povezujete se direktno sa provajderom Internet usluga i na taj način dobijate ovlašćenje za slanje pošte preko njegovog SMTP servera (odlazne pošte) na bilo koju adresu, bez obzira na lokaciju poštanskog sandučeta primaoca.

Jesi li na poslu. Vaša poslovna poštanska adresa završava na @thephone-company.com, a imate kućni račun ISP-a koji završava na @proseware.com i na koji se povezujete preko telefonske linije, kabla ili DSL modema... U Outlooku imate konfigurisane iste postavke SMTP servera kao kod kuće. Šaljete poruku nekome čija adresa e-pošte također završava na @ proseware.com.

br. Vaša pošta se obrađuje na uobičajen način.

Odsjedate u hotelu ili koristite internet terminal na aerodromu koji omogućava pristup internetu. Imate kućni nalog dobavljača Internet usluga (ISP) koji završava na @ proseware.com na koji se povezujete putem dial-up, kablovskog ili DSL modema. U Outlooku imate konfigurisane iste postavke SMTP servera kao kod kuće. Šaljete poruku drugoj osobi čija adresa e-pošte također završava na @ proseware.com.

br. Vaša pošta se obrađuje na uobičajen način.

Isto kao u prethodnoj situaciji, samo što šaljete poruku osobi čija poštanska adresa završava na @adatum.com.

Da, i ova poruka se može blokirati kao proslijeđena pošta. Pokušavate da koristite kućni SMTP (odlazna pošta) server vašeg ISP-a, iako niste povezani na njihovu mrežu. SMTP server ne može vas autentifikovati kao ovlaštenog pretplatnika ISP-a. Pored toga, tražite od SMTP servera da prihvati poruku i poveže se sa drugim SMTP serverom kako bi je isporučio u poštansko sanduče primaoca.

Rješenja

Ako se vaša situacija smatra relejnom, morate poslati poruku preko servera na koji se trenutno povezujete. Odnosno, ako ste na poslu ili odsutni od kuće i ne koristite svog ISP-a za povezivanje na Internet, ali želite poslati poruku sa svog kućnog računa koji pruža taj ISP, morate promijeniti postavke računa e-pošte da navedete da SMTP server koji koristite tamo gdje se nalazite (na primjer, SMTP server koji radi). Za detaljna uputstva pogledajte članak.

Ako to ne uspije ili ako više volite koristiti kućni račun, trebate kontaktirati svog ISP-a i pitati da li su vam dostupne opcije opisane ranije. Što se tiče prva dva ograničenja (zahteva SMTP autentifikaciju i prvo povezivanje sa POP3 serverom dolazne pošte ISP-a), možete napraviti promjene u Postavke računa u programu Outlook. Za uputstva pogledajte Promjena postavki računa e-pošte.

Još uvijek ne šaljete poruke?

Promijenili ste SMTP postavke u Outlooku ili ste pronašli opciju koja će vam omogućiti slanje e-mail poruka. Ali i dalje ne možete slati poštu i primati poruku o grešci.

Možda ste sve uradili kako treba, ali mrežni administratori koriste neku drugu sigurnosnu funkciju kako bi spriječili lažiranje identiteta. Prevara identiteta je jednostavno način slanja e-mail poruka u kojima skrivate ko ste.

U Outlooku, kao i kod većine programa za e-poštu, možete navesti "ime za prikaz" i povratnu poštansku adresu koja se pojavljuje kada odgovorite na poruku. U neželjenoj pošti ova polja gotovo uvijek sadrže lažne informacije. Vjerujete li zaista da poruke o brzom bogaćenju dolaze od supermodela ili svjetskog lidera?

Kako bi spriječili lažiranje identiteta, neki ISP-ovi ograničavaju mogućnost umetanja lažnih informacija u polje adrese u odgovorima. Na primjer, ako ime domene vašeg ISP-a završava na proseware.com, ISP vam možda neće dozvoliti da unesete povratnu adresu. [email protected]... Ovo ograničenje se ne koristi tako široko kao što je prethodno opisano, ali se može primijeniti na sve korisnike bez obzira na njihovu lokaciju ili način povezivanja. U ovom slučaju nema alternative. Ako administrator servera koristi ovaj metod, morate navesti domenu koja odgovara vašoj trenutnoj vezi u povratnoj adresi.

Top srodni članci