Konfigurimi i postës elektronike (pa email në postë të padëshiruar). Humbja e mesazheve postare

Vendosja e dërgimit të emaileve pa i futur ato në postë të padëshiruar.

Opsioni për të dërguar email përmes serverëve SMTP të palëve të treta (Mandrill, Mailgun, Yandex) dhe përmes adresat personale Unë nuk do të konsideroj shërbimet e postës (gjithçka është shumë e thjeshtë atje, nëse ndiqni udhëzimet e dhëna të instalimit) - Unë do të konsideroj vetëm opsionin që ne kemi serverin tonë, në të cilin është instaluar në përputhje me rrethanat serveri i postës, si exim (si shumica e hosteve).

Do të na duhet akses për të modifikuar të dhënat DNS dhe zotërim minimal të konsolës Cilësimet e DKIM(nëse ka ISPmanager - dhe ky artikull bëhet i parëndësishëm). Në total, do t'ju duhet të konfiguroni (shtoni) 4 hyrje të reja në të dhënat DNS të domenit tuaj: PTR, SPF, DKIM dhe DMARC.

• PTR- i ashtuquajturi rekordi DNS "i kundërt". Duhet të jetë i detyrueshëm, sepse numër i madh shërbimet e postës për treguesin e tij të pasaktë është i patolerueshëm. Në teori, ai duhet të instalohet nga hosti juaj, për shembull DigitalOcean e bën atë automatikisht. - por ekziston një opsion dhe cilësimet e tij manuale.
• SPF- një rekord që tregon se serveri juaj lejohet të dërgojë email nga ky domen dhe IP. Nuk ka këtë rekord - hyrja në postë të padëshiruar është pothuajse e garantuar. Instalimi është shumë i thjeshtë - informacione gjithëpërfshirëse me shembuj të konfigurimit mund të merren në (informacione në pllakën e gjelbër) ose në.
• DKIM- nënshkrim elektronik letrat tuaja. Nëse janë dy hyrjet e mëparshme- i jep "peshë" domenit tuaj dhe shkronjave prej tij, falë të cilave i njëjti Yandex, për shembull, shënon shkronja me një shenjë të këndshme të gjelbër.

Vendosja e këtij nënshkrimi është ndoshta më e vështira - si rezultat, 90% e faqeve nuk e kanë atë, por rekomandohet shumë. Është shumë e lehtë ta konfigurosh në ISPmanager: aktivizo mbështetjen e DKIM në skedën e veçorive, në redaktim domeni i postës kontrolloni kutinë e kontrollit DKIM dhe merrni hyrjen e gatshme në vetitë e domenit (NS). Nëse nuk ka ISPmanager, ju këshilloj të përdorni këtë artikull mjaft të thjeshtë:.

• DMARC- Standardi është krejtësisht i ri, por tashmë është duke u zbatuar në mënyrë aktive nga shërbimet e postës dhe këtë vit tashmë është 100% që duhet të ketë. Konfigurimi është më i thjeshti nga të gjitha hyrjet e mësipërme, ju duhet vetëm të shtoni një nga shembujt e listuar në këtë faqe më poshtë: - Unë këshilloj të dytin.

Serveri juaj tani është konfiguruar dhe nëse gjithçka është bërë si duhet, asnjë shkronjë e vetme nuk do të shkojë në postë të padëshiruar. Për shembull, një pamje konfirmuese e ekranit nga zyra postare mail.ru (një situatë e ngjashme me mungesë totale identifikimi i postës elektronike si spam dhe sipas Yandex):

Kthimi i konfigurimit të koleksionistit të postës.

XenForo ka një mekanizëm absolutisht të mahnitshëm që pothuajse askush nuk e përdor - mbledhësin e postës elektronike të kthimit. Mendoj se të gjithë janë përballur me situatën që pas kryerjes postime masive Kutia postare merr një numër të madh letrash të formës së mëposhtme:

Ky mesazh u krijua automatikisht nga programi i dërgimit të postës.

Një mesazh që dërgove nuk mund të dërgohej në një ose më shumë prej tij
marrësit. Ky është një gabim i përhershëm. Adresat e mëposhtme dështuan:

***@rambler.ru
Gabim SMTP nga serveri i postës në distancë pas RCPT TO:<***@rambler.ru>:
host imx1.rambler.ru : 540 5.7.1<***@rambler.ru>:
Adresa e marrësit u refuzua: Email-et tuaja janë kthyer sepse llogaria e emailit e marrësit të synuar është pezulluar. Llogaria duhet të riaktivizohet për të marrë mesazhe hyrëse.

Këto emaile janë një sinjal se përdoruesit tuaj kanë adresa të vjetruara. Email(kutitë janë të bllokuara, të fshira, të plota), që do të thotë se ata nuk do të marrin letra të reja nga ju dhe, nëse është e nevojshme, nuk do të jenë në gjendje të rivendosin llogarinë e tyre në forum. Shumë përdorues as nuk e dinë se po përdorin një adresë emaili të vjetëruar, por shërbimet e postës, duke parë një numër të madh email-esh të dërguara në adresa joekzistente, ato mund ta vendosin domenin tuaj në listën e postës së padëshiruar.

Kjo duhet luftuar, sepse edhe në forumin tim, ku ky sistem ka funksionuar më shumë se postimi i parë, ka shumë letra "të kthyera", në krahasim me numrin e përdoruesve:

• Për të filluar, ne krijojmë adresa postare, të cilave do t'u dërgojmë letra të kthyera (kutia është sistemore dhe nuk duhet të përdoret për asnjë qëllim tjetër) - për shembull ku google.com është domeni juaj.

• Shkoni te seksioni i administratorit Cilësimet - Cilësimet e postës elektronike. Në fushën e Adresës së Kthimit, futni kutinë postare që keni krijuar. Vendos një tik-tak përpunim automatik letra të padorëzuara dhe tregoni të dhënat për hyrjen e kutisë postare të shërbimit që keni krijuar më parë: adresën (në rastin e serverit tuaj SMTP, specifikoni tuajin), hyrjen (adresën që keni krijuar) dhe fjalëkalimin nga kutia. Unë do të jap një shembull të cilësimeve të mia - unë kam një postë biznesi nga Mail.ru - prandaj, lidhem me serverin e tyre për të marrë postë nga një kuti shërbimi

Në thelb, ky është i gjithë konfigurimi. Forumi do të shkojë automatikisht në kutinë postare të shërbimit që keni specifikuar në intervale të caktuara, do të shkarkojë kopje të letrave të kthyera që ka marrë dhe do t'i fshijë ato prej andej. Në kapitullin Mjetet - Regjistri i dështimit të dërgimit të emailit ju mund të shikoni këto statistika. Theksoj veçanërisht se kjo kuti nuk mund të përdoret për ndonjë qëllim tjetër, përndryshe rrezikoni të merrni disa gabime mjaft qesharake në regjistrat e panelit të administratorit.

