[Mailfilter-ng] Lite frågor inför en övergång till Halon

Hej Dan, Lite svar (nedan) inline på dina/LNUs funderingar... När SUNET gick över till Halon-piloten förra året så bytte vi bara rakt av. Innan hade vi prepp:at alla DNS-zoner så MX pekarna hade låg TTL (ett par minuter), så vi skulle kunna svänga över till Halon snabbt (samt tillbaka till CanIt om behov uppstod). SUNET har ju inte jättemånga användare som vissa av er, men det går hyfsat mycket epost till SUNET-domänen (tex ping at sunet.se). Vi har ju också många domäner, så vi kunde börja med att flytta över de mindre använda domänerna först och att validera att allt fungerade som det skulle. Sen var vi ju också lite självsäkra, dvs. att allt var konfigurerat korrekt och att det inte skulle vara några problem eller större buggar med nya Mailfilter-ng :) Jag tror de flesta av er har någon eller några extra domäner / underdomäner som kanske inte får speciellt mycket epost, då kan man ju börja testa med en sådan för att se att hela kedjan med leverans ut till epostserver och brevlåda fungerar. (Ibland är ju allt korrekt uppsatt i MX och epost-servrarna, men så är det en access-lista någonstans i en router som blockerar någonstans…) En alternativ metod för de som vill göra ett mellan test innan man pekar om allt igenom nya lösningen, är att börja testa Mailfilter-ng som en "Backup MX” till existerade Mailfilter. (https://en.wikipedia.org/wiki/MX_record#"Backup”_MX) Dvs. sätta nya Mailfilter-ng med era domän(er) och policy(s) så som ni tror ni vill ha det, och sedan testa det *skarpt* på en liten delmängd av epost, genom att _lägga_till_endast_en_extra_ MX i er domän, och peka på en av Mailfilter-ng MX-servrarna. Den nya MX-(dns-)posten ska ha högt preferens-värde (== "lång distans” == låg prio) samt ha ett litet TTL-värde, så ni kan plocka bort den snabbt (den försvinner snabbt ur alla dns-cache:ar) om ni upptäcker nått problem. Det beror delvis kanske på hur mycket man testar eller hur snabbt man gör bytet/omläggningen… I vårt fall så körde vi bara på ett snabbt byte ("ingen kommer ihåg en fegis"), så det kändes som en bra sak att dels skapa en intern-ärende, så vår NOC kände till att vi bytte lösning till en annan bara över dagen. Och dels kanske användare skulle uppleva någon störning i form av att epost inte kom fram, men peppar peppar, det blev inget avbrott eller någon störning. (Däremot hitta vi en PDF-bilage-bugg långt senare, men den är fixad sedan en länge tid tillbaka…) Testar ni köra en server som Backup MX så kommer ni ju tydligare kunna hitta ev. problem, om det skulle vara nått med konfiguration osv. Ni kan ju även sätta om preferens-värdet på MX-pekare för mailfilter-ng till något lägre lite senare (jämnviktat med CanIt), för att få se mer epost-trafik. Om ni testat det i någon/några veckor utan att det blivit nått problem, så kanske det inte är meningsfullt att göra någon informationskampanj om att ni byter anitspam-lösning? Dock kommer ju en Backup MX med största säkerhet inte ge en fullständig bild av all epost som passerar... Inget utöver det jag skrivit ovan. De viktigaste är tänka på att sänka TTL-värdet för alla MX pekare i god tid innan om vill kunna peka om snabbt. Om man vill ha en mer utdragen process så låter man TTL vara oförändrad på gamla CanIt MX:arna, och skriver över dem med de nya MX (med låg TTL, så man kan få bort dem ur zonen och all DNS-cache om man behöver backa tillbaka till CanIt snabbt) Det bör inte vara nått problem att få till några sådana. Är det nått speciellt du tänker på? Mvh, Fredrik