[Ubuntu] fallback - backup mailserver

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Tweakers,

Momenteel heb ik ongeveer paar honder domeinen draaien, waar momenteel de mail slechts op een mailserver wordt afgeleverd. Ondanks dat het eigenlijk al jaren stabiel draait wil ik graag naar een omgeving waar ik voor elk domein een fallback mailserver opgeef door middel van een extra MX record.

mocht de mainserver onbereikbar zijn (daar draait ook pop3 / imap) dan gaat de mail dus naar de fallback server, en deze levert de mail weer netjes af op de hoofd server wanneer die bereikbaar is.

Nu zou ik graag willen kijken naar een oplossing die eigenlijk het volgende doet:

1) Mail accepteren voor alle domeinen (komen regelmatig extra domeinen bij, en liefst wil ik zero configuration extra doen op de fallback host, dus moet gewoon alle mail accepteren) (zal ook wel veel spam op de fallback binnen komen, maar dat wordt toch gefilterd op de main server)

2) Mail dus vasthouden.

nu heb ik zitten zoeken op goolgle over Postfix, Exim, Sendmail etc. Maar nergens echt een duidelijke guide of howto gevonden over het opzetten van een systeem als dit hierboven.

Op Windows (bah) heb je bijv MailEnable, klik je op Act as smarthost, vult IP in van je main mail server (of hostname) en het draait, alleen ik wil af van dat ellendige Windows >:)

uw advies is welkom!

Acties:
  • 0 Henk 'm!

  • Silver7
  • Registratie: Januari 2002
  • Laatst online: 15-08 08:23
Advies: cluster bouwen?

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Cluster? Nergens voor nodig. Postfix configuratie is simpel.

http://www.postfix.org/ST...RATION_README.html#backup

Dus belangrijkste settings is relay_domains en relay_recipient_maps . Zonder relay_recipient_maps ben je vatbaar voor backscatter omdat je secundaire MX dan mail accepteert voor niet bestaande gebruikers en deze levert ie vervolgens af bij de primaire MX die deze weigert.

Als je slim bent laat je je postfix tabel via mysql server replicaten naar je secundaire MX zodat je altijd dezelfde domeinen en adressen hebt op je primaire MX.

Het is ook verstandig om je secundaire MX ook te voorzien van clamav/amavisd om je primaire te ontlasten. Als je niet filtert op je secundaire MX kan je ook blacklists niet gebruiken van je primaire omdat de connecties van je secundaire MX afkomen en niet van de grote boze buitenwereld.

Acties:
  • 0 Henk 'm!

  • ralpje
  • Registratie: November 2003
  • Laatst online: 15:50

ralpje

Deugpopje

Andere optie is exim met accept_relay_secondary_mx (exacte syntax ben ik even kwijt). Komt er in het kort op neer dat je bak dan mail accepteert voor alle domeinen die betreffende bak in hun mx records hebben staan, en vervolgens af gaat proberen te leveren op de eerste MX record.

Freelance (Microsoft) Cloud Consultant & Microsoft Certified Trainer


Acties:
  • 0 Henk 'm!

  • Kippenijzer
  • Registratie: Juni 2001
  • Laatst online: 26-08 09:08

Kippenijzer

McFallafel, nu met paardevlees

Ik zou idd niet stellen om alle mail te accepteren, mocht je main down zijn en het een beetje lang duren voor hij terug is is je backp ook dood omdat hij geen discspace meer heeft ;).
De oplossing door idd gewoon een normale postfix, maar dan als relay ipv als backup instellen, die zijn gegevens uit de lokale read-only MySQL Replicatie server van je main Mail-MySQL haalt is de 'beste' die ook nog eenvoudig blijft.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Dit zijn wel antwoorden waar ik verder mee kom, maar een aantal puntjes waarover ik na zit te denken:

De primaire MX (mailserver) is voorzien van SA, ClamAV, Amavis, Postgrey, Bayes, Custom spam settings per user, etc. Mijn voorkeur is dan ook om niet al die ellende (veel configuratie werk) ook te moeten doen op een secundaire MX server.

Wel vind ik het nuttig inderdaad om alleen de domeinen te accepteren die gehost worden door me primaire MX server. Daarbij komt de suggestie van ralpje weer in de richting.

MySQL replication is opzich geen probleem, maar mooiste zou zijn dat het natuurlijk een kwestie is van configureren van de primaire MX, daar moet het naar toe, accepteer alle domeinen die op de primaire MX draaien.

