Poštni strežnik in nedosegljivost

Povsem informativno. Recimo, da ima nekdo doma postavljen poštni strežnik. Kaj se zgodi, če je strežnik nekaj časa nedostopen zaradi takega ali drugačnega razloga, nekdo pa v tem času pošlje mail?

Če se samo poštni strežnik ne odziva, bo pošiljateljev strežnik poskusil sporočilo ponovno poslati kasneje. Odvisno od nastavitev, večina strežnikov poskuša sporočilo pošiljati pet dni. Pošiljatelj običajno že po štirih urah dobi opozorilo, da pošiljanje zaenkrat ni bilo uspešno, na koncu pa še obvestilo, da je sporočilo dokončno zavrnjeno, če pride do tega.

Če pa DNS zapis za domeno prejemnika neha obstajati (se rado zgodi ko recimo dol padeta DNS in poštni strežnik hkrati, sekundarnega DNS pa ni), bo sporočilo takoj zavrnjeno in pošiljatelj takoj prejme tudi obvestilo o tem.

Še ena varianta je - da imaš providerjev mail server kot sekundarnega definiranega v DNS.

V tem primeru se pošta namenjena tvojemu strežniku ob nedostavljivosti pošlje na strežnik od tvojega providerja. Ko je tvoj strežnik spet online, pa se sporočila prenesejo s providerjevega na tvoj strežnik.

Edino ne vem (predolgo že, ko sem si to nastavljal), ali se moraš za sekundarca prej dogovoriti s providerjem, ali gre to avtomatično, čim pravi zapis vpišeš v svoj DNS MX zapis.

Kako naj ti preko backup MX-a prepošljejo virus/trojanca, katerega ti direktno nebi mogli poslati?

To razlago pa bi res rad slišal....

Misliš mogoče zato, ker ti greylisting v tem primeru ne bo deloval?
Tega bi jaz takointako prepovedal in bannal vse MX-e, ki ga uporabljajo.

flbroker je 26. sep 2016 ob 11:51 izjavil:

bluefish je 23. sep 2016 ob 17:26 izjavil:

Povsem informativno. Recimo, da ima nekdo doma postavljen poštni strežnik. Kaj se zgodi, če je strežnik nekaj časa nedostopen zaradi takega ali drugačnega razloga, nekdo pa v tem času pošlje mail?

Dodaj se kak MX record z nizjo prioriteto (visja stevilka) recimo Gmail da imas backup v primeru da je tvoj mail streznik nedosegljiv, lahko posiljatelj se vedno poslje prvemu dosegljivemu.

To pa nisem vedel - kaj res lahko googlov strežnik daš za sekundarca?
Preverjeno? Deluje za VSE domene?

flbroker> Nima veze s streznikom.

Noben pravilno nastavljen SMTP strežnik ne sprejema prometa za naslovnike z neznanih domen.

flbroker> Gmail podpira dual delivery.

Kaj si pa ti predstavljaš pod "dual delivery"?

Googlovi SMTP strežniki (pa tudi noben drug pravilno nastavljen SMTP strežnik) definitivno ne bodo sprejeli sporočil, če ne poznajo naslovnika.

Kar pravimo je to, da ni dovolj, da nek SMTP strežnik z MX zapisom v svoji domeni obtožiš, da sprejema pošto zanjo. Tudi SMTP strežnik se mora s tem strinjat, sicer dostava ne deluje.

Dual delivery je na voljo pri Googlu samo moras imeti Google Apps, ne vidim v cem je problem.

Domeno dodas h Google skozi Google Apps, ampak administracija domene se vedno ostane tam kjer je. Google samo isce svoj MX record, nic drugega. Domeno se vedno imas pripeto k hostingu.

Ne razumem @jype zakaj omenjas nepravilno nastavljene streznike. Lahko imas vec zakupljenih hostingov z ISTO domeno in postnim predalom. Tam kjer upravljas DNS nastavitve pa nastavis MX records za vsak od teh hostingov. Kje je problem? To je cist navadni in najbolj enostavni MX backup sistem ki ga vec ali manj vsi uporabljajo.

