Backup MX vraagjes

[Paul van der Vlis]

Hallo,

Als ik de MX records zo instel:
10 mx1.domein.nl
20 mx2.domein.nl
kan ik er dan van op aan dat normale mail (dus geen spammers o.i.d.) de
mail afleveren op mx1.domein.nl mits deze machine in de lucht is?
Volgens mij niet, maar ik kan me vergissen.

Dan heb ik nog een vraag: de laatste tijd richt ik steeds meer
mailservers in zonder een backup MX, omdat spammers die soms misbruiken.
Stel de verbinding of de machine valt uit, dan neem ik toch aan dat ik
op het laatste nippertje nog een backup MX kan gaan instellen, of het IP
van de bestaande MX wijzigen waardoor de mail naar een andere machine
gaat. Correct? Of vragen sommige mailservers niet opnieuw na bij de
mailserver bij een nieuwe poging de mail af te leveren?

Of is het misschien een idee om een backup MX in te stellen en de mail
daar altijd tijdelijk te weigeren, zodat er wel afgeleverd moet worden
op de juiste machine. En de weigering op te heffen op het moment van een
probleem?

Met vriendelijke groet,
Paul van der Vlis.

[Cor Gest]

Some entity, AKA Paul van der Vlis <***@vandervlis.nl>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

Post by Paul van der Vlis
Hallo,
10 mx1.domein.nl
20 mx2.domein.nl
kan ik er dan van op aan dat normale mail (dus geen spammers o.i.d.) de
mail afleveren op mx1.domein.nl mits deze machine in de lucht is?
Volgens mij niet, maar ik kan me vergissen.

Veel spambots sturen bij voorkeur naar de MX met de laagste priority
(hoogste volgnnummer) in de hoop dat een Backup MX niet of onvoldoende
correct is geconfigureerd om hun criminele rotzooi tegen te houden.
Echter als je geen backup MX hebt, spammers sturen zelfs hun criminele
rotzooi als je helemaal geen MX hebt, gaat alles naar die ene MX toe.

Post by Paul van der Vlis
Of is het misschien een idee om een backup MX in te stellen en de mail
daar altijd tijdelijk te weigeren, zodat er wel afgeleverd moet worden
op de juiste machine. En de weigering op te heffen op het moment van een
probleem?

Een temporary_error genereren na 'CONNECT' is een redelijke oplossing
om in ieder geval een deel van de zooi uiten de deur te houden.
Een correct afgerichte smtp-server wacht dan een uurtje of wat en
re-sends.

Cor

[Ruben van der Leij]

Post by Cor Gest
Een temporary_error genereren na 'CONNECT' is een redelijke oplossing
om in ieder geval een deel van de zooi uiten de deur te houden.
Een correct afgerichte smtp-server wacht dan een uurtje of wat en
re-sends.

The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
will be beneficial when the SMTP client can determine the reason for
non-delivery.

Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. The
parameters to the retry algorithm MUST be configurable.

(rfc2821)

Alles wat zich niet aan bovenstaande houdt (oude Lotus Notus, Exhange, en
andere rommel) spreekt geen SMTP en hoort niet thuis op het internet.

[Paul van der Vlis]

Post by Cor Gest
(selectively-snipped-or-not-p)

Post by Paul van der Vlis
Hallo,
10 mx1.domein.nl
20 mx2.domein.nl
kan ik er dan van op aan dat normale mail (dus geen spammers o.i.d.) de
mail afleveren op mx1.domein.nl mits deze machine in de lucht is?
Volgens mij niet, maar ik kan me vergissen.

Veel spambots sturen bij voorkeur naar de MX met de laagste priority
(hoogste volgnnummer) in de hoop dat een Backup MX niet of onvoldoende
correct is geconfigureerd om hun criminele rotzooi tegen te houden.
Echter als je geen backup MX hebt, spammers sturen zelfs hun criminele
rotzooi als je helemaal geen MX hebt, gaat alles naar die ene MX toe.

Het ging me hier om de gewone mail, en niet om de spam. Ik zoek ook geen
anti-spam oplossing maar een degelijke manier om mail te ontvangen.

Post by Cor Gest

Post by Paul van der Vlis
Of is het misschien een idee om een backup MX in te stellen en de mail
daar altijd tijdelijk te weigeren, zodat er wel afgeleverd moet worden
op de juiste machine. En de weigering op te heffen op het moment van een
probleem?

Een temporary_error genereren na 'CONNECT' is een redelijke oplossing
om in ieder geval een deel van de zooi uiten de deur te houden.
Een correct afgerichte smtp-server wacht dan een uurtje of wat en
re-sends.

