---

Nogle internetudbydere kræver, at indgående post
skal sendes gennem udbyderens eget relay. Typisk
konfigureres det så ved at man sætter den rigtige
server som primær mx og relay serveren som sekundær
mx.

Jeg tænker, at det burde kunne gøres smartere.

For det første har man det problem, at afsenderen
altid først prøver den primære mx og så kommer til
at vente på et timeout. Og først derefter sender
til den sekundære mx.

For det andet har man ikke mere den (begrænsede)
sikring imod single point of failure som det at
have to mx records giver. Tværtimod får man nu to
single points of failure, for hvis blot en af de to
mailservere er nede kan der ikke sendes mail til
domænet.

Jeg tænker, at det ville være smartere hvis
udbyderen har to uafhængige relays, man kan angive
som primær og sekundær mx. Men hvordan kan man så
fortælle disse servere, hvad der er den endelige
destination?

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

"Kasper Dupont"
> Nogle internetudbydere kræver, at indgående post
> skal sendes gennem udbyderens eget relay. Typisk
> konfigureres det så ved at man sætter den rigtige
> server som primær mx og relay serveren som sekundær
> mx.
>
> Jeg tænker, at det burde kunne gøres smartere.

Korrekt. Hvis udbyderen og dig selv, gerne ville holde en liste over de
"rigtige" mailservere opdateret konstant, så kunne ISP være lavest mx. Og du
behøvede faktisk slet ikke have en mx-record. Men med den nuværende metode,
slipper udbyderen for at vide på forhånd hvad din ip er. Udbyderen bruger
bare normal dns opslag.

> Jeg tænker, at det ville være smartere hvis
> udbyderen har to uafhængige relays, man kan angive
> som primær og sekundær mx. Men hvordan kan man så
> fortælle disse servere, hvad der er den endelige
> destination?

Med fare for ikke at have forstået dit spørgsmål rigtigt, vil jeg vove den
påstand, at det er fuldstændig det samme scenario som med kun 1 server.

Før
Din = mx10
ISP = mx20

Efter
Din = mx10
ISP1 = mx20
ISP2 = mx30 (eller mx20 på lige fod med ISP1)

Desuden kan du jo ikke vide (men det forholder sig jo nok sådan), om
udbyderen allerede har et redundant setup. Via BGP, redundante linjer,
firewalls og servere, mv..

--
/Stoltze
Har du husket at klippe i dit indlæg? Og læst det igennem en ekstra gang?
Husk at læse http://www.usenet.dk/netikette/citatteknik.html
Kig forbi http://blomstertid.dk

---

Niels Stoltze wrote:
>
> Korrekt. Hvis udbyderen og dig selv, gerne ville holde en liste over de
> "rigtige" mailservere opdateret konstant, så kunne ISP være lavest mx. Og du
> behøvede faktisk slet ikke have en mx-record. Men med den nuværende metode,
> slipper udbyderen for at vide på forhånd hvad din ip er. Udbyderen bruger
> bare normal dns opslag.

Jeg er enig i, at det ikke duer hvis en ISP skal ind og
lave opsætning for hvert enkelt domæne. Men måske kunne
man finde på en anden måde ejeren af domænet selv kunne
fortælle relayet, hvor mailen skulle sendes hen.

>
> > Jeg tænker, at det ville være smartere hvis
> > udbyderen har to uafhængige relays, man kan angive
> > som primær og sekundær mx. Men hvordan kan man så
> > fortælle disse servere, hvad der er den endelige
> > destination?
>
> Med fare for ikke at have forstået dit spørgsmål rigtigt, vil jeg vove den
> påstand, at det er fuldstændig det samme scenario som med kun 1 server.
>
> Før
> Din = mx10
> ISP = mx20
>
> Efter
> Din = mx10
> ISP1 = mx20
> ISP2 = mx30 (eller mx20 på lige fod med ISP1)

Det har du selvfølgelig ret i. Man har stadig problemet
med timeouts. Og hvis man også selv vil have redundante
servere så får man timeouts på de første to af fire
mail servere.

Nogen af de steder hvor man kan få gratis domænenavne er
der faktisk ikke mulighed for mere end to mx records.
Men hvis den bedste løsning er flere mx records, så skal
man selvfølgelig gå efter den løsning. Jeg synes bare
ikke et setup hvor den primære server aldrig kan tage
imod mail er ønskeligt.

>
> Desuden kan du jo ikke vide (men det forholder sig jo nok sådan), om
> udbyderen allerede har et redundant setup. Via BGP, redundante linjer,
> firewalls og servere, mv..

Det er selvfølgelig en mulighed.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

On Sun, 31 Jul 2005 12:15:02 +0200, Kasper Dupont
<kasperd@daimi.au.dk> wrote:

> For det første har man det problem, at afsenderen
> altid først prøver den primære mx og så kommer til
> at vente på et timeout. Og først derefter sender
> til den sekundære mx.

Hvis det er konfigureret fornuftigt, vil der blive sendt en
unreachable til afsenderen, når han forsøger første server, og det bør
han reagere fornuftigt på ved med det samme at forsøge den anden.

Dermed bliver forsinkelsen fuldstændig minimal, men selv med et max
TCP timeout er forsinkelsen begrænset, og det er jo mail, der ikke
ligefrem er en realtidsapplikation.

> For det andet har man ikke mere den (begrænsede)
> sikring imod single point of failure som det at
> have to mx records giver. Tværtimod får man nu to
> single points of failure, for hvis blot en af de to
> mailservere er nede kan der ikke sendes mail til
> domænet.

Du overser, at der er en sikring hos afsenderen, der lægger mailen i
kø indtil den kan afleveres. Det er kun hvis en servere er nede i ret
lang tid, at mail faktisk mistes.

-A

---

Asbjorn Hojmark wrote:
>
> Hvis det er konfigureret fornuftigt, vil der blive sendt en
> unreachable til afsenderen, når han forsøger første server, og det bør
> han reagere fornuftigt på ved med det samme at forsøge den anden.

Enig, men har du set tilfælde, hvor det var konfigureret
fornuftigt?

>
> Du overser, at der er en sikring hos afsenderen, der lægger mailen i
> kø indtil den kan afleveres. Det er kun hvis en servere er nede i ret
> lang tid, at mail faktisk mistes.

Jeg ved godt, at mails ikke går tabt bare fordi en smtp
server er nede i en periode. Men selv en forsinkelse kan
være ret så upraktisk i nogle situationer. Typisk går der
vel højst fem sekunder fra afsenderen trykker send og til
jeg får besked om, at den er modtaget. For det meste
kunne jeg sikkert også godt leve med et par minuter.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.