No dobro, ker tako uporno ponavljas isto bom pa ti zdaj _dokazal_ da nimas prav.

***
*** 1.Domena je registrirana v tujini ***
***

$ whois lightspeedahead23.co.uk | grep -A2 servers
Name servers:
ns0.lcn.com
ns1.lcn.com

$ dig A lightspeedahead23.co.uk +short
31.28.93.58

***
*** Dodal sem jo tudi k Zabcu v Sloveniji in nastavil MX records pri OBEH hostingih
***

$ dig MX lightspeedahead23.co.uk +short
0 mail.lightspeedahead23.co.uk.
10 mx1.lcn.com.
10 mx0.lcn.com.

$ host mail.lightspeedahead23.co.uk
mail.lightspeedahead23.co.uk has address 185.29.16.50

***
*** Ustvaril test@lightspeedahead23.co.uk pri obeh hostingih ter poslal mail
***

1.Kot vidis je bil mail uspesno sprejet s strani Zabca 185.29.16.50 (in ga tudi imam v Inboxu):

root@intmail:/var/log/exim4# grep lightspeedahead23.co.uk mainlog-20160926
2016-09-26 15:44:05 1boX8W-00051s-Tl => test@lightspeedahead23.co.uk R=lookuphost T=remote_smtp H=mx0.lcn.com [94.126.47.85] X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128
2016-09-26 16:03:24 1boXQZ-0005TL-4Y => test@lightspeedahead23.co.uk R=lookuphost T=remote_smtp H=mail.lightspeedahead23.co.uk [185.29.16.50] X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128

2.Zdaj pa recimo da je postni streznik pri Zabcu nedosegljiv (zamenjal sem IP ki je trenutno offline da simuliramo tole):

$ host mail.lightspeedahead23.co.uk
mail.lightspeedahead23.co.uk has address 31.28.93.20

$ ping 31.28.93.20
PING 31.28.93.20 (31.28.93.20) 56(84) bytes of data.

3.In posljem mail se enkrat na test@lightspeedahead23.co.uk:

root@intmail:/var/log/exim4# grep lightspeedahead23.co.uk mainlog-20160926
2016-09-26 16:09:40 1boXXF-0005dX-62 mail.lightspeedahead23.co.uk [31.28.93.20] No route to host
2016-09-26 16:09:40 1boXXF-0005dX-62 => test@lightspeedahead23.co.uk R=lookuphost T=remote_smtp H=mx1.lcn.com [94.126.47.84] X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128

Kot vidis posiljatej zazna prvi MX da je nedosegljiv in ga poslje takoj drugemu na lestvici. In tukaj je dokaz da je mail sprejet v Inbox:

root@log2:/var/log/system/2016-09-26$ grep 1boXXI-0006GS-Hz mail.log 
Sep 26 16:09:40 10.1.4.9 exim[24084]: 2016-09-26 16:09:40 1boXXI-0006GS-Hz <= IZBRISANO@POSILJATELJ.com H=(mailguard-scan8.mailguard.com) [94.126.47.84] P=esmtps X=TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256 S=2332 id=57E939B8.6080303@lcn.com T="test2"
Sep 26 16:09:40 10.1.4.9 exim[24089]: 2016-09-26 16:09:40 1boXXI-0006GS-Hz => test <test@lightspeedahead23.co.uk> R=customer_domain T=customer_delivery
Sep 26 16:09:40 10.1.4.9 exim[24089]: 2016-09-26 16:09:40 1boXXI-0006GS-Hz Completed

Tako da prosim ne govorit nekaj da tole ne deluje ko pa je cisto enostavna zadeva ki jo marsikdo uporablja. Hvala.

O moj bog!!!, prosim vas ljudje ne vec pisat, zgoraj imas loge prilepljenje pa govoris o round robin, a ti sploh ves kaj je round robin?