Mijn bedoeling was om dit evt. altijd te doen op de backup MX. Alleen in
geval van problemen op de echte MX wou ik hem open zetten. Voordeel
boven het wijzigen van de DNS lijkt me dat ik de DNS niet altijd zelf in
de hand heb, en het wijzigen dan soms traag is.

Groet,
Paul.

[Maurice Janssen]

Post by Paul van der Vlis
Mijn bedoeling was om dit evt. altijd te doen op de backup MX. Alleen in
geval van problemen op de echte MX wou ik hem open zetten.

Als het gaat om betrouwbaar mail ontvangen, dan zou ik hem permanent
openzetten. Het is immers altijd mogelijk dat de primaire server geen
problemen heeft, maar dat deze toch onbereikbaar is voor een verzendende
server (door routeringsproblemen bij de verzende server of ergens
onderweg), zodat er toch op de backup MX mail afgeleverd wordt.
In de meeste gevallen zal het wel goed gaan, maar naar mijn idee maak je
het jezelf nodeloos ingewikkeld door al die toeters en bellen.

[Paul van der Vlis]

Post by Maurice Janssen

Post by Paul van der Vlis
Mijn bedoeling was om dit evt. altijd te doen op de backup MX. Alleen in
geval van problemen op de echte MX wou ik hem open zetten.

Als het gaat om betrouwbaar mail ontvangen, dan zou ik hem permanent
openzetten. Het is immers altijd mogelijk dat de primaire server geen
problemen heeft, maar dat deze toch onbereikbaar is voor een verzendende
server (door routeringsproblemen bij de verzende server of ergens
onderweg), zodat er toch op de backup MX mail afgeleverd wordt.
In de meeste gevallen zal het wel goed gaan, maar naar mijn idee maak je
het jezelf nodeloos ingewikkeld door al die toeters en bellen.

Het potentiele spam probleem wat ik zie is het volgende:

Een backup MX heeft in veel gevallen niet de beschikking over de lijst
met beschikbare mailboxen, het neemt dus een bericht van een correct
domein gewoon aan. Stel de spammer geeft als afzender de persoon naar
wie hij wil spammen aan, die persoon krijgt dan een "mailbox does not
excist" bericht terug van mijn backup MX en mijn backup MX kan daardoor
in de blacklists komen.

Met vriendelijke groet,
Paul van der Vlis.

[Maurice Janssen]

Post by Paul van der Vlis
Een backup MX heeft in veel gevallen niet de beschikking over de lijst
met beschikbare mailboxen, het neemt dus een bericht van een correct
domein gewoon aan.

Dat moet je inderdaad voorkomen. Als je op de backup geen lijst met
alle mailboxen hebt, dan kun je er maar beter meteen mee stoppen.

Post by Paul van der Vlis
Stel de spammer geeft als afzender de persoon naar
wie hij wil spammen aan, die persoon krijgt dan een "mailbox does not
excist" bericht terug van mijn backup MX en mijn backup MX kan daardoor
in de blacklists komen.

Precies. Een backup MX die dergelijke back scatter veroorzaakt verdient
ook niet beter.

Je moet m.i. dus zorgen dat je ofwel een backup hebt die geen
backscatter veroorzaakt (dus dezelfde spammaatregelen als de primary en
een lijst mailboxen), ofwel een primary die voldoende betrouwbaar is.

[Paul van der Vlis]

Post by Maurice Janssen

Post by Paul van der Vlis
Een backup MX heeft in veel gevallen niet de beschikking over de lijst
met beschikbare mailboxen, het neemt dus een bericht van een correct
domein gewoon aan.

Dat moet je inderdaad voorkomen. Als je op de backup geen lijst met
alle mailboxen hebt, dan kun je er maar beter meteen mee stoppen.

Post by Paul van der Vlis
Stel de spammer geeft als afzender de persoon naar
wie hij wil spammen aan, die persoon krijgt dan een "mailbox does not
excist" bericht terug van mijn backup MX en mijn backup MX kan daardoor
in de blacklists komen.

Precies. Een backup MX die dergelijke back scatter veroorzaakt verdient
ook niet beter.
Je moet m.i. dus zorgen dat je ofwel een backup hebt die geen
backscatter veroorzaakt (dus dezelfde spammaatregelen als de primary en
een lijst mailboxen), ofwel een primary die voldoende betrouwbaar is.

Het punt is dat de mensen hun mailboxenlijst en aliassen wel eens
veranderen. Zelfs als je die lijst regelmatig zou updaten loop je nog
achter de feiten aan, lijkt me. Een andere oplossing lijkt me nog niet
zo eenvoudig. Hoe zorg jij dat je backup MX dezelfde mailboxen en
aliassen kent?