Het gaat hier om ongeveer 10.000 tot 15.000 berichten per dag dus het volume is niet zo heel extreem dat wanneer de primaire eruit ligt hij klapt door de spamchecks, dit valt allemaal wel mee, vandaar dat ik het for now, niet echt nodig vind om de secundaire zwaar uit te rusten met een hele hoop checks, etc.

Dus, welke adviezen blijven met dit stukje staan? Exim of een simpele Postfix config waar ik dan al die domeinen in moet zetten? Want ik mis het stukje waar Postfix dan moet gaan 'afleveren'.

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Verwijderd schreef op dinsdag 22 juli 2008 @ 11:38:
Dit zijn wel antwoorden waar ik verder mee kom, maar een aantal puntjes waarover ik na zit te denken:

De primaire MX (mailserver) is voorzien van SA, ClamAV, Amavis, Postgrey, Bayes, Custom spam settings per user, etc. Mijn voorkeur is dan ook om niet al die ellende (veel configuratie werk) ook te moeten doen op een secundaire MX server.
Je laat je tabellen gewoon replicaten en secundaire MX. En configuratie is 1 keer copy/pasten of in een SVN repo hangen. Enige interessante is je main.cf
Wel vind ik het nuttig inderdaad om alleen de domeinen te accepteren die gehost worden door me primaire MX server. Daarbij komt de suggestie van ralpje weer in de richting.
Goh, inderdaad briljant om alleen domeinen te accepteren waar je mail voor host. Als je alles klakkeloos accepteert ben je een open relay. En blindelings vertrouwen op MX records zou ik nooit doen. Iedere joker kan natuurlijk zijn secundaire MX naar jouw bak laten wijzen zodat jouw mailserver uiteindelijk kan gaan spammen.
MySQL replication is opzich geen probleem, maar mooiste zou zijn dat het natuurlijk een kwestie is van configureren van de primaire MX, daar moet het naar toe, accepteer alle domeinen die op de primaire MX draaien.
Met mysql houd je gewoon beheer van je secundaire MX in eigen hand, als je alleen kijkt naar MX records geef je dat uit handen.
Het gaat hier om ongeveer 10.000 tot 15.000 berichten per dag dus het volume is niet zo heel extreem dat wanneer de primaire eruit ligt hij klapt door de spamchecks, dit valt allemaal wel mee, vandaar dat ik het for now, niet echt nodig vind om de secundaire zwaar uit te rusten met een hele hoop checks, etc.
Mijn ervaring is dat je maar een goede blacklists al een hoop troep stopt. Zeker die country based blacklists waarmee je China, Korea, Polen etc kan weigeren. Maar het blijft altijd een gepuzzel.
Dus, welke adviezen blijven met dit stukje staan? Exim of een simpele Postfix config waar ik dan al die domeinen in moet zetten? Want ik mis het stukje waar Postfix dan moet gaan 'afleveren'.
Je hebt al Postfix op je primaire, waarom dan iets anders op je secundaire?

Je hoeft voor je relay_domains alleen je virtual_domains_maps o.i.d. settings uit main.cf te pakken, tis geen rocket-science

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Dat is wel een punt, sorry voor mijn kortzichtigheid :P 2 zieke mensen op de afdeling, en de vraag eventjes zo'n backup situatie in te richten.

Ik ga voor dit artikel: http://samat.org/node/con...act_as_a_backup_mx_server met de aanvulling vanuit deze thread (mysql replication, of for now even met de hand de transport map bouwen (of simpel scriptje maken in python die via crontab de mail table synchroniseerd en postmap draait).

thanks

Acties:
  • 0 Henk 'm!

  • ralpje
  • Registratie: November 2003
  • Laatst online: 15:50

ralpje

Deugpopje

smesjz schreef op dinsdag 22 juli 2008 @ 11:51:
[...]

En blindelings vertrouwen op MX records zou ik nooit doen. Iedere joker kan natuurlijk zijn secundaire MX naar jouw bak laten wijzen zodat jouw mailserver uiteindelijk kan gaan spammen.
Niet helemaal waar, want jouw server gaat die mail weer afleveren voglens de MX records. Dat zou betekenen dat een spammer eerst de DNS van de ontvanger aan moet zien te passen om jouw server daaribj te zetten, en vervolgens spam naar dat domein kan versturen.