Oglasi se samo ne govorit nekaj v kar se ne razumes. Pa nocem bit nesramen ali zloben ampak dosti nekih stvari se omenja krneki. DNS ti ni najbolj jasen, pa round robin tudi ne (ki tukaj nima nobene veze), jype-ju pa ocitno ni jasen DNS (MX priority) ker skoz ponavlja da to ni mozno. Zgoraj sem simuliral OP-ov problem in vam dokazal z logi kako MX backup/secondary deluje pa spet pises nekaj kontra.

Dobro, prosim ce si preberes kaj je MX Priority.

Ko si to preberes beri dalje tukaj. Ce imas dva mail streznika Exim1 and Exim2, vsakega na drugem koncu sveta, in na obeh ustvaris mailbox test@domena.com kateremu pripada prostor na strezniku recimo /mail/domena.com/test/Maildir. Torej imas dva identicna mailboxa na dveh razlicnih streznikih. Exim (ali karkoli drugega) torej ima podatek kdo je test@domena.com in kjer na strezniku se nahaja.

Ti pa imas domena.com pri GoDaddy in kot MX dolocis Exim1 streznik. Tam ti bo sla posta. Ce hoces spremenit posto, potem MX spremenis iz Exim1 v Exim2 in posta bo sla na drugi streznik zdaj. Potem pa se odlocis da zadevo automatiziras in dolocis oba streznika h domeni. Exim1 in Exim2. Oba, ja pa kako je to mozno? Enemu dolocis visjo prioriteto, drugemu pa manjso. In vse dokler bo tvoj streznik z visjo prioritet dosegljiv bo posta sla k njemu. Ce pa ze zgodi da ta vec ne bo dosegljiv pa bo sla naslednjemu.

A je zdaj bolj jasno? Res ne razumem zakaj imate nekateri tezave z razumevanjem ene cisto banalne stvari. Skozi nase mail streznike gre v povprecju 3.7mil sporocil dnevno in verjemi da sem se s tem ze srecal in da ne govorim nekaj brezveze, pa se zgoraj si prosim enkrat loge preglej. Upam da sem ti kaj bolj pojasnil.

Kakšne so pa recimo konkretne opcije za sekundarni MX, poleg omenjenega Googla?

A nima Telekom neko tako stvar (mailhub)?
Vsaj enkrat mi je eden od tehnikov to predlagal.

b3D_950 je 26. sep 2016 ob 18:19 izjavil:

A nima Telekom neko tako stvar (mailhub)?
Vsaj enkrat mi je eden od tehnikov to predlagal.

Verjetno se gre točno za to isto zadevo. Vsak jo pač malo drugače poimenuje.

Drugače pa imaš varianto Mail Relay-a, ki nima z to temo nič skupnega in služi pošti, kateri pošiljaš ven v svet. Tudi tu se gre za store&forward zadevo - namesto direktno na končni mail server, mail pošlješ samo do serverja od tvojega providerja. Včasih, ko so bila kje kakšna huda ozka grla, omrežja manj stabilna, serverji pogosteje nedosegljivi, si se na ta način rešil svojih mailov in jih predal strežniku svojega providerja, ta pa je potem poskrbel za dostavo.

Danes to morda ni več tako atraktivno, saj so omrežja hitrejša in bolj stabilna. Jaz sem ukinil mail relay, ker sem imel kup težav zaradi brihtnežev, ki so bili prepričanja, da je greylisting ultimativna antispam rešitev.

flbroker je 26. sep 2016 ob 18:22 izjavil:

SeMiNeSanja je 26. sep 2016 ob 18:11 izjavil:

Varianta, ki se DEJANSKO uporablja (tam, kjer imajo kaj pojma o teh stvareh) pa je tipa 'store and forward' - backup server PREPOŠLJE mail na primarni server, ko ta pride nazaj online. Torej NE pobiraš mailov nikjer drugje, kot s tvojega enega in edinega mail serverja.