Sipas kushteve që keni vendosur, kur ktheheni, për shembull, 3 letra nga një adresë, përdoruesi do të dërgohet për riaktivizim automatik - do t'i kërkohet të tregojë adresën aktuale të emailit dhe të riaktivizojë llogarinë. Asnjë nga pjesëmarrja juaj nuk kërkohet - përdoruesit do të tregojnë vetë adresat e tyre aktuale të emailit dhe për këtë arsye problemi do të largohet me kalimin e kohës. Dhe kur dërgoni postë, përdoruesit me një adresë të pasaktë të postës elektronike mund të përjashtohen prej tij - duke shmangur kështu një goditje të mundshme në listat e postës së padëshiruar.

Është shkruar shumë tekst, por në fakt, konfigurimi i gjithçkaje - si serveri ashtu edhe mbledhësi i postës, zgjat disa minuta, nëse ndiqni udhëzimet saktësisht. Vendoseni një herë dhe harroni se emailet tuaja të forumit nuk arritën diku ose se domeni juaj ishte përfshirë në listat e postës së padëshiruar sepse baza e të dhënave është e vjetëruar.

Për të thjeshtuar disa nga detyrat e përshkruara më sipër, mund të përdorni njërën nga ato - çfarëdo që preferoni. Unë përdor të parën - por zgjedhja varet tërësisht nga ju. Shtimi i domeneve tuaja atje do t'ju japë kuti postare të përshtatshme dhe të pakufizuara me filtra të integruar tashmë të spam-it + njëfarë thjeshtimi të cilësimeve të serverit (një pjesë e të dhënave do të sigurohet automatikisht (me përjashtim të DKIM, i cili duhet të gjenerohet manualisht për të dërguar postë nga server në një mënyrë ose në një tjetër)).

Shembuj letrash:

550 5.7.1 Ky mesazh nuk u pranua për shkak të politikës DMARC të zotëruesit të domenit (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc

550-5.7.1 Email i paautentikuar nga mail.ru nuk pranohet për shkak të politikës DMARC të domenit 550-5.7.1. Ju lutemi kontaktoni administratorin e domenit mail.ru nëse kjo 550-5.7.1 ishte një postë e ligjshme. Ju lutemi vizitoni 550 -5.7.1 https://support.google.com/mail/answer/2451690 për të mësuar rreth DMARC

550 5.7.1 Email i refuzuar sipas politikës DMARC për ...

Problemi i dërgimit të mesazhit në lidhje me aplikimin e politikës së re DMARC lidhur me shtrëngimin e rregullave për kalimin e filtrave të spamit.

DMARCështë një protokoll mbrojtjeje anti-spam dhe anti-spam i bazuar në mekanizmat ekzistues DKIM dhe SPF. Faqja zyrtare: dmarc.org.

Nëse po merrni mesazhe të ngjashme me ato të mësipërme, ka shumë të ngjarë, posta nga faqja juaj të dërgohet në emër të kuti postare në bazë @mail.ru, @bk.ru, @list.ru ose @inbox.ru. Mail.Ru nuk pranon mesazhe të dërguara përmes phpmail nëse titujt e postës përmbajnë një kuti postare që i përket mail.ru. Mesazhe të tilla, sipas politikës së zbatuar nga Mail.Ru DMARC, refuzohen.

Si ta zgjidhni problemin

Ka dy mënyra për të zgjidhur problemin:

Metoda 1: Ndryshoni kutinë postare nga e cila dërgohen mesazhet

Zakonisht e-mail-i, në emër të të cilit dërgohen mesazhet postare, regjistrohet në pjesën administrative të CMS. Mund të ndryshohet gjithashtu drejtpërdrejt në skriptin që dërgon mesazhe (fusha "Nga").

Është e nevojshme që mesazhet të dërgohen nga një kuti postare bazuar në emrin e domenit tuaj, për shembull « [email i mbrojtur]» , ku domain.ru është domeni juaj. .

Gjithashtu, kutia postare duhet të ndryshohet në skedarin php.ini:

Ndryshimi i kutisë në php.ini

1. 1 hyni në panelin e kontrollit të hostit dhe hapni skedarin php.ini për redaktim: ;
2. 2

   gjeni një rresht si:
   

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

   Në këtë linjë, në vend të « [email i mbrojtur]» specifikoni një kuti postare jo-domeni @mail.ru, @bk.ru, @list.ru dhe @inbox.ru.
   Është e këshillueshme që të specifikoni një kuti postare në domenin tuaj, për shembull, « [email i mbrojtur]» , ku domain.ru është domeni juaj.

   Përveç kësaj, kutia postare e specifikuar në php.ini duhet të ekzistojë. Nëse përdorni postë në një host, krijoni një kuti postare në domen dhe regjistrojeni atë në skedarin php.ini.

Metoda 2: Përdorni autorizimin SMTP

Ju mund të dërgoni mesazhe në emër të kutisë tuaj postare bazuar në Mail.Ru duke vendosur autorizimin SMTP. Në këtë rast, të gjitha mesazhet përmes faqes tuaj do të dërgohen direkt nga serverët Mail.Ru.

Gabimet sistemi postar janë kode që u caktohen mesazheve në momentin e marrjes ose refuzimit të marrjes. Kodi i gabimit ju lejon të zbuloni arsyen pse dorëzimi nuk ishte i mundur mesazh me postë. Në mënyrë tipike, kodi i gabimit është një numër, si #550 ose #2001. Kodet e gabimit janë përshkruar më poshtë.

Mesazhe pa kode

adresë e padrejtuar

Dështoi në përcaktimin e serverit për të përcjellë mesazhin e postës. Arsyet e mundshme:

• Domeni në të cilin dërgohet posta nuk ekziston ose nuk është deleguar
• As regjistrimet MX dhe A nuk janë të regjistruara për domenin
• Regjistri MX tregon një emër joekzistent

Përdoruesi i panjohur

Kjo kuti postare nuk ekziston, ose adresa e postës është e pasaktë

transmetimi në vazhdim. qëndroni të sintonizuar

Mesazhi shfaqet kur dërgoni email klient email. Ky mesazh nuk është nga sistemi ynë i postës. Do të thotë që përdoruesi ka rrjet lokal ekziston një antispam ose mur zjarri që kontrollon të gjitha emailet dalëse.

Mbi kuotën

Gabim LMTP pas përfundimit të të dhënave: 552 5.2.2 Mbi kuotën
Gabimi ndodh kur kutia postare e marrësit është plot.

Mesazhe me kode

#1005

Verifikimi i thirrjes së dërguesit dështoi
Kontrollimi i dërguesit të letrës. Gabimi mund të jetë ose i plotë, siç tregohet më poshtë, ose i shkurtuar: "Verifikimi i dërguesit dështoi [#1005]". Një gabim dërgohet nga një server që ka implementuar përpjekje e dështuar dërgoni një email në serverin tonë. Serveri ynë është renditur në rreshtin "... ndërsa flasim me mx3.site.:".

Adresat e mëposhtme kishin gabime të përhershme fatale ----- (arsyeja: 550-Verifikimi dështoi për ) ----- Transkripti i sesionit vijon ----- ... ndërsa flisni me mx3.site.: >>> MAIL Nga: SIZE=523<<< 550-Verification failed for <<< 550-User unknown (200) <<< 550 Sender verify failed [#1005]. 554 5.0.0 Service unavailable

Adresa [email i mbrojtur]- Kjo është adresa e marrësit të letrës, është dhënë vetëm për hir të plotësimit.
Adresa e dërguesit [email i mbrojtur] nuk e kaloi testin, siç shkruhet në mesazh.

Për çdo letër, dërguesi kontrollohet. Për ta bërë këtë, serveri ynë përpiqet të lidhet me serverin që merr postë për domenin e dërguesit (në shembull - shembull.com) dhe të dërgojë një email nga adresa "<>» në adresën e dërguesit (në shembull [email i mbrojtur]). Të tilla emaile duhet të pranohen gjithmonë, sepse kështu duken mesazhet për dërgesat e dështuara. Nëse serveri përgjigjet se një kuti postare e tillë nuk ekziston (në shembull, serveri që shërben në domenin example.com u përgjigj "550-Përdorues i panjohur (200)") ose refuzon përpjekjen për arsye të tjera, atëherë një letër nga adresa [email i mbrojtur] e pa pranueshme.

Kontrollimi i adresës së kthimit nuk është mbrojtje ndaj spamit (edhe pse ndihmon në filtrimin e disa prej tyre). Serveri duhet të jetë në gjendje t'i dërgojë një mesazh dërguesit nëse nuk ishte në gjendje t'ia dorëzonte mesazhin marrësit. Për të garantuar këtë mundësi, kontrollohet adresa e kthimit.
Në këtë rast, ju jeni në dijeni të problemit sepse serveri ynë nuk e pranoi mesazhin (duke treguar probleme komunikimi me domenin e dërguesit) dhe serveri dërgues ia raportoi këtë dërguesit. Nëse serveri ynë do ta kishte pranuar mesazhin pa kontrolluar mundësinë e një dërgese të kthimit, nuk do të kishit ditur për problemin.

Një letër me një adresë të pasaktë kthimi është një problem që duhet zgjidhur, por në asnjë rast duke çaktivizuar mjetin që e sinjalizon.

#1004

Na vjen keq, ne nuk pranojmë mesazhe nga hostet pa regjistrim PTR
Gabimi ndodh kur nyja dërguese nuk ka një rekord PTR.

#1007

Ne nuk pranojmë adresa ip dinamike, ju lutemi përdorni smtp-në e ofruesit tuaj [#1007] ose IP dinamike u refuzua [#1007]
Ky gabim ndodh për përdoruesit që përdorin një grup adresash dinamike për lidhjen e tyre. Kontrolli kryhet në bazë të adresës IP të përdoruesit (prania e fjalëve dial, ppp, pool, dsl, dinamike, statike dhe dukurive të tjera në të).

#1008

Verifikimi i dërguesit dështoi
Posta nga kreu i sesionit smtp përmban një adresë kthimi të pavlefshme (për shembull, një domen që nuk ekziston).

#1009

Ne nuk pranojmë adresa ip dinamike, ju lutemi përdorni smtp-në e ofruesit tuaj [#1009]
Ky gabim ndodh kryesisht për përdoruesit që përdorin lidhje DSL ose DialUp dhe dërgojnë postë nga kompjuterët e tyre lokalë, me fjalë të tjera, duke mos përdorur serverin SMTP të ofruesit të tyre. Kontrolli bazohet në një shprehje të rregullt për:
^((1,3)\D+)(2)((1,3)[^\d\.]*).*\.(\w|-)+\.\w(2,4)$
Nëse për ndonjë arsye nuk mund të përdorni serverin SMTP të ofruesit tuaj, shkruani një kërkesë për mbështetjen teknike duke treguar adresën tuaj ip, ajo do të shtohet në listën e bardhë.

#1014

Posta u refuzua, shikoni http://www.spamcop.net/w3m?action=checkblock&ip=IP adresën [#1014]
Ne përdorim listat e zeza të DNS të spamcop.net për mbrojtjen e spamit. Adresa e dërguesit është në listën e zezë spamcop.net

#1020

Rele nuk lejohet
U bë një përpjekje për të dërguar një email në një domen që nuk shërbehet nga serverët tanë të postës.

#1024

Verifikimi i marrësit dështoi
Kontrollimi i marrësit të letrës. Gabim ndodh nëse domeni shërbehet nga serverët tanë, por një adresë e tillë nuk ekziston në domen.

#1025

Verifikimi i thirrjes së marrësit dështoi
Kontrollimi i marrësit të letrës. Ndodh një gabim nëse serveri në distancë përgjigjet se një marrës i tillë nuk ekziston.

#1305

Po dërgoni shumë mesazhe
Është tejkaluar kufiri për dërgimin e emaileve përmes smtp. Për të rritur kufirin, duhet të kontaktoni shërbimin e mbështetjes teknike.

#2002

Kërkohet vërtetimi
Për të dërguar, duhet të vërtetoni me një emër përdoruesi dhe fjalëkalim.
Mund të shihen shembuj të konfigurimit të saktë të klientëve të postës

Lufta kundër spamit është një dhimbje koke për të gjithë administratorët përgjegjës të postës. Ajo që ata nuk shpikin për ta bërë jetën më të mirë për përdoruesit e tyre të preferuar. Sidoqoftë, siç ka treguar praktika e komunikimit me shumë administratorë të sistemit, për disa arsye, jo të gjithë e kuptojnë se si të filtrojnë saktë spamin.

Qasja më e zakonshme është "shtoni një grumbull RBL (DNSBL) dhe shijoni jetën". Qasja nuk është e vërtetë pak më shumë se plotësisht. I dyti më i popullarizuari është filtrat e përmbajtjes, shpesh të blerë për para të mëdha. Kjo qasje është gjithashtu në shumicën e rasteve plotësisht e pajustifikuar.

Por gjithçka është kaq e thjeshtë, për një jetë të qetë, mjafton vetëm të shikoni nga afër tre titujt e sesionit të ardhshëm SMTP. Duke gërmuar nëpër Habré dhe në rrugët e pasme të internetit, nuk gjeta një artikull shterues mbi temën e konfigurimit të saktë të një serveri SMTP për sa i përket kundërshtimit të spamit. Prandaj, vendosa të pikturoj gjithçka që di për këtë temë vetë dhe atë që përdor me sukses.

Nga rruga: ky artikull sigurisht që synon kryesisht administratorët që duan të bëjnë një filtër spam me cilësi të lartë. Sidoqoftë, nga ana tjetër, ai përmban informacione shumë të rëndësishme për ata që thjesht duhet të punojnë me postën, por që nuk janë të aftë për të gjitha ndërlikimet e procesit të dërgimit të postës elektronike.

Pra, nëse doni të mbroni përdoruesit tuaj nga mesazhet e padëshiruara, ose anasjelltas, nëse dëshironi që dikush të mos mbrojë rastësisht përdoruesit nga letrat tuaja - mirëpritur nën cat.

Një shënim i vogël: artikulli u shkrua me një sy në ngritjen e një serveri postar postfiks, por në përgjithësi është më tepër teorik. Opsionet e përshkruara Postfix duhet të specifikohen në të përshtatshme *_kufizim opsionet e skedarit të konfigurimit, shikoni çdo udhëzues të konfigurimit të Postfix për detaje.

Pak për protokollin SMTP

E-mail ka shumë analogji me postën e zakonshme. Gjëja më e rëndësishme për ne tani është se të gjitha informacionet në "zarfin" elektronik janë vetëm dy adresa: marrësi dhe dërguesi, si dhe vula e postierit që ka dorëzuar zarfin.

Le të largohemi pak: imagjinoni që një person me pamje jashtëzakonisht të neveritshme të vijë tek ju dhe t'ju dorëzojë një pako të mbyllur fort me adresën e kthimit "Tryam nga Tilimilithryamdia". Guxoni të pranoni dhe të hapni? Nuk ka gjasa. Pra, e-mail-i gjithashtu mund të kontrollohet dhe filtrohet lehtësisht bazuar vetëm në informacionin e adresës, dhe hapësira për veprime të mundshme është shumë më e gjerë këtu.

Siç duhet të dini, posta në internet transferohet midis serverëve të postës duke përdorur protokollin SMTP. Çdo komunikim duke përdorur këtë protokoll fillon me tre tituj të detyrueshëm: PERSHENDETJE, POSTE NGA dhe RCPT TE. Domethënë, përpara se të fillojë të transmetojë ndonjë të dhënë, serveri fillimisht prezantohet (HELO), më pas raporton adresën e kthimit të dërguesit (MAIL FROM) dhe më pas adresën e marrësit (RCPT TO). Këta tre tituj janë nënshkrimi në zarfin elektronik, dhe pothuajse të gjitha mesazhet e padëshiruara mund të filtrohen vetëm në bazë të analizës së tyre. Shumica e përpjekjeve për të dërguar diçka në serverin tim nuk e kalojnë MAIL FROM, domethënë, mesazhet filtrohen përpara se të pranohen, gjë që redukton shumë ngarkesën. Dmth, në vend që të hap paketën nga Tryam dhe të gjej spore antraksi atje, unë e dërgoj menjëherë postierin në ferr.

Pra, çfarë duhet bërë për të shmangur marrjen e emaileve që njihen si spam? Le të shkojmë me radhë.

Pak për DNS

Në ditët e para të internetit, posta u dërgohej drejtpërdrejt hosteve të specifikuar në adresën e postës. Kjo është, për t'i dorëzuar një letër [email i mbrojtur] serveri i postës kërkoi adresën IP të domain.com dhe u përpoq të dërgonte një parcelë në IP-në e gjetur. Pastaj u shfaqën të dhënat MX, të cilat menjëherë zgjidhën shumicën e problemeve të një organizimi të tillë të ndërveprimit me postë. Megjithatë, disa programe ende mund të punojnë me regjistrimet A kur dërgojnë postë. Por ju me siguri keni të paktën një rekord MX për domenin tuaj, apo jo?

Të dhënat MX përmbajnë adresat e serverit, në të cilat duhet të dorëzohen letra për domenin e specifikuar. Sidoqoftë, për të luftuar spam-in, është shfaqur një teknologji që ju lejon të specifikoni në DNS edhe adresat e serverëve, Me të cilat mund të marrin letra nga domeni i specifikuar. Emri i saj është Korniza e Politikave të Dërguesit.

Unë nuk do të hyj në të gjitha ndërlikimet e teknologjisë në detaje, do të them vetëm se rekordi TXT

V=spf1 +mx-të gjitha

Vendosni gjithmonë një rekord SPF për domenin, dhe gjithashtu aktivizoni kontrollet SPF në serverët tuaj të postës. Unë rekomandoj ndalimin e rreptë të emaileve nga domeni juaj nga të gjithë hostet, përveç serverëve tuaj MX. Së bashku me kontrollin SPF në serverin tuaj, një cilësim i tillë do të ndërpresë menjëherë të gjitha letrat e dërguara nga hostet e palëve të treta në emër të përdoruesve të domenit tuaj në adresat e përdoruesve të domenit tuaj. Dhe pothuajse gjysma e një spam të tillë, sepse zakonisht serverët SMTP janë shumë të dobët të mbrojtur nga letrat nga domeni i tyre, dhe spammers e përdorin në mënyrë aktive këtë. SPF do t'ju shpëtojë një herë e mirë nga letrat drejtuar Vasya Pupkin, të shkruara nga Vasya Pupkin, sipas zarfit, por që vijnë nga një server në disa Nikaragua.

Google do t'ju tregojë se si të konfiguroni SPF në Postfix, ka shumë informacion dhe nuk mund të gaboni, kështu që ne nuk do të humbim kohë në detaje teknike.

Ka disa shënime jashtëzakonisht të rëndësishme në lidhje me DNS. Ju ndoshta e dini se të dhënat bazë DNS, të ashtuquajturat regjistrime A, përkthejnë një emër në një adresë IP. Përveç tyre, ka edhe regjistrime CNAME që caktojnë një pseudonim për një emër tashmë ekzistues. Janë këto dy lloje regjistrimesh që formojnë bazën e të gjithë sistemit të emrave të domenit.

Por pak përdorues e dinë se ka edhe regjistrime të kundërta që konvertojnë një IP në një emër domaini. Ata quhen PTR. Pra, ekzistojnë dy rregulla të pashkruara (në mënyrë rigoroze) që të gjithë i ndjekin ende:

• Për çdo rekord A duhet të ekzistojë pasqyrë Regjistrimi PTR, d.m.th., me emrin e hostit përmes DNS marrim IP, dhe me IP ne marrim të njëjtin emër pritës.
• Adresa në rekordin MX duhet të jetë gjithmonë emri(jo IP!) e hostit për të cilin ekziston një hyrje A. Kjo do të thotë, nuk mund të keni një IP ose një pseudonim (CNAME) në rekordin MX.

Nëse nuk plotësoni një nga këto kërkesa, përgatituni për faktin se të paktën një e katërta e postës nga domeni juaj do të njihet si e padëshiruar. Kjo është për shkak të një teze të thjeshtë: një dërgues i besueshëm gjithmonë vendos gjithçka duke ndjekur rregullat, përkatësisht, nëse rregullat nuk respektohen, atëherë dërguesit nuk duhet t'i besohet, që do të thotë se nuk duhet të pranoni as postë prej tij.

Epo, për të aktivizuar kontrollin PTR për veten tuaj, përdorni opsionin

Refuzo_unknown_client_hostname

Kërkon që IP-ja nga e cila është bërë lidhja të zgjidhet në një emër nëpërmjet PTR, dhe ky emër nga ana tjetër të kthehet në IP-në e dëshiruar.

Ekziston gjithashtu një kufizim më pak i rreptë i vendosur nga opsioni

Refuzo_unknown_reverse_client_hostname

Në këtë rast, serveri do të kontrollojë vetëm ekzistencën e një rekord PTR, por nuk do të kërkojë ekzistencën e një rekord përkatës A.

Duke kontrolluar përshëndetjen

Pra, dikush donte t'i dërgonte një letër serverit tuaj. Transmetimi fillon me një përshëndetje - titulli HELO. HELO duhet të përmbajë emrin plotësisht të kualifikuar të domenit (FQDN) të dërguesit, përkatësisht, nëse nuk është kështu, ju mund të refuzoni me siguri ta pranoni menjëherë. Postfix ofron dy opsione për këtë:

Refuzo_invalid_helo_hostname
reject_non_fqdn_helo_hostname

E para çaktivizon marrjen e mesazheve nga hostet që dërgojnë një përshëndetje me sintaksë të pasaktë, e dyta - nga hostet që dërgojnë një jo-FQDN në një kërkesë HELO.

Sidoqoftë, vetëm spammerët më budallenj (dhe produktet MS, por ata, siç e dini, ligjet nuk janë shkruar) transmetojnë FQDN, në fund të fundit, nuk është e vështirë të prezantoni veten si gmail.com. Prandaj, duhet t'i hedhim një vështrim më të afërt HELO. Për këtë, opsioni

Refuzo_unknown_helo_hostname

E cila ndalon marrjen e letrave nga serverët që duket se janë një adresë për të cilën nuk ka regjistrim A ose MX.

Dërguesi - a duhet t'i besohet atij?

Pra, serveri ju prezantoi me sukses, artikulli tjetër në program është adresa e dërguesit. Ju gjithashtu mund të nxirrni shumë informacione të dobishme prej tij. Dua të vërej menjëherë se adresa e dërguesit nuk duhet të jetë nga i njëjti domen si vetë serveri. Ky është një keqkuptim i zakonshëm, ndaj kini parasysh se nuk është kështu. Një server i postës mund të shërbejë lehtësisht në disa domene.

Sidoqoftë, nëse adresa e dërguesit përmban një domen që nuk ekziston fare, atëherë letra është e qartë se nuk ia vlen të pranohet. Dhe sigurisht nuk duhet të pranoni një letër në të cilën diçka tregohet si adresë kthimi që nuk është aspak adresë. Ekzistojnë dy mundësi për refuzimin e pranimit të letrave të tilla:

Refuzo_non_fqdn_sender
reject_unknown_sender_domain

E para është kontrollimi i adresës për drejtshkrim, e dyta është kontrollimi i ekzistencës së domenit.

Kjo është shumë mirë, por ka më shumë që mund të bëhet. Ju mund të kërkoni serverin që shërben adresën e caktuar të dërguesit për të parë nëse ka një përdorues me atë adresë në të. Në të vërtetë, duket se është një ide e mirë të sigurohemi që adresa e kthimit ekziston vërtet, përndryshe mund të marrim një letër nga një fantazmë kalimtare për të cilën askush nuk ka dëgjuar ndonjëherë.

Teknikisht, kjo zbatohet shumë thjesht: serveri ynë hap një seancë SMTP kundër, duke u përpjekur të dërgojë një letër në adresën e dërguesit. Nëse është e mundur të kalohet me sukses faza e dërgimit të RCPT TO me këtë adresë, d.m.th. nëse serveri marrës papritmas nuk deklaron se kutia postare e specifikuar nuk është në të, atëherë konsiderohet se adresa e kthimit e dërguar tek ne ekziston. Natyrisht, asnjë e dhënë (d.m.th., një letër) nuk transmetohet gjatë kontrollit, seanca ndërpritet pas RCPT TO.

Opsioni

Refuzo_dërguesin e paverifikuar

Nga sa më sipër rezulton se për çdo adresë nga e cila dërgoni postë nga domeni juaj, duhet të ketë një kuti postare në serverin tuaj. Përndryshe, letrat tuaja nuk do të kalojnë kontrollin e adresës së kthimit nga ana e marrësit dhe, në përputhje me rrethanat, nuk do të dorëzohen në destinacionin e tyre. Kjo është e vërtetë për të gjitha llojet e postimeve dhe llojet e tjera të komunikimit të njëanshëm që nuk kërkojnë përgjigje. Krijoni gjithmonë kuti postare për të gjitha adresat nga të cilat dërgoni postë. Nëse nuk dëshironi të merrni përgjigje për një adresë, atëherë thjesht dërgoni një postë tek ajo në /dev/null, por nuk mund t'i pranoni këto emaile. i detyruar.

A ekziston marrësi?

Kështu arritëm te kreu i fundit i zarfit - te marrësi. Gjithçka është e thjeshtë këtu: së pari, do të ishte mirë të kontrollonim nëse informacioni që na transmetohet është përgjithësisht një adresë emaili. Për këtë direktiva

Refuzo_non_fqdn_marrësin

Përveç kësaj, ne nuk do të donim të pranonim postë në adresat për të cilat nuk kemi kuti postare. Për të konfiguruar këtë sjellje, së pari duhet të krijoni një listë të kutive postare të shërbyera, më pas t'i tregoni Postfix-it për të përmes një prej *_hartat_marrëse parametrat e skedarit të konfigurimit, mirë, atëherë ose përdorni parametrin e skedarit të konfigurimit

smtpd_reject_unlisted_recipient = po

Ose me një opsion çaktivizimi që ka të njëjtin efekt:

Refuzo_marrësin_të_palistuar

Në çdo rast, Postfix do të ndalojë pranimin e emaileve. për domenet e pranuara nëse nuk ekziston asnjë kuti postare për marrësin. Megjithatë, ky kufizim nuk do të ndikojë në përcjelljen e postës në adresat që nuk janë në domenet e pranuara.

Dhe së fundi, në përgjithësi mund të çaktivizoni përcjelljen e hapur të letrave përmes Postfix-it tuaj, duke lënë vetëm mundësinë për të marrë letra në adresat e njohura. Për këtë qëllim, opsioni

Refuzo_destinacionin_unauth

Ai parandalon dërgimin e emaileve për të gjithë përdoruesit e paregjistruar (po, do t'ju duhet të konfiguroni autorizimin SMTP). Përdoreni gjithmonë këtë opsion! Përndryshe, do të përfundoni shpejt në të gjitha llojet e DNSBL-ve.

Si një nëntotal

Kjo është mënyra se si mund të filtroni një sasi të madhe të spamit bazuar në analizën e tre kokave të zarfeve. Megjithatë, spammers janë dinakë, kështu që kjo ende nuk është e mjaftueshme.

Listimi gri

Ndonjëherë serverët e postës janë të mbingarkuar dhe nuk mund ta pranojnë letrën. Si mendoni se ata u përgjigjen kërkesave të ardhura në këtë rast? Mjaft e çuditshme, ata përgjigjen - serveri përkohësisht i padisponueshëm, ju lutemi provoni përsëri më vonë. Asnjë dërgues i vetëm normal nuk do të mendojë në këtë rast se një letër nuk mund të dorëzohet me të gjitha pasojat që pasojnë. Përkundrazi, dërguesi do të përpiqet ta dorëzojë letrën më vonë, duke e vendosur atë në radhë për dërgim. Ky fakt mund (dhe pa dyshim që duhet!) të përdoret në mënyrë shumë efektive: në çdo përpjekje të parë për t'u lidhur nga një host i panjohur, serveri ynë do të dërgojë një mesazh gabimi të përkohshëm dhe do ta lërë mesazhin të kalojë vetëm herën e dytë. Kjo do të filtrojë pothuajse të gjithë mesazhet e padëshiruara të mbetura menjëherë, pasi serverët e postës së padëshiruar pothuajse kurrë nuk bëjnë më shumë se një përpjekje për të dërguar një letër (përndryshe ata thjesht do të "binin" nga tejmbushja e radhës). Kjo teknologji quhet Greylisting, dhe është thjesht e nevojshme të përdoret në realitetet moderne.

Disavantazhi i aplikacionit është një vonesë e vogël (zakonisht jo më shumë se gjysmë ore) në dërgimin e letrave në të parën lidhje nga një host i panjohur. Kjo do të thotë, nëse serveri i panjohur ende për postfiksin tonë dëshiron të dërgojë një letër, atëherë në përpjekjen e parë të lidhjes, atij i dërgohet një gabim në lidhje me mosdisponueshmërinë e përkohshme. Nëse serveri përpiqet të lidhet përsëri, atëherë letra pranohet dhe serveri futet në nyje të besueshme, dhe letrat e mëtejshme prej tij merren pa vonesë.

Unë sugjeroj gjithashtu të lexoni për vendosjen e një liste gri në Postfix në Google, është e lehtë dhe nuk mund të gaboni.

Listat e bllokimit, ose çfarë të mos bëni

Disa administratorë të postës mbështeten në të ashtuquajturat DNSBL (RBL) për të filtruar postën e padëshiruar - listat e zeza të hosteve që shihen duke dërguar mesazhe të padëshiruara. Pra ja ku është kurrë mos shtoni nuk ka kontrolle DNSBL te serverët tuaj të postës. Ka dy arsye për këtë: e para, dhe më e rëndësishmja, qëndron në pjesën e dytë të fjalisë së parë të këtij seksioni. Pritësit futen në këto lista krejtësisht rastësisht dhe nuk ka garanci që një host normal nuk do të arrijë atje (në të cilin, ndoshta, në një moment u vendos një virus që dërgon spam, por tani virusi tashmë është shëruar, ose më lehtë dhe shumë më reale - një IP e jashtme për një rrjet të madh në të cilin filloi një spammer). Arsyeja e dytë është më banale: mekanizmi i filtrimit i propozuar më sipër është shumë më efikas se çdo DNSBL dhe nuk mbështetet në të dhëna të paverifikuara nga palë të treta.

Përmbys, ose shikoni nga ana tjetër e barrikadave

Mësuam se si të filtrojmë postën e padëshiruar, por tani do të përpiqem të bashkoj të gjitha informacionet mbi temën se çfarë duhet bërë për të jo futeni në mesazhe të padëshiruara.

Për administratorët e serverit të postës:

• Gjithmonë bëni që regjistrimet MX t'i referohen regjistrimeve A.
• Regjistri A për serverin e postës duhet të ketë gjithmonë një rekord PTR të pasqyruar.
• Pritësi në kokën HELO duhet të ketë një rekord A ose MX.
• Gjithmonë krijoni regjistrime SPF (po, po, kjo thjesht nuk është e nevojshme, por thjesht një praktikë e mirë).
• Për të gjitha postat e dërguara nga një domen i pranuar, duhet të ekzistojë një kuti adresash kthimi dhe të pranojë postën.

Për ata që dërgojnë postë (nga programet, faqet e internetit, etj.):

• Gjithmonë dërgoni postë vetëm me një adresë kthimi ekzistuese.
• Asnjëherë mos dërgoni postë nga një domen që nuk e kontrolloni pa kontrolluar rregullat SPF për të. Për shembull, gmail.com aktualisht ju lejon të dërgoni letra në emër të tij në çdo server, por yandex.ru dhe mail.ru raportojnë nëpërmjet SPF se dërgimi në emër të tyre nga serverë të palëve të treta duhet të tërheqë vëmendjen, gjë që interpretohet nga smart filtrat e spamit si një rritje në rezultatin e postës së padëshiruar për një email të caktuar.
• Asnjëherë mos dërgoni postë përmes serverëve SMTP të konfiguruar gabimisht. Kontrolloni serverin për morra sipas listës së mësipërme - një çështje prej 5 minutash, programi do t'ju ndihmojë gërmoj ose nslookup.

Përmbledhje

Sigurisht, cilësimet e propozuara nuk i filtrojnë të gjitha mesazhet e padëshiruara. Prandaj, është mjaft e mundur që do t'ju duhet të përdorni gjithashtu një filtër konteksti që do të analizojë përmbajtjen e emaileve, për shembull,

Kur dërgoni një mesazh email ndërsa jeni larg shtëpisë duke përdorur llogarinë tuaj të postës së shtëpisë, mesazhi mund të kthehet me një gabim 550, 553 ose transmetim. E njëjta gjë mund të ndodhë kur jeni jashtë zyrës duke u përpjekur të dërgoni një email duke përdorur llogarinë tuaj të postës elektronike të punës.

Përshkrim

Transmetimi ndodh kur një mesazh email dërgohet në një adresë emaili, domeni i së cilës (emri pas simbolit @, si p.sh. adatum.com) nuk përpunohet nga protokolli SMTP ose serveri i postës dalëse që merr kërkesën për dërgimin e mesazhit nga dërguesi. Serveri SMTP duhet të lidhet me një server tjetër SMTP për të transmetuar mesazhin.

Nëse ndodh një gabim transmetimi gjatë dërgimit të një mesazhi postar, serveri juaj SMTP (posta dalëse) mund të kthejë mesazhin tuaj së bashku me një mesazh gabimi të tillë si:

Tema:<тест>, Llogaria:<тест>, server: , protokolli: SMTP, përgjigja e serverit: "550 Relay refuzohet", porta: 25, e sigurt (SSL): asnjë, gabim serveri: 550, numri i gabimit: 0x800CCC79".

"Mesazhi nuk mund të dërgohej sepse serveri refuzoi të pranonte adresën e njërit prej marrësve. Adresa ishte e specifikuar në letër:<адрес эл. почты>. Tema:<тест>, Llogaria:<тест>, server: , protokolli: SMTP, përgjigja e serverit: "553 për fat të keq, ky domen nuk është në listën time të hosteve të lejuar (#5.7.1)", porta: 25, siguria (SSL): jo, gabimi i serverit: 553, numri i gabimit: 0x800CCC79" .

Teksti i saktë i mesazhit të gabimit do të varet nga ISP-ja juaj. Disa ofrues nuk kthejnë një mesazh gabimi kur identifikojnë mesazhet dalëse si të padëshiruara. Në këto raste, duket sikur mesazhi juaj po dërgohet normalisht (në Outlook, ai qëndron në dalëse dhe shfaqet në dosje Dërguar), por nuk i dorëzohet marrësit.

Mesazhi juaj u refuzua sepse serveri SMTP (posta dalëse) nuk ju njohu si përdorues të autorizuar.

SMTP është një protokoll (standardet e përdorura nga kompjuterët për të komunikuar) që përdoret nga shumica e serverëve të postës elektronike për të dërguar mesazhe në internet. Nëse jeni duke përdorur një program emaili (siç është Outlook) që ju lejon të ruani mesazhe në kompjuterin tuaj, do t'ju duhet akses në një server SMTP për të dërguar mesazhe.

Shënim: Sistemet e postës elektronike të bazuara në ueb (si Windows Live Mail ose Yahoo! Mail) funksionojnë ndryshe dhe nuk mbulohen në këtë artikull.

Reletë e padëshiruar dhe të hapura

Mesazhet reklamuese të pakërkuara njihen si spam ose spam. Vëllimi i mesazheve të padëshiruara vazhdon të rritet sepse nuk kushton pothuajse asgjë për t'i dërguar ato tek ata që e dërgojnë. Në fakt, dërguesi as nuk duhet të dërgojë postë të padëshiruar përmes serverit SMTP (postë dalëse) të ISP-së së tij.

Gjatë krijimit të strukturës bazë të internetit, askush nuk parashikoi pasojat e mundësisë për të dërguar miliona mesazhe të pakërkuara për një tarifë të papërfillshme. Nëpërmjet aftësisë transmetuese të serverëve SMTP, dërguesit e postës së padëshiruar maskojnë burimin e vërtetë të spamit duke e kaluar atë nëpër serverë të palëve të treta që lejojnë transmetime të tilla të hapura. Si rezultat, spam duket se vjen nga një sajt që transmeton mesazhin dhe fsheh identitetin e dërguesit të vërtetë.

Deri kohët e fundit, shumica e serverëve të postës SMTP bazoheshin në një sistem të hapur të besuar. Në një sistem të tillë, çdokush nga kudo mund të dërgojë një mesazh poste në një server SMTP, dhe serveri duhet ta pranojë atë dhe t'ia përcjellë atë marrësit ose një serveri tjetër të postës që pret kutinë postare të marrësit. Me këtë stafetë të hapur, nuk ka kufizime që pengojnë dikë të dërgojë postë përmes një serveri SMTP.

Kufizimet e ISP në transmetimin e postës

Ndërsa vëllimet e postës së padëshiruar janë rritur, administratorët e rrjetit (njerëzit përgjegjës për menaxhimin e serverëve të ISP-së) kanë filluar të vendosin kufizime në serverët e tyre të postës SMTP. Këto kufizime i pengojnë të gjithë të përdorin serverin e postës. Imagjinoni që ka një telefon në hollin e organizatës suaj që është i aksesueshëm për të gjithë, përfshirë ata që nuk janë punonjës të organizatës. Tani vetëm punonjësit lejohen të përdorin telefonin.

Sot përdoren disa lloje kufizimesh.

Kërkon vërtetim SMTP. Ashtu siç përdorni një emër përdoruesi dhe fjalëkalim për të hyrë në një server POP3 (postë hyrëse) dhe mesazhet tuaja të postës elektronike, duhet të vendosni një emër përdoruesi dhe fjalëkalim për të dërguar mesazhe emaili përmes një serveri SMTP. Ky është zakonisht i njëjti emër përdoruesi dhe fjalëkalimi si për serverin POP3, por mund të jetë unik.

Së pari duhet të lidheni me serverin POP3 (postë hyrëse) të ISP-së tuaj. Për të marrë mesazhet tuaja të reja të postës, zakonisht lidheni me një server POP3 (inbox). Ju duhet të vendosni një emër përdoruesi dhe fjalëkalim për të hyrë në kutinë tuaj postare. Administratori i rrjetit mund ta konfigurojë serverin në mënyrë që nëse së pari lidheni me një server POP3 në hyrje dhe vërtetoni, ai do të miratojë të gjitha kërkesat për të dërguar mesazhe emaili përmes serverit SMTP në dalje, i cili përndryshe do të kufizohej.

Kërkon një lidhje nga një vendndodhje e autorizuar në rrjet. Nëse lidheni me një ISP në shtëpi me një linjë telefonike, kabllor ose modem DSL, lidhja shkon drejtpërdrejt në rrjetin e ISP-së. Ju jeni të besueshëm sepse keni një llogari me një emër përdoruesi dhe fjalëkalim të ofruar nga ISP-ja juaj. Ju si klient ju lejohet të përdorni një server SMTP për të dërguar mesazhe me email.

Kërkon një lidhje nga një adresë IP specifike ose një gamë adresash IP. ISP-ja juaj mund të lejojë qasje në serverin SMTP për njerëzit që nuk janë të lidhur drejtpërdrejt me rrjetin. Për shembull, mund të jetë një përdorues i largët në zyrë. Problemi kryesor është se adresat IP dinamike përdoren në shumë vende. Sidoqoftë, nuk mund të jeni i sigurt se keni të njëjtën adresë IP sa herë që lidheni. Disa organizata mund të kenë një bllok ose gamë adresash IP të rezervuara. ISP mund t'i konsiderojë ata që lidhen nga këto adresa IP si përdorues të verifikuar. Ai mund të japë më shumë informacion.

Ka shumë skenarë të mundshëm rele. Më poshtë janë situatat më të zakonshme. Ndoshta njëri prej tyre është i ngjashëm me tuajin.

Situata	A është një stafetë?
Jeni në shtëpi dhe keni një llogari ISP që mbaron në @proseware.com me të cilën jeni lidhur me telefon, kabllor ose modem DSL. Ju po i dërgoni një mesazh një personi tjetër, adresa e emailit të të cilit gjithashtu përfundon në @proseware.com.
Njësoj si në situatën e parë, përveç se po i dërgoni një mesazh një personi, adresa e emailit të të cilit përfundon në @adatum.com.	Po, por nuk është i bllokuar. Ju lidheni drejtpërdrejt me një ISP dhe në këtë mënyrë fitoni autoritetin për të dërguar postë përmes serverit të tij SMTP (postë dalëse) në çdo adresë, pavarësisht nga vendndodhja e kutisë postare të marrësit.
A je në punë. Adresa juaj e emailit të punës përfundon në @thephone-company.com dhe ju keni një llogari të ISP-së në shtëpi që përfundon në @proseware.com dhe lidhet me të nëpërmjet telefonit telefonik, kabllor ose modemit DSL. Në Outlook, ju keni të njëjtat cilësime të serverit SMTP si në shtëpi. Ju po i dërgoni një mesazh një personi, adresa e emailit të të cilit përfundon gjithashtu në @proseware.com.	Nr. Posta juaj përpunohet në mënyrën e zakonshme.
Keni qëndruar në një hotel ose keni përdorur një terminal interneti në aeroport që ofron akses në internet. Ju keni një llogari të ISP-së në shtëpi që mbaron në @proseware.com me të cilën lidheni me telefon, kabllor ose modem DSL. Në Outlook, ju keni të njëjtat cilësime të serverit SMTP si në shtëpi. Ju po i dërgoni një mesazh një personi tjetër, adresa e emailit të të cilit gjithashtu përfundon në @proseware.com.	Nr. Posta juaj përpunohet në mënyrën e zakonshme.
Njësoj si më sipër, përveçse po i dërgoni një mesazh një personi, adresa e emailit të të cilit përfundon në @adatum.com.	Po, dhe ky mesazh mund të bllokohet si postë e transmetuar. Po përpiqeni të përdorni serverin SMTP (postë dalëse) të ISP-së tuaj në shtëpi, megjithëse nuk jeni i lidhur me rrjetin e tyre. Serveri SMTP nuk mund t'ju vërtetojë si pajtimtar i autorizuar i ISP-së. Përveç kësaj, po i kërkoni serverit SMTP të pranojë mesazhin dhe të lidhet me një server tjetër SMTP për ta dërguar atë në kutinë postare të marrësit.

Zgjidhjet

Nëse situata juaj konsiderohet një stafetë, duhet ta dërgoni mesazhin përmes serverit me të cilin jeni duke u lidhur aktualisht. Kjo do të thotë, nëse jeni në punë ose larg shtëpisë dhe nuk përdorni ISP-në tuaj për t'u lidhur me internetin, por dëshironi të dërgoni një mesazh nga llogaria juaj e shtëpisë të ofruar nga ai ISP, duhet të ndryshoni cilësimet e llogarisë tuaj të postës për të treguar atë server SMTP , të cilin e përdorni aty ku jeni (për shembull, një server SMTP që funksionon). Shihni artikullin për udhëzime hap pas hapi.

Nëse kjo nuk funksionon, ose nëse preferoni të përdorni një llogari në shtëpi, do t'ju duhet të kontaktoni ISP-në tuaj dhe të pyesni nëse opsionet e përshkruara më parë janë të disponueshme për ju. Lidhur me dy kufizimet e para (kërkon vërtetimin SMTP dhe kërkon që së pari të lidheni me serverin POP3 në hyrje të ISP-së), mund të ndryshoni Cilësimet e llogarisë në Outlook. Shikoni Ndrysho cilësimet e llogarisë tuaj të emailit për udhëzime.

Mesazhet nuk janë dërguar ende?

Ju keni ndryshuar cilësimet SMTP në Outlook ose keni gjetur një cilësim që do t'ju lejojë të dërgoni mesazhe me email. Por ju ende nuk mund të dërgoni postë dhe të merrni një mesazh gabimi.

Ju mund të keni bërë gjithçka siç duhet, por administratorët e rrjetit po përdorin një veçori tjetër sigurie për të parandaluar mashtrimin e identitetit. Mashtrimi i identitetit është thjesht një mënyrë për të dërguar një email ku fshihni se kush jeni.

Në Outlook, si në shumicën e programeve të postës elektronike, mund të specifikoni një "emër të shfaqur" dhe një adresë emaili kthimi që shfaqet kur mesazhit tuaj i përgjigjet. Në postë të padëshiruar, këto fusha pothuajse gjithmonë përmbajnë informacion të rremë. A besoni vërtet se mesazhet e pasurimit të shpejtë erdhën nga një supermodele apo një lider botëror?

Për të parandaluar mashtrimin e identitetit, disa ISP kufizojnë aftësinë për të futur informacion të rremë në fushën e adresës në përgjigje. Për shembull, nëse emri i domenit të ISP-së suaj përfundon në proseware.com, ISP mund t'ju ndalojë të jepni një adresë kthimi [email i mbrojtur]. Ky kufizim nuk përdoret aq gjerësisht sa përshkruhet më parë, por mund të zbatohet për të gjithë përdoruesit, pavarësisht nga vendndodhja dhe mënyra e lidhjes së tyre. Në këtë rast, nuk ka alternativë. Nëse administratori i serverit përdor këtë metodë, duhet të specifikoni domenin që korrespondon me lidhjen tuaj aktuale në adresën e kthimit.