Bekijk Volledige Versie : Fallback MX
Aan het orienteren om een fallback MX op te zetten, deze moet de mails opvangen wanneer de primary mailserver onbereikbaar is. Nu zullen sommige roepen 'zolang je DNS maar bereikbaar is, is een fallback niet nodig', dus het heeft geen zin om dat te roepen.
Ik lees hier en daar dat een fallback 'problemen' met zich meeneemt, op de primary heb je antivirus/anti-spam etc draaien, maar je fallback is meestal maar een simpel postfix/exim server zonder deze toepassingen. Nu vraag ik mij af, is dit wel nodig? Want de fallback zal alles doorsturen naar de primary en hier zal de mails alsnog gescanned worden, niet?
Volgens mij mis ik ergens iets?
Ik lees hier en daar dat een fallback 'problemen' met zich meeneemt, op de primary heb je antivirus/anti-spam etc draaien, maar je fallback is meestal maar een simpel postfix/exim server zonder deze toepassingen. Nu vraag ik mij af, is dit wel nodig? Want de fallback zal alles doorsturen naar de primary en hier zal de mails alsnog gescanned worden, niet?
Volgens mij mis ik ergens iets?
Je mist niet echt iets, vroeger was het nog wel eens zo dat spammers bewust omdat er geen virus/spam/rbl dingen op de hogere MXen aangewezig waren voor deze kozen. Tegenwoordig zie ik dit gedrag in ieder geval veel minder.
Als je scant op je primaire en het is niet de bedoeling een stuk load te offloaden is het enige dat je mist mogelijke RBL listings, als de primaire niet dieper kijkt dan dat het van de backup MX afkomt. Ik weet niet wat er op de primaire draait, maar de meeste producten hebben dit door en kijken dan 1 host verder terug.
Wij hebben laatst ook een (nieuwe) fallback mailserver geconfigureerd in combinatie met clamav/postgrey/dcc etc.
Is het niet zo dat de fallback als 'trusted' wordt gezien door de primary?
Ik weet het niet zeker....
Maar wat zie jij dan precies als het 'probleem' (refererend naar "Ik lees hier en daar dat een fallback 'problemen' met zich meeneemt") ?
Ik bedoel op de fallback hoef je geen clamav/spamassassin etc hoeven draaien omdat de primary het al heeft.
dreamhost_nl
15/01/12, 09:20
En waarom zou je dat niet doen? Ik kan je legio voobeelden opnoemen waarom je dit juist wel moet doen.
Als je rbl's wilt gebruiken die op basis van ip adres blokkeren, moet je dit ook op je fallback doen. Anders zal de spam via je fallback alsnog binnenkomen en aangezien je fallback niet op de blacklist staat, krijg je dan alsnog vrij veel spam ..
En waarom zou je dat niet doen? Ik kan je legio voobeelden opnoemen waarom je dit juist wel moet doen.
Omdat bijvoorbeeld op de primary gebruikers zelf instellingen kunnen wijzigen en het bijna niet te doen is om deze in sync te houden met de fallback.
Geef eens een aantal (als je wilt legio) voorbeelden, zeer interessant.
Wij draaien ook gewoon RBL/clamav etc op de fallback. Het "in sync houden" gebeurd op domeinnaam basis (en technisch uitgevoerd als: alle webservers hebben hun lokale DNS server (voornamelijk DirectAdmin systemen) welke syncen met ons DNS cluster. Uit die database worden alle domeinen gesynct naar een aparte database welke door Postfix wordt uitgelezen. Alle mail voor domeinen in de database worden geaccepteerd, ook voor niet bestaande adressen, die worden door de primairy geweigerd).
Zo voorkom je dat spam toch wordt afgeleverd (de fallback heeft namelijk wel rDNS, staat niet in een RBL, enz en zal dus veel minder scoren bij spamassassin dan wanneer de spam rechtstreeks wordt afgeleverd op de primary).
Omdat bijvoorbeeld op de primary gebruikers zelf instellingen kunnen wijzigen en het bijna niet te doen is om deze in sync te houden met de fallback.
Geef eens een aantal (als je wilt legio) voorbeelden, zeer interessant.
Wij draaien ook gewoon RBL/clamav etc op de fallback. Het "in sync houden" gebeurd op domeinnaam basis (en technisch uitgevoerd als: alle webservers hebben hun lokale DNS server (voornamelijk DirectAdmin systemen) welke syncen met ons DNS cluster. Uit die database worden alle domeinen gesynct naar een aparte database welke door Postfix wordt uitgelezen. Alle mail voor domeinen in de database worden geaccepteerd, ook voor niet bestaande adressen, die worden door de primairy geweigerd).
Zo voorkom je dat spam toch wordt afgeleverd (de fallback heeft namelijk wel rDNS, staat niet in een RBL, enz en zal dus veel minder scoren bij spamassassin dan wanneer de spam rechtstreeks wordt afgeleverd op de primary).
Ik denk dat xaban meer bedoelt op het feit van whitelist, greylist, blacklist in verband met de syncronisatie. Je wilt natuurlijk niet hebben op je fallback dat een e-mail adres standaard gereject wordt als die wel in een whitelist staat op de primaire.
Verder gebruik ik op mijn fallbacks zowel spam als antivirus en rbl, the whole works eigenlijk. Hiervoor had ik een custom directadmin addon/module gemaakt zodat klanten hun instellingen zelf konden regelen, dit werd via een api geupdate naar de fallback servers (postfix+mailscanner+clamav+fprot). Maar omdat ik het onderhoud er van beu ben ga ik overstappen naar spamexperts, de voordelen wegen in mijn geval veel meer door dan de kosten.
Ik denk dat xaban meer bedoelt op het feit van whitelist, greylist, blacklist in verband met de syncronisatie. Je wilt natuurlijk niet hebben op je fallback dat een e-mail adres standaard gereject wordt als die wel in een whitelist staat op de primaire.Inderdaad, dat is wat ik bedoel met in sync houden :)
Verder gebruik ik op mijn fallbacks zowel spam als antivirus en rbl, the whole works eigenlijk. Hiervoor had ik een custom directadmin addon/module gemaakt zodat klanten hun instellingen zelf konden regelen, dit werd via een api geupdate naar de fallback servers (postfix+mailscanner+clamav+fprot). Maar omdat ik het onderhoud er van beu ben ga ik overstappen naar spamexperts, de voordelen wegen in mijn geval veel meer door dan de kosten.
EUR 12,- / domein per jaar vind ik toch iets teveel, dus voorlopig geen spamexperts.
Nu vraag ik mij nog steeds af, waarom moet je de hele rambam op je fallback hebben, de primary haalt alle e-mail sowieso door de hele rambam, niet? Volgens mij mis ik ergens nog steeds een punt :)
CharlieRoot
15/01/12, 18:09
Je kunt het op meder manieren doen natuurlijk. Je kunt de fallback altijd alle mail laten afleveren aan de primaire server (die blijkbaar dus down is), maar dat lijkt mij niet wenselijk. Wij hebben altijd 3 MX records waarbij de servers identiek zijn; allen met Postfix/Clamav/Spamc/Mailscanner. enige verschil is de bewaartijd, hoe hoger de MX prio hoe langer de bewaartijd.
EUR 12,- / domein per jaar vind ik toch iets teveel, dus voorlopig geen spamexperts.
Dat hangt natuurlijk van je business model af, je kan de klanten ook de optie geven om dit als extra dienst af te nemen zoals ik doe ;)
Nu vraag ik mij nog steeds af, waarom moet je de hele rambam op je fallback hebben, de primary haalt alle e-mail sowieso door de hele rambam, niet? Volgens mij mis ik ergens nog steeds een punt :)
Even kort uitleggen:
Optie 1: Je fallback (zonder toeters en bellen) ontvangt van de spammer, je fallback zend dit naar je primaire (zonder extra instellingen) en aanziet jouw fallback server als spam server en blokkeert deze. Resultaat je fallback kan niet meer afleveren bij je primaire server.
Optie 2: Je fallback (zonder toeters en bellen) ontvangt van de spammer, je fallback zend dit naar je primaire (met fallback in whitelist|allow|...), hierdoor ontvangt je primaire alles van je fallback zonder ip/rdns/rbl check. Resultaat de spam krijgt minder punten en wordt daardoor niet als spam aanzien.
En dan heb ik het nog niet over de extra load die veroorzaakt kan worden als een fallback (zonder toeters en bellen) begint met het afleveren van e-mails als je primaire bvb down was.
Correct me if i'm wrong ;).
crossplatform
19/01/12, 11:13
Ben het eens met de meeste mensen dat een fallback in ieder geval RBL controle moet doen.
Als je dat niet doet dan komt het inderdaad voor dat je primary minder spam pakt omdat jouw fallback (hopelijk) niet op een RBL staat.
Je fallback weigert dan in ieder geval dezelfde mail servers als de primary MX op basis van RBL's.
antispam zoals spamassassin oid gewoon op de primary laten draaien en niet op de fallback.
Deep inspection op header en body van de mail moet je bij de primary laten. Ook ivm settings van je users zoals whitelists, blacklists, quarantaine ja/nee, etcetera.
Wij hebben een SpamExperts cluster draaien waar onze MX20's (machines in DE) ook gewoon members/slaves in het cluster zijn. Zo hebben we op de fallback de zelfde kwaliteit spamfiltering als op de MX10.