Verder zou ik ook helemaal niet weten hoe je dat moet instellen in
Postfix. Ik doe het nu met "relay_domains = ...". In het bestand
"transport" staat dan iets als:
domein34.nl relay:[hallo.xs4all.nl]

Met vriendelijke groet,
Paul van der Vlis.

[Maurice Janssen]

Post by Paul van der Vlis

Post by Maurice Janssen
Je moet m.i. dus zorgen dat je ofwel een backup hebt die geen
backscatter veroorzaakt (dus dezelfde spammaatregelen als de primary en
een lijst mailboxen), ofwel een primary die voldoende betrouwbaar is.

Het punt is dat de mensen hun mailboxenlijst en aliassen wel eens
veranderen. Zelfs als je die lijst regelmatig zou updaten loop je nog
achter de feiten aan, lijkt me.

Dat is inderdaad lastig. Je moet denk ik een methode vinden om het te
kunnen synchroniseren zonder handmatige acties te hoeven ondernemen.
Dan kun je het een paar keer per dag syncen.
Dat lijkt me wel acceptabel: alleen mail die bij de backup MX aangeboden
wordt voor adressen die nog niet gesynced zijn gaat dan verloren (tenzij
je een 4xx code terugstuurt, maar voor niet-bestaande mailboxen geef je
normaliter een 5xx code).

Post by Paul van der Vlis
Een andere oplossing lijkt me nog niet
zo eenvoudig. Hoe zorg jij dat je backup MX dezelfde mailboxen en
aliassen kent?

Ik heb geen backup MX ;-)

Post by Paul van der Vlis
Verder zou ik ook helemaal niet weten hoe je dat moet instellen in
Postfix. Ik doe het nu met "relay_domains = ...". In het bestand
domein34.nl relay:[hallo.xs4all.nl]

Sorry, ik heb vrijwel geen ervaring met Postfix.

[richard lucassen]

On Fri, 17 Oct 2008 13:53:23 +0000 (UTC)

Post by Maurice Janssen

Post by Paul van der Vlis
Het punt is dat de mensen hun mailboxenlijst en aliassen wel eens
veranderen. Zelfs als je die lijst regelmatig zou updaten loop je nog
achter de feiten aan, lijkt me.

Dat is inderdaad lastig. Je moet denk ik een methode vinden om het te
kunnen synchroniseren zonder handmatige acties te hoeven ondernemen.
Dan kun je het een paar keer per dag syncen.
Dat lijkt me wel acceptabel: alleen mail die bij de backup MX
aangeboden wordt voor adressen die nog niet gesynced zijn gaat dan
verloren (tenzij je een 4xx code terugstuurt, maar voor niet-bestaande
mailboxen geef je normaliter een 5xx code).

Postfix kan dat. Die vraagt als 2e mx aan de authoritative mailserver of
de user bestaat, zoniet, 5xx, opzouten dus:

unverified_recipient_reject_code = 550

(zeg het ff uit m'n hoofd, maar zoiets is het wel, kan dadelijk wel ff
kijken of er niet een extra optie ergens nodig is)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Stef]

In nl.comp.os.linux.netwerken,

Post by richard lucassen
On Fri, 17 Oct 2008 13:53:23 +0000 (UTC)

Post by Maurice Janssen

Post by Paul van der Vlis
Het punt is dat de mensen hun mailboxenlijst en aliassen wel eens
veranderen. Zelfs als je die lijst regelmatig zou updaten loop je nog
achter de feiten aan, lijkt me.

Dat is inderdaad lastig. Je moet denk ik een methode vinden om het te
kunnen synchroniseren zonder handmatige acties te hoeven ondernemen.
Dan kun je het een paar keer per dag syncen.
Dat lijkt me wel acceptabel: alleen mail die bij de backup MX
aangeboden wordt voor adressen die nog niet gesynced zijn gaat dan
verloren (tenzij je een 4xx code terugstuurt, maar voor niet-bestaande
mailboxen geef je normaliter een 5xx code).

Postfix kan dat. Die vraagt als 2e mx aan de authoritative mailserver of

Maar wat gebeurt er dan als die authoritative server uit de lucht is?

[richard lucassen]

On Fri, 17 Oct 2008 19:33:54 +0200

Post by Stef

Post by richard lucassen
Postfix kan dat. Die vraagt als 2e mx aan de authoritative

Maar wat gebeurt er dan als die authoritative server uit de lucht is?

Dan geeft-ie een 4xx. Nog geen probleem, want als de verzendende server
netjes smtp praat, dan houdt die ook nog 5 dagen in de queue.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[richard lucassen]