Enige risico dat je loopt met dit systeem, is dat iemand zonder jouw medeweten jouw host aan zijn MX records toevoegd. Niet erg, want alleen mail aan zijn domein wordt dan gerelayed. En waarom zou iemand zijn inkomende mail via een voor hem onbekende relay willen laten lopen, met alle risico's van dien?

Freelance (Microsoft) Cloud Consultant & Microsoft Certified Trainer


Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
Verwijderd schreef op dinsdag 22 juli 2008 @ 11:57:
Dat is wel een punt, sorry voor mijn kortzichtigheid :P 2 zieke mensen op de afdeling, en de vraag eventjes zo'n backup situatie in te richten.

Ik ga voor dit artikel: http://samat.org/node/con...act_as_a_backup_mx_server met de aanvulling vanuit deze thread (mysql replication, of for now even met de hand de transport map bouwen (of simpel scriptje maken in python die via crontab de mail table synchroniseerd en postmap draait).

thanks
Tsja, dan ga voorbij aan mijn opmerking over backscatter. Transport maps zijn imho niet de manier om dit op te lossen. Relay_* wel. Met transport maps kan je een hoop leuke dingen doen, zoals mail voor een bepaald altijd via 1 bepaalde server laten lopen (en dus MX omzeilen), keiharde routing aangeven en bijv. direct naar een service in /etc/postfix/master.cf verwijzen voor bijv. afhandeling van auto-responders voor vakantie.

Je hebt waarschijnlijk nu iets in main.cf als:

virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

En je relay_domains wordt dan:
relay_domains=mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

En virtual_mailbox_maps op je primaire verander je in relay_recipient_maps op je secundaire.

En ga vooral niet kloten met python en cron om beide servers gelijk te houden. replication lijkt mij het makkelijkst.

Acties:
  • 0 Henk 'm!

  • smesjz
  • Registratie: Juli 2002
  • Niet online
ralpje schreef op dinsdag 22 juli 2008 @ 11:58:
[...]


Niet helemaal waar, want jouw server gaat die mail weer afleveren voglens de MX records. Dat zou betekenen dat een spammer eerst de DNS van de ontvanger aan moet zien te passen om jouw server daaribj te zetten, en vervolgens spam naar dat domein kan versturen.

Enige risico dat je loopt met dit systeem, is dat iemand zonder jouw medeweten jouw host aan zijn MX records toevoegd. Niet erg, want alleen mail aan zijn domein wordt dan gerelayed. En waarom zou iemand zijn inkomende mail via een voor hem onbekende relay willen laten lopen, met alle risico's van dien?
Nou ja, het is inderdaad wat far fetched maar de Postfix manual zegt dit er over:
"Safety: permit_mx_backup can be vulnerable to mis-use when access is not restricted with permit_mx_backup_networks. "
permit_mx_backup_networks:
Restrict the use of the permit_mx_backup SMTP access feature to only domains whose primary MX hosts match the listed networks.
Ergo, je kan dus net zo goed relay_domains gebruiken als je toch een lijst met domeinen moet opgeven.

Slecht voorbeeldje misschien:

ik heb domainX.nl (waar ik verder niks mee doe) met primaire MX 10 die verwijst naar een record waar geen mailserver op draait. MX 20 verwijst naar jouw server. Jouw mail accepteert doodleuk al die spam en kan deze vervolgens niet afleveren aan mijn primaire MX.
Na maximal_queue_lifetime komt de mail bij postmaster (bij jou dus) terecht. Schiet toch niet op?

En iedere keer 'postsuper -d ALL' te doen is ook nogal lomp want je kan ook legitieme mail verwijderen.

Acties:
  • 0 Henk 'm!

  • DiedX
  • Registratie: December 2000
  • Laatst online: 16:56
Ik maak zelf gebruik van fallback mx en postfix, nooit geouwehoer gehad. Heb ik niet zoveel domeinnamen, maar toch ;)

Een belangrijke tip die ik TS meegeef: zorg er voor dat je antispam maatregelen even sterk zijn op je fallback als op je primaire site. Hierbij is de wet van de zwakste schakel van belang.

Zelf maak ik gebruik van:
  • RBL
  • Greylisting
  • SA
Succes!

DiedX supports the Roland™, Sound Blaster™ and Ad Lib™ sound cards

Pagina: 1