Hej Fredrik, Tack för svaren, tillägg till frågan om "ratelimit-regler". Idag har vi satt en gräns för alla användare att de får skicka 400 mail per timme, denna gräns vill vi också ha i det nya filtret. Vi har också för ett 50-tal användare gjort individuella undantag från ovanstående generella gräns som medger att dessa får skicka 500-10000 mail per timme. Bägge dessa regler vill vi kunna konfigurera innan vi sätter Halon i drift för utgående mail, är det möjligt och hur kan vi göra? Vi planerar också att som Tomas gör nu att först börja med att flytta den ingående mailtrafiken till Halon och låta den utgående hanteras av Can-It ett tag tills vi känner oss mogna att slå över även denna trafik och lämna Can-It helt. Med vänliga hälsningar, Dan Andersson Vi behandlar personuppgifter enligt reglerna i Dataskyddsförordningen, se lnu.se/personuppgifter. -----Ursprungligt meddelande----- Från: Fredrik Pettai <pettai at sunet.se> Skickat: den 16 mars 2021 12:20 Till: Dan Andersson <dan.andersson at lnu.se> Kopia: mailfilter-ng at lists.sunet.se Ämne: Re: [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