On Fri, 17 Oct 2008 20:32:44 +0200

Post by richard lucassen

Post by Stef
Maar wat gebeurt er dan als die authoritative server uit de lucht is?

Dan geeft-ie een 4xx. Nog geen probleem, want als de verzendende
server netjes smtp praat, dan houdt die ook nog 5 dagen in de queue.

Kanttekening: ik gebruik dit systeem met front-end servers en niet met
een backup-mx, dat is een klein verschil. Ik wil dat er een 5xx gegeven
wordt als de user niet bestaat. Ik heb namelijk geen zin om mail te
processen die niet afgeleverd kan worden.

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Stef]

In nl.comp.os.linux.netwerken,

Post by richard lucassen
On Fri, 17 Oct 2008 20:32:44 +0200

Post by richard lucassen

Post by Stef
Maar wat gebeurt er dan als die authoritative server uit de lucht is?

Dan geeft-ie een 4xx. Nog geen probleem, want als de verzendende
server netjes smtp praat, dan houdt die ook nog 5 dagen in de queue.

Kanttekening: ik gebruik dit systeem met front-end servers en niet met
een backup-mx, dat is een klein verschil. Ik wil dat er een 5xx gegeven
wordt als de user niet bestaat. Ik heb namelijk geen zin om mail te
processen die niet afgeleverd kan worden.

Dus als ik het goed begrijp draai je in feite zonder backup-MX?

[richard lucassen]

On Sun, 19 Oct 2008 21:26:45 +0200

Post by Stef

Post by richard lucassen
Kanttekening: ik gebruik dit systeem met front-end servers en niet
met een backup-mx, dat is een klein verschil. Ik wil dat er een 5xx
gegeven wordt als de user niet bestaat. Ik heb namelijk geen zin om
mail te processen die niet afgeleverd kan worden.

Dus als ik het goed begrijp draai je in feite zonder backup-MX?

Niet nodig, ik draai meerdere front-end servers. Maar inderdaad, een
backup-mx is, als de verzendende mailservers zich netjes gedragen,
eigenlijk niet nodig, aangezien de verzendende server de zaak al 4 a 5
dagen vasthoudt. Alleen heb je dan geen vat op de queues. Bij een
backup-mx wel.

R.

[Martijn Lievaart]

Post by richard lucassen
On Fri, 17 Oct 2008 19:33:54 +0200

Post by Stef

Post by richard lucassen
Postfix kan dat. Die vraagt als 2e mx aan de authoritative mailserver

Maar wat gebeurt er dan als die authoritative server uit de lucht is?

Dan geeft-ie een 4xx. Nog geen probleem, want als de verzendende server
netjes smtp praat, dan houdt die ook nog 5 dagen in de queue.

Dan heb je niets gewonnen boven geen backup MX.

M4

[richard lucassen]

On Wed, 5 Nov 2008 18:40:56 +0100

Post by Martijn Lievaart

Post by richard lucassen
Dan geeft-ie een 4xx. Nog geen probleem, want als de verzendende
server netjes smtp praat, dan houdt die ook nog 5 dagen in de queue.

Dan heb je niets gewonnen boven geen backup MX.

Kijk eens in de opvolgende post :)

Een backup-mx draaien heeft een paar kleine voordelen, zoals het in 1
keer kunnen doorschieten van de wachtende queue en een eventueel langer
dan vijf dagen vasthouden van de mail.

Maar volgens mij word je als beheerder opgeknoopt door de gemiddelde
user als de mail het vijf dagen niet doet :)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Cor Gest]

Some entity, AKA richard lucassen <***@xaq.nl>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

Post by richard lucassen
Maar volgens mij word je als beheerder opgeknoopt door de gemiddelde
user als de mail het vijf dagen niet doet :)

lusers krijgen alreeds een reetketelsteenhemorroideverkalking als mail het 5
minuten niet doet, niet dat ook enigszons boeit verder ... ;-)


cor

[richard lucassen]

On Wed, 05 Nov 2008 18:53:57 +0000

Post by Cor Gest

Post by richard lucassen
Maar volgens mij word je als beheerder opgeknoopt door de gemiddelde
user als de mail het vijf dagen niet doet :)

lusers krijgen alreeds een reetketelsteenhemorroideverkalking als mail
het 5 minuten niet doet, niet dat ook enigszons boeit verder ... ;-)

Ik zou dan maar nooit greylisting toepassen Cor :)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Cor Gest]

Some entity, AKA richard lucassen <***@xaq.nl>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

Post by richard lucassen
Ik zou dan maar nooit greylisting toepassen Cor :)

OMG!, het idee alleen al! ..... AFFREUZ!