Ja in, v cem je problem? Mi tukaj govorimo o MX failover sistemu za katerega ti trdis da NE DELUJE, ker nimas blage veze o cem govoris! Potem ko sem ti razlozil kako deluje prides ven z izjavo da JA RES DELUJE AMPAK tisti 'ta pravi' imajo se forwarding nastavljen na koncu! lol pa kaj ti sploh govoris clovek? A se zavedas kaj pises?

Kje prosim, sem napisal, da NE DELUJE? Napisal sem, da je bullshit, ker imaš svoje maile po X mailboxih naokrog raztresene in jih moraš pobirat enega po enega.
In prosim ne se delat pretirano pametnega, glede na to, da očitno tudi za Round Robin DNS še nisi slišal.

P.S.: Forward si še naštimaš? Pri 100+ uporabnikih naštimaš forward za vsakega posebej? Kam pa? Na tvojo domeno ali na še dodatne gmail accounte? Sploh razmišljaš, kaj pišeš? Take hece in improvizacije si lahlo privoščiš tam do 5 mailbox-ov. Kako boš pa ti to počel pri nekaj sto uporabnikih, pa mi ni jasno.

>Kaj maš pa ti za ene probleme?
sej je jasno vse :) ane?

flbroker je 26. sep 2016 ob 18:41 izjavil:

No zato ker ti ni jasno bodi tiho. Mi imamo 200k mailboxov, 150k forwardov in 3.7mil sporocil dnevno, ti pa brskas po Wikipediji. Jaz sem vecja budala ker se sploh skusam nekaj ukvarjat in bit v pomoc. Se ne oglasim vec v tej temi, kjer prevladujejo pametnjanovici.

Papir in Internet preneseta vse, kajne?

Kdo nima pojma, si že ti pokazal, ker nisi imel pojma, kako se razporeja mail, če je v MX podana ista prioriteta. Potem pa samo še nabijaš nekaj in se delaš pametnega, za store&forward pa sploh slišal še nisi.

Sploh pa - če bi stvar res OBVLADAL, se nebi obnašal kot aroganten vzvišen as...le.
Tako obnašanje je značilno za tiste, ki so mnenja, da so 'znanje' jedli z veliko žlico, da so stručkoti za vse in jim nihle niti približno do kolen ne seže.

Sorry - mogoče koga drugega prepričaš. Mene pač ne. Sem prevečkrat reševal sranje, ki so ga zakuhali takšni 'stručkoti za vse'

bluefish> Kakšne so pa recimo konkretne opcije za sekundarni MX, poleg omenjenega Googla?

Jaz strankam običajno ponujam storitev za _primarni_ MX, ki počisti smetje, preden pride do njihovega Exchange strežnika, redki med njimi so pa takšni, ki imajo pri sebi v pisarni svoj MX strežnik na manj zanesljivi povezavi, moj MX strežnik pa je nastavljen, da sprejme sporočila za vnaprej določene naslovnike (kadar je njihov strežnik dosegljiv, mu jih praktično nihče ne pošilja), ter jih drži v svoji vrsti, dokler njihov strežnik ni zopet dostopen.

Načeloma to lahko urediš na enega od ogromno različnih načinov, a ti v resnici ni treba, razen če si lahko predstavljaš, da bo tvoj primarni MX nedosegljiv več dni skupaj.

flbroker> Tako da prosim ne govorit nekaj da tole ne deluje ko pa je cisto enostavna zadeva ki jo marsikdo uporablja. Hvala.

Tvoja shema je skrajno neobičajna. Kdo bi si želel takšnega "backupa", da mora stranka "peš" hodit po pošto na drug strežnik vsakič, ko en del interneta "kolcne", in se pošta pošlje na sekundarni MX strežnik in konča v "sekundarnem" poštnem predalu? Tako se s pošto ne dela. Pravilno bi bilo, da bi MX strežnik z višjo prioriteto sporočila držal v vrsti, dokler primarni MX strežnik ni dostopen, ter jih takrat posredoval naprej.