If-Koubou

Kāpēc starpposma SMTP serveris ir nepieciešams, lai nosūtītu pastu?

Kāpēc starpposma SMTP serveris ir nepieciešams, lai nosūtītu pastu? (Kā)

Kā persona uzzina vairāk par to, kā darbojas pasta klienti, SMTP serveri un visa tiešsaistes pasta sistēma, viņiem var būt interesanti, kāpēc SMTP serveris ir pat nepieciešams. Ņemot to vērā, šodienas SuperUser Q & A ziņai ir atbildes uz ziņkārīgo lasītāja jautājumiem.

Šodienas jautājumu un atbilžu sesija mums priecājas par SuperUser - Stack Exchange dalību, kas ir kopienas vadīta Q & A tīmekļa vietņu grupa.

Foto pieklājīgi no David Schroeder (Flickr).

Jautājums

SuperUser lasītājs Tobia vēlas uzzināt, kāpēc starpposma SMTP serveris ir nepieciešams, lai nosūtītu pastu:

Kāpēc man ir nepieciešams SMTP serveris, lai nosūtītu pastu? Kāpēc mans pasta klients (Outlook vai Thunderbird) nespēj nosūtīt ziņojumus tieši saņēmēja SMTP domēnā?

Piemēram, ja man jānosūta e-pasts uz [email protected] ar savu Gmail kontu, es to nosūta uz smtp.gmail.com serveris; tad šis serveris nosūta manu ziņojumu MX serverim example.com.

Kāpēc SMTP serveri nepieciešams, lai nosūtītu pastu?

Atbilde

SuperUser ieguldītājs davidgo mums ir atbilde:

Tehniski ir iespējams nosūtīt e-pastu tieši no saņēmēja SMTP servera no datora.

Apskatot to no vēsturiskā pamata, ja attālais SMTP serveris ir uz leju, jūs vēlaties, lai sistēma automātiski apstrādātu to un turpinātu atkārtot, tādēļ jums ir SMTP serveris. Tāpat arī vecajās dienās visi pasta serveri tika pieslēgti nepārtraukti (tālsatiksmes saites bija dārgas), tāpēc pasta tika rindā un nosūtīta, kad tika izveidota saite.

Pārejot uz vietnēm, kur interneta pakalpojumi ir lēti, joprojām ir lietderīgi izveidot mehānismus, lai atkārtotu pasta sūtīšanu, ja serveris nav pieejams. Tas nav ideāli, ja šī funkcija tiek ierakstīta MUA (Mail lietotāja aģenta / gala lietotāja pasta programmā). Šīs funkcijas ietilpst MTA (pasta serverī / SMTP serverī).

Bet tas kļūst sliktāks - surogātpasta izplatītāji. Lielākā daļa pasta (vairāk nekā 80 procenti) ir surogātpasts. Pasta pakalpojumu sniedzēji dara visu iespējamo, lai mazinātu šo problēmu, un daudzi paņēmieni ļauj izdarīt pieņēmumus par pasta piegādes veidu. Svarīgi apsvērumi ir šādi:

1. Greylisting: Daži pakalpojumu sniedzēji automātiski pārtrauc pasta savienojumu, ja sūtītājs un saņēmējs iepriekš nav sazinājušies un sagaidīt, ka viņi mēģinās to izdarīt otrreiz. Surogātpasta izplatītāji bieži vien vēlreiz neizmēģina, kamēr SMTP serverim vienmēr vajadzētu. Tas samazina surogātpasta apjomu par apmēram 80 procentiem, bet tas sucks to ir jādara, lai gan.

2. Reputācija: Ir daudz lielāka iespēja, ka kāds, kurš nosūtīs pastu caur cienījamu, pazīstamu SMTP serveri, ir legit salīdzinājumā ar "fly-by-night server". Lai iegūtu reputāciju, pakalpojumu sniedzēji veic vairākas lietas:

  • Bloķēt dinamiskās / klienta adreses (nevis 100 procenti, bet ir izveidoti lieli interneta gabali).
  • Pārbaudiet, vai reversais DNS atbilst priekšējam DNS. Nav ļoti grūti izdarīt, bet tas parāda zināmu atbildības līmeni un zināšanas par labāko praksi (kaut ko daudz klienta adreses bloki nav).
  • Pārbaudiet reputāciju. Sazinoties ar citiem SMTP serveriem, daudzi pakalpojumu sniedzēji sekmē surogātpasta apjomu un nosūtīto pasta apjomu. Tie var samazināt surogātpasta apjomu, ierobežojot savienojumus un ievērojot šos parametrus. Ir daudz veidu, kā tas tiek darīts, ne visi no tiem ir acīmredzami, bet tiem ir nepieciešams zināms sūtītājs.
  • SPF un DKIM. Šie mehānismi piesaista DNS resursus uz domēna vārdu, lai padarītu vafeļu sūtīšanu grūtāku, un tas būtu grūti, bet ne vienmēr ir neiespējami izvietot, ja pasta programma (MUA) ir atbildīga par izejošo pastu.

Iespējams, ir citas nelielas bažas, taču tās būtu galvenās.

Vai kaut ko pievienot paskaidrojumam? Skatieties komentāros. Vēlaties lasīt citas atbildes no citiem tehnoloģiju savvy Stack Exchange lietotājiem? Šeit skatiet pilnu diskusiju pavedienu.