shitlisting Rulez: 2.561.174 entries & counting ....

Cor

[Martijn Lievaart]

Post by Cor Gest
(selectively-snipped-or-not-p)

Post by richard lucassen
Maar volgens mij word je als beheerder opgeknoopt door de gemiddelde
user als de mail het vijf dagen niet doet :)

lusers krijgen alreeds een reetketelsteenhemorroideverkalking als mail
het 5 minuten niet doet, niet dat ook enigszons boeit verder ... ;-)

Je wilt niet weten hoe vaak ik moet uitleggen dat mail niet 100%
betrouwbaar is. Het grote probleem momenteel is dat het zo betrouwbaar is
dat alle lusers er van uit gaan dat het wel betrouwbaar is. Tot het
misgaat.

M4

[Martijn Lievaart]

Post by richard lucassen
On Wed, 5 Nov 2008 18:40:56 +0100

Post by Martijn Lievaart

Post by richard lucassen
Dan geeft-ie een 4xx. Nog geen probleem, want als de verzendende
server netjes smtp praat, dan houdt die ook nog 5 dagen in de queue.

Dan heb je niets gewonnen boven geen backup MX.

Kijk eens in de opvolgende post :)
Een backup-mx draaien heeft een paar kleine voordelen, zoals het in 1
keer kunnen doorschieten van de wachtende queue en een eventueel langer
dan vijf dagen vasthouden van de mail.

Niet als ie een 4xx geeft, dan heb je niets gewonnen. Want als alle MXen
niet beschikbaar zijn, is dat voor de verzender precies hetzelfde als een
4xx.

Of ben ik nou gek?

M4

[richard lucassen]

On Thu, 6 Nov 2008 10:38:42 +0100

Post by Martijn Lievaart

Post by richard lucassen
Een backup-mx draaien heeft een paar kleine voordelen, zoals het in
1 keer kunnen doorschieten van de wachtende queue en een eventueel
langer dan vijf dagen vasthouden van de mail.

Niet als ie een 4xx geeft, dan heb je niets gewonnen. Want als alle
MXen niet beschikbaar zijn, is dat voor de verzender precies
hetzelfde als een 4xx.

Dan niet nee

Post by Martijn Lievaart
Of ben ik nou gek?

Nee, maar een backup mx geeft geen 4xx, die neemt de mail aan. Op
voorwaarde dat hij zo ingesteld is dat hij een database aan boord heeft
van de users. En als je de userdatabase checkt op de platliggende server
en vervolgens een 4xx geeft dan heeft dat geen zin natuurlijk.

Of je stelt 'm zo in dat-ie alle mail aanneemt maar dat zou ik anno 2008
toch echt niet meer willen.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Martijn Lievaart]

Post by richard lucassen
On Thu, 6 Nov 2008 10:38:42 +0100

Post by Martijn Lievaart

Post by richard lucassen
Een backup-mx draaien heeft een paar kleine voordelen, zoals het in 1
keer kunnen doorschieten van de wachtende queue en een eventueel
langer dan vijf dagen vasthouden van de mail.

Niet als ie een 4xx geeft, dan heb je niets gewonnen. Want als alle
MXen niet beschikbaar zijn, is dat voor de verzender precies hetzelfde
als een 4xx.

Dan niet nee

Dat was waar ik op reageerde. Vandaar. :-)

M4

[Fred Mobach]

Post by richard lucassen
On Thu, 6 Nov 2008 10:38:42 +0100

Post by Martijn Lievaart

Post by richard lucassen
Een backup-mx draaien heeft een paar kleine voordelen, zoals het in
1 keer kunnen doorschieten van de wachtende queue en een eventueel
langer dan vijf dagen vasthouden van de mail.

Niet als ie een 4xx geeft, dan heb je niets gewonnen. Want als alle
MXen niet beschikbaar zijn, is dat voor de verzender precies
hetzelfde als een 4xx.

Dan niet nee

Post by Martijn Lievaart
Of ben ik nou gek?

Nee, maar een backup mx geeft geen 4xx, die neemt de mail aan.

Je bent te optimistisch. Ga maar eens na in welke situaties een 4xx
return wordt gegeven, dan zul je zien dat er vele redenen kunnen zijn
daarvoor die niets te maken hebben met de andere MX-en.

[Ruben van der Leij]

Hoe zorg jij dat je backup MX dezelfde mailboxen en aliassen kent?

rsync, mysql replicatie, ldap replicatie etc.

[Martijn Lievaart]

Post by Paul van der Vlis

Post by Maurice Janssen
Je moet m.i. dus zorgen dat je ofwel een backup hebt die geen
backscatter veroorzaakt (dus dezelfde spammaatregelen als de primary en
een lijst mailboxen), ofwel een primary die voldoende betrouwbaar is.

Het punt is dat de mensen hun mailboxenlijst en aliassen wel eens
veranderen. Zelfs als je die lijst regelmatig zou updaten loop je nog
achter de feiten aan, lijkt me. Een andere oplossing lijkt me nog niet
zo eenvoudig. Hoe zorg jij dat je backup MX dezelfde mailboxen en
aliassen kent?

Alles in ldap en een replica draaien op de backup MX.

M4

[Martijn Lievaart]

Post by Maurice Janssen

Post by Paul van der Vlis
Mijn bedoeling was om dit evt. altijd te doen op de backup MX. Alleen in
geval van problemen op de echte MX wou ik hem open zetten.

Als het gaat om betrouwbaar mail ontvangen, dan zou ik hem permanent
openzetten. Het is immers altijd mogelijk dat de primaire server geen
problemen heeft, maar dat deze toch onbereikbaar is voor een verzendende
server (door routeringsproblemen bij de verzende server of ergens
onderweg), zodat er toch op de backup MX mail afgeleverd wordt. In de
meeste gevallen zal het wel goed gaan, maar naar mijn idee maak je het
jezelf nodeloos ingewikkeld door al die toeters en bellen.

Heb net een gevalletje gehad waarbij het niet goed ging. De verzender had
twee lijnen, de mail werd over een willekeurige van de twee lijnen
verstuurd. Maar een van de twee lijnen had een routerings probleem met de
primary MX ontvanger, waarna de mail op de backup MX werd aangeboden, die
weigerde omdat de primary op was. Heeft best wat hoofdbrekens gekost om
te vinden (kwam ook doordat de beheerder van de verzendende kant niet
100% meewerkte tot duidelijk werd wat het probleem was).

Gelukkig was dit voor beide kanten voldoende om hun setup aan te passen.

Met andere woorden, niet doen dus.

M4

[Dick Streefland]

Paul van der Vlis <***@vandervlis.nl> wrote:
| Of is het misschien een idee om een backup MX in te stellen en de mail
| daar altijd tijdelijk te weigeren, zodat er wel afgeleverd moet worden
| op de juiste machine. En de weigering op te heffen op het moment van een
| probleem?

Wat ik gedaan heb, is een backup MX record maken met een dyndns.org
naam, waarvan met het IP adres hetzelfde is als dat van het eerste MX
record. Als de server uitvalt, dan zorgt een watchdog script op de
backup machine er voor dat het IP adres omgeschakeld wordt.

[Paul van der Vlis]

Post by Dick Streefland
| Of is het misschien een idee om een backup MX in te stellen en de mail
| daar altijd tijdelijk te weigeren, zodat er wel afgeleverd moet worden
| op de juiste machine. En de weigering op te heffen op het moment van een
| probleem?
Wat ik gedaan heb, is een backup MX record maken met een dyndns.org
naam, waarvan met het IP adres hetzelfde is als dat van het eerste MX
record. Als de server uitvalt, dan zorgt een watchdog script op de
backup machine er voor dat het IP adres omgeschakeld wordt.

Ik vind dat in pricipe een goed idee. Wat de toegevoegde waarde van
dyndns.org precies is snap ik niet helemaal, maar dat lijkt me bijzaak.

Ik heb zelf nameservers en zou voor elke klant een eigen backupMX kunnen
aanmaken die inderdaad verwijst naar hun eigen mailserver, maar die ik
snel kan veranderen in geval van problemen.

Het watchdog script idee gaat nog verder. Ik ga er eens verder over denken.

Met vriendelijke groet,
Paul van der Vlis.

[Dick Streefland]

Paul van der Vlis <***@vandervlis.nl> wrote:
| Ik vind dat in pricipe een goed idee. Wat de toegevoegde waarde van
| dyndns.org precies is snap ik niet helemaal, maar dat lijkt me bijzaak.

Het voordeel van zo'n domain is dat er een simpele interface
beschikbaar is om snel het IP adres te kunnen updaten. Ik doe dat
met een eenvoudig wget commando.

| Ik heb zelf nameservers en zou voor elke klant een eigen backupMX kunnen
| aanmaken die inderdaad verwijst naar hun eigen mailserver, maar die ik
| snel kan veranderen in geval van problemen.

Als je zelf een betrouwbare nameserver hebt, dan kun je dat inderdaad
ook zelf doen.

| Het watchdog script idee gaat nog verder. Ik ga er eens verder over denken.

Het stelt niet veel voor, ik doe periodiek een:

echo QUIT | nc -q3 $server smtp

en kijk dan of er een 220 melding terugkomt. Als er gedurende een
bepaalde tijd geen enkele 220 melding terugkomt, wordt omgeschakeld
naar de backup MX.

[Ximinez]

Post by Paul van der Vlis
Hallo,
10 mx1.domein.nl
20 mx2.domein.nl
kan ik er dan van op aan dat normale mail (dus geen spammers o.i.d.) de
mail afleveren op mx1.domein.nl mits deze machine in de lucht is?
Volgens mij niet, maar ik kan me vergissen.
Dan heb ik nog een vraag: de laatste tijd richt ik steeds meer
mailservers in zonder een backup MX, omdat spammers die soms misbruiken.
Stel de verbinding of de machine valt uit, dan neem ik toch aan dat ik
op het laatste nippertje nog een backup MX kan gaan instellen, of het IP
van de bestaande MX wijzigen waardoor de mail naar een andere machine
gaat. Correct? Of vragen sommige mailservers niet opnieuw na bij de
mailserver bij een nieuwe poging de mail af te leveren?

Volgens mij heb je gelijk en is een backup MX in feite onnodig. Als je
mailserver langere tijd down is kun je altijd je DNS aanpassen. Ik heb
het nooit getest, maar het lijkt me bijzonder vreemd als mailservers
geen nieuw DNS request doen. Wel zorgen dat je ttl niet te hoog staat.

In de pakweg 15 jaar dat ik mailservers draai heb ik nog nooit mail
verloren doordat de server zo lang down ging dat een backup nodig was
geweest.

X.

[Jaap]

Post by Ximinez
In de pakweg 15 jaar dat ik mailservers draai heb ik nog nooit mail
verloren doordat de server zo lang down ging dat een backup nodig was
geweest.

Verdwenen mail is natuurlijk moeilijk aan te tonen, maar mijn mailserver
staat soms dagen uit en ontvangt toch de mail van de afgelopen dagen.
Het hang natuurlijk erg af van het geduld van de verzendende mailservers.

Deze mailserver gebruik ik voornamelijk om emailadressen te maken voor
allerlei sites die mijn email willen weten. Zodra er misbruik van een
adres gemaakt wordt, verdwijnt het adres uit mijn aliasses.

Jaap

[Paul van der Vlis]

Post by Jaap

Post by Ximinez
In de pakweg 15 jaar dat ik mailservers draai heb ik nog nooit mail
verloren doordat de server zo lang down ging dat een backup nodig was
geweest.

Verdwenen mail is natuurlijk moeilijk aan te tonen, maar mijn mailserver
staat soms dagen uit en ontvangt toch de mail van de afgelopen dagen.
Het hang natuurlijk erg af van het geduld van de verzendende mailservers.

4-5 dagen is normaal.

Met vriendelijke groet,
Paul van der Vlis.

[Martijn Lievaart]

Post by Ximinez
Volgens mij heb je gelijk en is een backup MX in feite onnodig. Als je
mailserver langere tijd down is kun je altijd je DNS aanpassen. Ik heb
het nooit getest, maar het lijkt me bijzonder vreemd als mailservers
geen nieuw DNS request doen.

Ha. Haha. Hahahahahahahahahah.

Welcome to the real world 1).

M4

1) Firewall-1 SMTP proxy. Dat is trouwens niet het enige wat met het ding
mis is.

[Natxo Asenjo]

On 2008-10-16, Paul van der Vlis <***@vandervlis.nl> wrote:

[knip]

Post by Paul van der Vlis
Dan heb ik nog een vraag: de laatste tijd richt ik steeds meer
mailservers in zonder een backup MX, omdat spammers die soms misbruiken.
Stel de verbinding of de machine valt uit, dan neem ik toch aan dat ik
op het laatste nippertje nog een backup MX kan gaan instellen, of het IP
van de bestaande MX wijzigen waardoor de mail naar een andere machine
gaat. Correct? Of vragen sommige mailservers niet opnieuw na bij de
mailserver bij een nieuwe poging de mail af te leveren?

ik zou geen backup mx hebben. Wél een goed monitoring systeem :-). Als
je je e-mail problemen binnen 2 dagen kan oplossen, heb je geen mx
nodig. 2 dagen moeten genoeg zijn voor je, toch?

[Paul van der Vlis]

Post by Natxo Asenjo
[knip]

Post by Paul van der Vlis
Dan heb ik nog een vraag: de laatste tijd richt ik steeds meer
mailservers in zonder een backup MX, omdat spammers die soms misbruiken.
Stel de verbinding of de machine valt uit, dan neem ik toch aan dat ik
op het laatste nippertje nog een backup MX kan gaan instellen, of het IP
van de bestaande MX wijzigen waardoor de mail naar een andere machine
gaat. Correct? Of vragen sommige mailservers niet opnieuw na bij de
mailserver bij een nieuwe poging de mail af te leveren?

ik zou geen backup mx hebben. Wél een goed monitoring systeem :-). Als
je je e-mail problemen binnen 2 dagen kan oplossen, heb je geen mx
nodig. 2 dagen moeten genoeg zijn voor je, toch?

Ja normaal wel, maar niet om b.v. een kapotte kabel in de grond te
vervangen.

Met vriendelijke groet,
Paul van der Vlis.

[Natxo Asenjo]

Post by Paul van der Vlis

Post by Natxo Asenjo
ik zou geen backup mx hebben. Wél een goed monitoring systeem :-). Als
je je e-mail problemen binnen 2 dagen kan oplossen, heb je geen mx
nodig. 2 dagen moeten genoeg zijn voor je, toch?

Ja normaal wel, maar niet om b.v. een kapotte kabel in de grond te
vervangen.

tja, als je daar bang voor bent, dan moet je de boel op een datacenter
hosten en niet lokaal op het bedrijf zelf. Maar daar kunnen ook de
kabels door graafwerkzaamheden worden gesneden.

En wat als je (weer) getroffen wordt door zo'n dsl storing als die van
kpn eerder dit jaar? Bij ons lagen verbindingen langer dan 5 dagen uit.
Dat heet overmacht.

Wat je kan doen is 2 verbindingen binnen laten komen, een van een
kabelaar, een van een dsl provider. De kans dat je getroffen wordt door
storingen op alle 2 tegelijk is heel klein (maar kan nog steeds
gebeuren, natuurlijk). Dan moet je alleen het ip van de mx record
aanpassen (kort ttl). Maar, dit kost extra geld en je kan het niet op
een consumentabbonement doen (je bent zo in een blocklist ook al heb je
niks mis gedaan).

dus ...

Praat met je klant, leg hem uit wat de opties zijn (en evt gevolgen
daarvan) en laat hem beslissen.

[Paul van der Vlis]

Post by Natxo Asenjo

Post by Paul van der Vlis

Post by Natxo Asenjo
ik zou geen backup mx hebben. Wél een goed monitoring systeem :-). Als
je je e-mail problemen binnen 2 dagen kan oplossen, heb je geen mx
nodig. 2 dagen moeten genoeg zijn voor je, toch?

Ja normaal wel, maar niet om b.v. een kapotte kabel in de grond te
vervangen.

tja, als je daar bang voor bent, dan moet je de boel op een datacenter
hosten en niet lokaal op het bedrijf zelf. Maar daar kunnen ook de
kabels door graafwerkzaamheden worden gesneden.

Ik had twee weken geleden nog een kapotte kabel bij een klant. En XS4all
wilde geen monteur sturen, eerst moesten er allerlei testjes worden
gedaan, op locatie natuurlijk. Daarbij moest de hele bekabeling worden
veranderd vond men. Die bekabeling was overigens door een monteur van
XS4all aangelegd, maar toch was hij fout en moesten wij het veranderen,
ahum. Gelukkig zat er nog linesharing op, de telefoonlijn bromde, en de
KPN stuurde wel een monteur. De kabel was inderdaad ergens vol water
gelopen.

Post by Natxo Asenjo
En wat als je (weer) getroffen wordt door zo'n dsl storing als die van
kpn eerder dit jaar? Bij ons lagen verbindingen langer dan 5 dagen uit.
Dat heet overmacht.

Nu ja, met wat ingrepen kun je de mail tijdelijk ergens anders laten
uitkomen. Dat heb ik bij bovengenoemde klant ook gedaan, want het duurde
wat langer dan de bedoeling was...

Post by Natxo Asenjo
Wat je kan doen is 2 verbindingen binnen laten komen, een van een
kabelaar, een van een dsl provider. De kans dat je getroffen wordt door
storingen op alle 2 tegelijk is heel klein (maar kan nog steeds
gebeuren, natuurlijk). Dan moet je alleen het ip van de mx record
aanpassen (kort ttl). Maar, dit kost extra geld en je kan het niet op
een consumentabbonement doen (je bent zo in een blocklist ook al heb je
niks mis gedaan).

Kan wel op veel consumenten abbonnementen. Alhoewel, de kabelaar hier
geeft alleen dynamische IP's die wijzigen. Maar voor nood kan het lijkt
me met iets als dynDNS. Ik heb ook al zitten denken aan draadloos ;-)

Met vriendelijke groet,
Paul van der Vlis.