Hej,
Fram tills i helgen så har även epost som innehåller virus blivit taggade eller satta i karantän om Spam Action varit inställd på “tag” eller “quarantine”.
UU noterade att det kanske inte var optimalt att skicka vidare dessa epost, och bad även om en policy-ändring att alltid neka epost innehållandes virus.
Det har vi ändrat nu så oavsett vilken spam action som är satt, så kommer epost som Mailfilter-ng hittar virus i att alltid bli nekade (reject).
Mvh,
/P
Hej!
Nu har sommaren gått och det mesta är migrerat till Halon.
För att sammanfatta hur det gott och för att få höra era åsikter om vad som
är kvar och vad som önskas inför framtiden så tänker vi köra ett
användarmöte.
Ingen anmälan krävs.
Agenda:
Inledning/presentation
Kundfeedback, hur fungerar Mailfilter-ng för
er? Ris & ros!
Mailfilter-ng: vad kan förbättras, vilka
funktioner saknas?
Datum: 29e september
Tid: 13.00 -15.00
Plats: https://oru-se.zoom.us/my/liljebergh
Hej på er,
Under sommaren så var det några kunder med lite större epost-miljöer som fann ett problem med att SRS inte fungerade i olika alla fall för dem.
Kort problemförklaring: Det var om det en Mailfilter-ng kund som skickade epost till en annan Mailfilter-ng kund där mottagare var en funktionsadress som i sin tur gjorde redirect utgående.
Även fast SRS var påslaget hos den andra kunden (för att generell “redirect" skulle fungera utåt), så ägdes avsändarens epost-adress av den första kunden.
Att kunder ska kunna spoof:a varandras epost-adresser är inget Halon hade stöd för, de har en strikt kontroll på att bara kunderna får skicka ut från sina egna domäner.
När problemet upptäcktes och rapporterades av UU så meddelade vi Halon som kikade på detta över sommaren. En fix från Halon kom tidigare till devops-milön och nu när vi testat den så har vi även lagt in den i produktion-miljön. Har ni SRS påslaget så börjar den gälla automatiskt nu.
Mvh,
/P
Hej,
Vi har lagt på lite funktioner som efterfrågats av er kunder, men nu har vi nått stabil produktion vad det gäller funktioner som ni alla har efterfrågat & haft behov av, iallafall för att klara av sommaren
De senaste sakerna vi fixat är:
• Om man blockerar en “Sender” så kommer den även blockeras i form av mottagare på utgående epost-flöde (förutsatt att man har utgående epost uppsatt igenom Halon)
• Det finns en ny inställning för att stripp:a bort MDNs (X-Confirm-Reading-To mfl) på inkommande epost.
• CYRENs Viruss-canner som blockerat en del epost för er, går att stänga av separat (inställningen gäller både in- & utgående)
• Message-ID loggas nu även om man skickar syslog lokalt till sin organisation
• säkert nått jag glömt…
Flera går på semester snart (några har redan hunnit gå), så arbetet med nya releaser avstannar temporärt för att ha en så stabil drift som möjligt över sommaren.
Fortsätt kontakta noc at sunet.se om ni har frågor, eller hittat problem, så hjälper vi er. Vi kommer få lite förstärkning till NOC:en fr.o.m 1 Juli, då Fredrik Kjellman kommer tillbaka (tidigare SU, nu som SUNET), och ska börja jobba med Mailfilter-ng.
Givetvis kommer vi lägga på uppdateringar mm om så behövs… men vi kommer dra ner på tempot med nya releaser/funktioner nu under Juli månad.
Trevlig sommar!
Mvh,
/P
Hej,
Något försenat, men nu har vi loggning av ej konfigurerade avsändare (domäner) samt SRS (Sender Rewrite Scheme) som funktioner i Mailfilter-ng.
En mer detaljerad beskrivning om hur det ska konfigureras kommer vi publisera på Mailfilter-ng forum-sidan. Kan posta länken till det här.
Mvh,
/P
Hej
Vi har stött på ett problem vi inte kan lösa och undra hur ni andra löst det, om ni haft liknande saker.
I vår e-postmiljö kan man inte automatiskt skicka vidare brev till mottagare utanför e-postservern. Det finns dock några undantag till regeln. Vi har bl.a. ett antal funktionsadressbrevlådor som vidarebefordras till externa tjänster. Bl.a. bibliotekstjänster som använder t.ex. libanswers.com, eller ekonomiavdelningen som använder externa inscanningstjänster.
Fram tills nu har det inte varit ett problem då Canit gladeligen släppte igenom all sådan e-post. Halon däremot sätter käppar i hjulet för oss genom att inte tillåta att vi skickar e-post där vi inte i förväg definierat domänen i Halon. Med tanke på att hela världen kan skicka till dessa funktionsbrevlådor skulle vi isf behöva definiera hela världens e-postdomäner, vilket av förklarliga skäl inte är möjligt.
Så när vi nu står inför problemet ser vi i praktiken bara två lösningar:
a) Halon fixar något så vi kan fortsätta med Halon.
b) Vi använder något annat än Halon.
Tankar?
--
Dan Manell
Universitetsgemensam IT
Uppsala Universitet
När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/
E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy
Hej på er alla!
Efter att under en längre tid undersökt och utvärderat mailfilter så har vi
tillslut fått Halon installerat och driftsatt.
De flesta kunder har migrerat över helt eller delvis och i de flesta fall
utan några större problem.
Halon har under hela resan varit mycket behjälpliga med rättningar allt
eftersom det dykt upp problem och med utveckling när önskemål inkommit.
Om ni märker av några problem, så hör av er till noc at sunet.se så vi kan
hjälpa till så fort som möjligt.
Glöm nu bara inte att sista dag för migrering är 30/6-2021.
Om ni har specifika problem som inte fungerar i Halon kontakta genast
noc at sunet.se om ni inte redan gjort så, då går det bra att tillsvidare
använda Canit medans vi jobbar tillsammans för att lösa dessa.
Sunet har även gått in och sponsrat utveckling för att få in saker som ni
som kunder efterfrågat.
Vår tanke är att vi under hösten kommer att bjuda in till ett användarmöte
där vi kommer parta om en roadmap, diskutera hur Halon har fungerat och om
det är något som ni som kunder saknar eller har fått behov för
Med det sagt så önskar vi på Sunet er alla en lugn, varm, spam- & virus fri
sommar, i dubbel bemärkelse.
Glad sommar från Tomas, Fredrik, Salu, Eric och Tobias
---------------------------------------------------
Tomas Liljebergh
Productmanager SUNET mailfilter
Tomas at sunet.se
https://www.sunet.se/tjanster/mailfilter
Hej,
Några små uppdateringar/buggfixar som skett i Mailfilter-ng senaste veckan:
• Vi har skalat upp Halon-MTAernas resurser (dubblerat hårdvaran)
• “Corner-case”-bugg fixad för ratelimitern (när avsändande server bryter kopplingen mitt i sändningen, kunder ratelimitern göra fel och sätt samma gräns som domänen hade för en sender med egna gränsvärden)
• Block OfficeMacro AutoOpen var för “greedy” och kunde trigga på sånt som inte var office-dokument, det är nu tillrättat.
• Inställningen “Sender domain exists” är utökad så den inte bara Reject:ar avsändare vars domäner ger NXDOMAIN, den kommer även göra Defer om domänuppslag på avsändare ger SERVFAIL eller andra DNS fel tex. SERVFAIL (domänen är registrerad, men är delegerad ut i binära världsrymden (där ingen svarar)
Trevlig helg!
Mvh,
/P
Hej,
Vi har uppdaterat testmiljön för Mailfilter-ng med lite buggfixar och funktioner som efterfrågat:
* "Alternative recipient lookup" är nu en typen "list", så man kan lägga in flera servrar.
* Den 3:e “virusscannern” som är inbakad i CYRENs RPD-motor, går att stänga av separat
(om man har problem med att den blockerar inkommande / utgående epost med olika typer av bilagor)
Ni som har efterfrågat ovanstående funktioner får gärna testa dem och återkomma om de löser era problem.
Ytterligare ändringar & fixar som installerats i båda miljöerna:
* Bugg fixad som visar “Detailer” för alla events.
* Ratelimitern är nu inställd på tidsperioden per dygn som default.
* Mer statisk
Mvh,
/P
Hej
Två lite olika, men i någon mån relaterade, frågeställningar.
-----
För det första, rate limiting.
-----
Rate limiting i Halon fungerar ju rätt annorlunda jämfört med Canit. Vi har funderat lite på hur man kan lösa enstaka undantag till den generella rate limiten.
För en domän borde man kunna lägga in den domänen (med huvuddomänen som ägare) och justera enbart rate limit, med senderdomain som rate type. Vi funderar på att göra det för våra sympalistor t.ex.
För enstaka användare bör man kunna skapa en användare med rätt avsändaradress och justera rate limit för den användaren. Vi funderar däremot på om det skulle gå vägen att skapa dummyanvändare, typ "RateLimit5000", "RateLimit3000" osv, och koppla de enskilda avsändaradresserna som ska ha justerad rate limit till motsvarande dummyanvändare? Det förfarandet kan ställa till det om vi i framtiden vill låta användarna själva logga in och justera saker.
Det vi inte fått någon bra kläm på är om en ny, högre eller lägre, rate limit slår igenom direkt för en avsändare som redan slagit i taket på den befintliga, eller om det slår igenom först nästa gång. Dvs. kan man med omedelbar verkan släppa igenom brev som fastnat, eller måste man vänta till den valda tidsperioden passerat?
På samma sätt, om en avsändare fastnat pga spam rate limit så vill man kanske neka alla vidare brev istället för att pytsa ut dem över flera dagar. Går det på något sätt sätta rejekt direkt, eller behöver man tömma brevkön på e-postservern i vår ände?
Att tillfälligt justera rate limit för någon enstaka verkar inte vara möjligt i Halon, om man inte själv skriptar något via API:t. Eller tillfälligt ändrar rate limit för en användare och sedan inte glömmer att ställa tillbaka, vilket kommer glömmas förr eller senare.
-----
För det andra, användare
-----
Vad är för- respektive nack-delarna med att automatiskt skapa (eller inte skapa) användare för en domän?
Finns något "bäst-före-datum" för användare, eller ligger de kvar i systemet för all framtid?
Vi har för tillfället valt att inte skapa användare automatiskt. Som vår inloggning fungerar så är det inte e-postadressen man loggar in med, och det finns ingen direkt koppling mellan inloggningsnamnet och e-postadressen som kan göras utan att slå upp det i ett annat system. Så automatisk skapade användare (om det görs per mottagande e-postadress) skulle inte gå att logga in på. Dessutom kan en användare ha flera e-postadresser kopplade till sitt konto, även om de har en primär e-postadress som de skickar via (som i sin tur kan ändras om de byter tjänst inom universitetet.) För att en koppling ska kunna göras behöver det göras manuellt (eller möjligen via API:t) genom att lägga den faktiska e-postadressen som ett alias till inloggningskontot.
--
Dan Manell
Universitetsgemensam IT
Uppsala Universitet
När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/
E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy
