Het nut van een fallback mailserver?

[mazz]

Omdat ik een fallback mailserver op wilde zetten en daarom wat informatie aan het inwinnen was stuitte ik op enkele discussies over het al dan niet gebruiken van een fallback mailserver.

De meeste mensen die tegen zijn klampen zich vast aan een RFC artikel waarin staat dat een mail server minimaal 4 a 5 dagen moet proberen om de mail alsnog af te leveren. Veel mailservers zijn niet zo geconfigureerd waardoor je dus al problemen kunt krijgen. Daarnaast lijkt het mij veel fijner om niet afhankelijk te hoeven zijn van de configuratie van de mailservers van de tegenpartij.

Ik denk dat, zolang een groot deel zich nog niet strict aan de RFC standaarden houdt, het weinig zin heeft om deze strak te hanteren.

Wat denken jullie hierover? Ik ben erg benieuwd!

[mrFoce]

Het nut is vrij simpel. Stel dat je server 24 uur of langer plat ligt, dan verwijderen veel SMTP servers tegenwoordig de e-mail. Als jij een fallback server hebt, dan wordt de mail gewoon afgeleverd. Daarnaast zal je fallback server de mail gelijk versturen aan je primaire server, zodra die dat kan en verwijderd de fallback server de e-mails niet. Wil je geen mail verliezen, gebruik een fallback server

[mazz]

Er zijn ook veel mensen die zeggen, als je je niet aan de RFC houdt, dan moet je het maar uitzoeken.
Ik zou dat niet kunnen verantwoorden eerlijk gezegd. Weet niet hoe jullie hierover denken?

Ik ben trouwens ook benieuwd naar de maatregelen die jullie nemen om spam buiten de deur te houden mb.t een fallback server

[JoetjeF]

De RFC zegt alleen maar dat als een bericht niet verzonden kan worden er niet onmiddelijk opnieuw geprobeerd mag worden om het bericht te verzenden maar dat er eerst gewacht moet worden.

De RFC noemt wel dat er 'over het algemeen 4 to 5 dagen' geprobeerd moet worden het bericht opnieuw te verzenden, maar dat is dus alleen maar een aanbeveling.

Ik geloof dat de meeste mail servers toch wel minstens twee dagen proberen te verzenden. Wat ook mee kan spelen is hoe snel je de mail in je mailbox wilt hebben na een storing, Bij een fallback mailserver is dat vrijwel direct maar als je op een retry van de zendende mailserver moet wachten kan dat soms wel oplopen tot 24 uur.

[CyBeR]

't is eigenlijk vrij simpel: als er iets mis gaat bij jouw normale mailserver, wil je dan afhankelijk zijn van het goed geconfigureerd zijn van anderen hun servers of niet?

Vwb spam: waarom zou dat een probleem zijn? Je moet natuurlijk niet je fallback servers uitzonderingen laten zijn qua spam scanning en dergelijke.

[ChaserBoZ_]

CyBeR schreef op maandag 31 mei 2010 @ 02:46:
't is eigenlijk vrij simpel: als er iets mis gaat bij jouw normale mailserver, wil je dan afhankelijk zijn van het goed geconfigureerd zijn van anderen hun servers of niet?

Vwb spam: waarom zou dat een probleem zijn? Je moet natuurlijk niet je fallback servers uitzonderingen laten zijn qua spam scanning en dergelijke.

Psies, antispam et cetera ook (juist) op de fallback server(s), en je fall back servers whitelisten op je 'uiteindelijke mx machine'. Zo voorkom je dat mail welke als spam wordt bestempeld niet tussen je mx servers blijft hangen, maar meteen wordt afgeschoten.

[Powermage]

Wij maken gebruik van een antispam platform wat we zelf hosten en leveren voor onze klanten, deze bestaat uit 2 antispam servers die op mx niveau direct de email krijgen voor de klant (en eigen) domeinen, deze staan op 2 verschillende locaties, dus meer fallback hebben we niet nodig, klanten krijgen vrijwel geen spam meer binnen en ze hebben ook direct een fallback. ook is het wel een aantal keer gebeurt dat klanten voor wat langere tijd van internet verstoken zaten en we dan de email omleidde naar een mailserver van ons met een catch all pop box eraan, die konden ze dan via een umts card en een pop3 connector alsnog leegpoppen om zo hun mail te ontvangen.

[mazz]

JoetjeF schreef op maandag 31 mei 2010 @ 02:40:
De RFC zegt alleen maar dat als een bericht niet verzonden kan worden er niet onmiddelijk opnieuw geprobeerd mag worden om het bericht te verzenden maar dat er eerst gewacht moet worden.

De RFC noemt wel dat er 'over het algemeen 4 to 5 dagen' geprobeerd moet worden het bericht opnieuw te verzenden, maar dat is dus alleen maar een aanbeveling.

Ik geloof dat de meeste mail servers toch wel minstens twee dagen proberen te verzenden. Wat ook mee kan spelen is hoe snel je de mail in je mailbox wilt hebben na een storing, Bij een fallback mailserver is dat vrijwel direct maar als je op een retry van de zendende mailserver moet wachten kan dat soms wel oplopen tot 24 uur.

Dat dacht ik eerst ook, maar volgens mij is het toch geen advies.
Welke bron gebruik jij voor het RFC artikel?

In mijn bron staat

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.

[Pogostokje]

Ervaring leert gewoon dat zonder fallback server last krijgt van 2 dingen:
1. Mail die niet bewaard wordt wanneer je hoofdserver even down is.
2. Wazige mail aan de verzenders over dat er vertraging is met afleveren.

In een meer-dan-hobby omgeving is het gewoon verstandig er 2 te hebben. En let op, dat ook al zet je de fallback server lager op de MX lijst (hoger nummer dus) ... juist spammers proberen er mail op af te leveren omdat vaak de fallback server niet de volledige anti-spam maatregelen krijgt ... want het is 'maar' de fallback server.

[mazz]

Ben het er zelf ook mee eens trouwens om een backup mx te hebben.

Wat denken jullie trouwens van onderstaande methode om spam tegen te houden. Gaat dit tegenwoordig nog op?

Nolisting mx A entry

Spammers email software does not retry higher-priority MX records. So all you have to do is create a non-existent primary mail server and a working secondary mail server, attempts to contact the primary mail server will always fail. This technique uses a non-existent primary mail server, which is compatible with all correctly configured mail servers such as Sendmail, MS-Exchange, Postfix, Qmail, Exim etc. Create BIND dns configuration as follows:

nixcraft.com. 86400 IN MX 10 mx01.nixcraft.net.in.
nixcraft.com. 86400 IN MX 20 mx02.nixcraft.net.in.
nixcraft.com. 86400 IN MX 30 mx03.nixcraft.net.in.
nixcraft.com. 86400 IN MX 40 mx04.nixcraft.net.in.
Where,

mx02.nixcraft.net.in - Runs your actual primary MX with anti spam and anti virus configurations.
mx03.nixcraft.net.in - Your backup mx server with anti spam / virus and act as store and forward server for mx02.nixcraft.net.in.
mx01.nixcraft.net.in and mx04.nixcraft.net.in are nolist MX servers. They can either be dead (or point to non existing IP) or you can run SMTP on port 25 that always returns 4xx error so that legitimate MTA to retry on a lower numbered MX server. nolist MX servers can also used to get more information about spammers to blacklist them. Google for "spam filtering services that offer free nolist servers" specifically for botnet data harvesting.

[Pogostokje]

Het houdt alleen de domme spam engines tegen. Die zijn er genoeg hoor, dus het helpt een beetje, maar verwacht niet zonder spam te zitten daarmee.

[CyBeR]

Dat houdt slechts één ding tegen: spam software die direct SMTP praat met de hoogste prio (laagste getal) MX. En dat is volgens mij vrij weinig: veel spam wordt gestuurd via open relays (en dat zijn volwaardige SMTP-praters die dus netjes de MX'en af lopen) en belachelijk veel spam probeert 'via de achterdeur', dus via een lagere prio (hoger getal) MX binnen te komen.

[Pogostokje]

Wat wel goed helpt is een serie van goede DNSBL lijsten op je mailservers te configureren. Dat houdt misschien wel 80% van de spam tegen die niet eens verder door de spam-engines hoeft te gaan. Dikke winst.

[Predator]

mazz schreef op maandag 31 mei 2010 @ 23:44:
Ben het er zelf ook mee eens trouwens om een backup mx te hebben.

Wat denken jullie trouwens van onderstaande methode om spam tegen te houden. Gaat dit tegenwoordig nog op?


[...]

Dat zal voor een deel werken, maar zeker niet voldoende.

Als ik even naar onze SMTP gateways kijk dan zie ik dat de 2de toch ook redelijk wat SPAM te eten krijgt.
Redelijk wat minder dan de eerste, maar die is ook online, dus er hoeft geen fallback gedaan te worden.

Meer zelfs. Sommige spam-bots vallen zelfs de laagste priority aan omdat die vaak minder verdediging heeft.

Vergeet niet dat je met zo'n setup ook mail vertraging kan creeëren. Sommige MTA's zetten een mail in de deferred/retry queue als de eerste poging (op de primary MTA) faalt, en gaan pas in de retry queue op alle MX'n proberen. Niet netjes, maar het gebeurd wel (om performantie redenen).

Maar het is allemaal zo simpel.
Je hebt 2 MTA's nodig, best identiek, met dezelfde anti-spam middelen.
Je 'backup' hoeft zelfs geen lagere prio te hebben.
Dankzij virtualisatie hoeft dat ook weinig extra te kosten (althans voor de hardware natuurlijk).

Niet gaan knoeien met fallback SMTP relays bij je provider en dergelijke brakke oplossingen.
Dat is allemaal half werk.

[ Voor 4% gewijzigd door Predator op 01-06-2010 10:52 ]

[Predator]

CyBeR schreef op dinsdag 01 juni 2010 @ 01:00:
Dat houdt slechts één ding tegen: spam software die direct SMTP praat met de hoogste prio (laagste getal) MX. En dat is volgens mij vrij weinig: veel spam wordt gestuurd via open relays (en dat zijn volwaardige SMTP-praters die dus netjes de MX'en af lopen)

Niet akkoord.

Open relay is slechts nog een klein percentage van de spam die verstuurd wordt.
Meer en meer MTA's staan default geen open relay meer. Zelfs in de KMO-wereld wordt er minder en minder geknoeid met instelling van hun MTA.

De grootste sources blijven spambots (gelukkig meestal dom, en dus fire-and-forget : makkelijk te counteren met greylisting of reputation filtering op basis van hun dynamische IP ranges, en vaak ook slechte/valve e-mail headers waardoor ook intelligente filters goed werken), en slechte webmail implementies. Die laatste zijn wel vervelend, want daar zit natuurlijk wel een echte MTA achter.

en belachelijk veel spam probeert 'via de achterdeur', dus via een lagere prio (hoger getal) MX binnen te komen.

Wel akkoord

Pogostokje schreef op dinsdag 01 juni 2010 @ 10:22:
Wat wel goed helpt is een serie van goede DNSBL lijsten op je mailservers te configureren. Dat houdt misschien wel 80% van de spam tegen die niet eens verder door de spam-engines hoeft te gaan. Dikke winst.

Vergeet wel niet dat DNSBL lijsten DNS intensief zijn.
Hoe meer DNSBL je configureerd hoe meer DNS queries je verstuurd per SMTP connectie.

[ Voor 18% gewijzigd door Predator op 01-06-2010 10:54 ]

[Pogostokje]

Predator schreef op dinsdag 01 juni 2010 @ 10:50:
[...]
Vergeet wel niet dat DNSBL lijsten DNS intensief zijn.
Hoe meer DNSBL je configureerd hoe meer DNS queries je verstuurd per SMTP connectie.

Akkoord.
Maar, jammer dan. Spam is iets waarmee gedealed moet worden: het is er nou eenmaal en ik kan in mijn eentje het niet doen laten verdwijnen. Wel kan ik het bij de deur tegenhouden, en dat ik daarvoor bandbreedte moet investeren ... ach, zou de mail doorgaan dan kost het mij wellicht meer: de SMTP sessie + body van de spam aan bandbreedte en dan ook nog storage om al die ongewenste mailtjes op te slaan.

Mocht externe DNS toch een probleem zijn, sommige lijsten kun je lokaal downloaden en dan 1x per zoveel tijd syncen. Dan kun je er een dedicated interne DNS server voor aanstellen (liefst virtueel, om de kosten te drukken). Daar heb ik geen ervaring mee, maar dan ga je dus niet eens naar buiten voor je DNS request.

[Predator]

Pogostokje schreef op dinsdag 01 juni 2010 @ 11:24:
[...]

Akkoord.
Maar, jammer dan. Spam is iets waarmee gedealed moet worden: het is er nou eenmaal en ik kan in mijn eentje het niet doen laten verdwijnen. Wel kan ik het bij de deur tegenhouden, en dat ik daarvoor bandbreedte moet investeren ... ach, zou de mail doorgaan dan kost het mij wellicht meer: de SMTP sessie + body van de spam aan bandbreedte en dan ook nog storage om al die ongewenste mailtjes op te slaan.

Mocht externe DNS toch een probleem zijn, sommige lijsten kun je lokaal downloaden en dan 1x per zoveel tijd syncen. Dan kun je er een dedicated interne DNS server voor aanstellen (liefst virtueel, om de kosten te drukken). Daar heb ik geen ervaring mee, maar dan ga je dus niet eens naar buiten voor je DNS request.

Dat hangt er vanaf. SPAM zijn meestal kleine mails.
Maar als je DNS server sloom is, of je hebt een DNSBL die traag of niet antwoord. Dan blijft je SMTP handler hangen. Die houdt dan een connectie open + memory vast gedurende de timeout.
Als je veel concurrent connecties hebt kan dat een groot probleem worden.

Je kon sommige syncen via rsync, maar niet allemaal.

Maar dat wil niet zeggen dat je geen DNSBL moet gebruiken. Hoe meer layers, hoe beters...
Gewoon je responstijden goed in de gaten houden.

[mazz]

Waar ik zelf aan dacht, is om de fallback pas actief te maken als de primary niet te bereiken is.
Op mijn blog heb ik hier een post over gewijd , inclusief een scriptje dat checkt of de primary mailserver online is.

Wat denken jullie daarvan? Scheelt ook een hoop in peformance denk ik. Als je de fallback speelt voor meerdere mailservers kan het misschien wel lastig worden..

Blogpost (weet niet of ik hem mag plaatsen?)http://www.solidsystems.o...or-directadmin-on-centos/

[CyBeR]

mazz schreef op woensdag 02 juni 2010 @ 21:27:
Waar ik zelf aan dacht, is om de fallback pas actief te maken als de primary niet te bereiken is.
Op mijn blog heb ik hier een post over gewijd , inclusief een scriptje dat checkt of de primary mailserver online is.

Wat denken jullie daarvan? Scheelt ook een hoop in peformance denk ik. Als je de fallback speelt voor meerdere mailservers kan het misschien wel lastig worden..

Geen geweldig idee. Als host X een mail wil sturen naar jouw mail server A, maar die is om de een of andere reden niet bereikbaar (vage firewall, internet routing kapot, whatever) dan is er nog een kans via jouw mail server B die dat wel kan. Een set-up waarbij B pas actief wordt als A niet meer reageert vertraagt de mail in die situatie, of verhindert aflevering compleet*. Plus dat 't waarschijnlijk even duurt voor je door hebt dat A niet meer reageert (of je moet dat elke seconde checken). Mail die komt terwijl A en B niet reageren (Want A is down en B nog niet up) wordt dus ook vertraagd alsof je überhaupt geen fallback had.

Plus dat 't nog 's nergens voor nodig is, ook. En inderdaad, in een set-up waar je fallback dat voor meedere servers doet bijna onmogelijk ook nog. Ik zie ook niet direct hoe 't in performance zou schelen.

*) Stel dat die oorzaak permanent is, zoals de vage firewall (en dat ben ik meer dan eens tegengekomen), dan komt die mail dus nooit aan, tenzij je primaire mail server toevallig een keer down gaat zodat je secundaire up komt. Dit alles terwijl die server X nog aan het proberen is, wat ook niet eeuwig duurt.

[ Voor 14% gewijzigd door CyBeR op 02-06-2010 21:42 ]

[mazz]

Hmm zit wel wat in inderdaad.

Dus eigenlijk bestaat een goede situatie uit een backup mx die hetzelfde antispam beleid hanteren.
Is er trouwens een makkelijke manier om te zorgen dat een backup mx mails direct kan redirecten naar de spam folder zodat de gebruiker dit ook ziet in z`n email client. Of moet je zorgen dat je het onderwerp aanpast naar bijv ***SPAM*** en daar op de primary mailserver een regel voor instelt dat die mailtjes direct de spam folder in gaan?

[CyBeR]

Dat zou je meestal op basis van headers doen.

[mazz]

Ik ga er eens mee aan de slag. Ik vind het toch wel een interessant onderwerp

Deze tutorial lijkt me wel goed
http://www.cyberciti.biz/...ackup-mx-server-anti-spam

Wat vind jij ervan? Alleen dat no-listing is misschien wat achterhaald

[CyBeR]

Dunno, ik doe niet aan postfix

Ik heb exim en die spamfiltert op mijn mx2 niet, daar is m'n mx1 voor en die maakt voor mx2 geen uitzonderingen. Spam die als zodanig geclassificeerd word, wordt gedropt of van een subject-modificatie voorzien. E-mail die niet aan zou komen (niet-bestaand adres bijvoorbeeld) wordt op beide direct geweigerd en mail die mx1 weigert om andere redenen weigert mx2 ook.

[DDX]

Mijn mening is dat het niet nodig is tenzij je er een goede reden voor kan bedenken.
Ik heb het bijvoorbeeld op mijn prive domeinnaam wel lopen omdat de primaire server aan een adsl lijn (bij mij thuis) hangt.
En het best wel eens kan voorkomen dat ik langer dan een paar dagen op vakantie ben en downtime langer dan paar dagen kan duren.
Hoe los ik het probleem van extra spam op; ik heb op de backup mx aangegeven welke users ik wil accepteren voor mijn domein, andere niet bestaande users geef ik dus ook op de backup mx een user unknown.
En op beide machines draait spamassassin.

Maar als ik de vraag krijg of wij bij ons op de zaak een backup mailserver oplossing kunnen aanbieden voor klanten die hierom vragen geef ik idd argument van de rfc dat servers het aantal dagen bewaren.
Zomaar een backup mx aanbieden zonder dat je filtering op juiste usernames kan doen/spamprotectie, geeft alleen maar erg veel mail richting postmaster@backupserver.

En argument dat je niet wilt dat afzenders na aantal uur waarschuwing mail krijgen wat hierboven genoemd wordt, lijkt me toch juist handig dat afzenders horen dat de mail niet afgeleverd is en dat je misschien beter even kan bellen ?
(op mijn backup mx heb ik de waarschuwing ook gewoon op 4u staan, ik heb alleen de failure aangepast op 99weken ipv 5 dagen)

[DukeBox]

Meestal zet ik niet meer dan 2 mx hosts in. Beide smtp servers voorzien van dnsbl, spam assasin, ldap verificatie over het algemeen heeft de primaire mx host toch het meeste werk, ook wat spam betreft.

Waar beide mx servers aktief zijn op een andere lokatie en subnet met lokale ldap en dns source, maar ook failover naar de andere dns en ldap source voor het geval die het te druk krijgt/er uit ligt.