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
Hej på er!
Dax för en liten uppdatering om status Mailfilter vs Mailfilter-ng…
Det är lite mindre en drygt 1,5 månad kvar innan den utsatta deadline:n för när alla Mailfilter-kunder bör vara migrerade från gamla lösningen.
En positiv sak är att det endast 3 st kunder kvar i gamla Mailfilter (CanIt), vilket vi tycker är mycket bra jobbat av er som migrerat över!
Så nu finns det flera som har (mer eller mindre) erfarenheter om hur det nya (Halon) fungerar för dem, i förhållande till det gamla (CanIt):
(SUNET), ORU, KAU, SMHI, DU, LNU
Mvh,
Fredrik
Hej,
Karlstad (KAU) var tidiga på att migrera in i Mailfilter-ng. Nått vi upptäckte under migreringen var att recipient verification inte fungerade/var aktiverat, så jag har tjatat lite på dem om att fixa till det :) Och Ulf & Mathias lyckades införa det ganska snabbt!
Det resulterade också i att gjort en enkel beskrivning på vad som behöver göras på alla exchange-servrar för att aktivera det.
Jag skrev om det och postade HOWTOn på SUNETs forum, här: https://forum.sunet.se/content/perma?id=3987
(Tack till Mathias & Ulf (KAU) för att ni delar med er av detta!)
Om ni själva inte gör recipient verification idag så är det hyfsat enkelt att implementera i Exchange.
Annars kan ni räkna med att jag kommer tjata på er om att fixa till det när ni migrerar :)
Vissa av er har andra SMTP-servrar framför Exchange (och andra epost-system) som bör ha motsvarande "recipient verification" -funktion påslagen.
Jag hoppas SU kommer dela med sig av hur de implementerat motsvarande funktion i Postfix (med uppslag mot LDAP),
ett mer avancerat alternativ till ovanstående, som t.ex. kan behövas när all epost inte ligger i Exchange...
Trevlig helg!
Mvh,
/P
Hej,
Under SUNET-dagarna har vi har jobbat på med Mailfilter-ng, här är några saker av de saker som fixats till:
* Uppdaterat alla MTAer till senaste releasen
* Strikt "recipient check" för att nya konton ska kunna automatskapas
* Förbättrade felmeddelanden
* Förbättrad loggning för Outbound epost-flödet
* Ny ratelimiter för DSN meddelanden (se https://en.wikipedia.org/wiki/Bounce_message)
* Säkert nått jag missat…
Tack till KAU samt ni andra som testar och ger feedback
Inom kort kommer även kontrollpanelen uppdateras till en ny release, med förbättrat API bl.a.
(btw. vi har skapat https://forum.sunet.se/s/mailfilter-ng/ om någon hellre vill ha nyheterna / diskutera Mailfilter-ng där)
Mvh,
/P
Hej,
Innan SUNET-dagarna så startade SUNET https://forum.sunet.se som en liten pilot för att utvärdera en ny samarbetesplattform, ett komplement till epost-listor & som ett alternativ till Slack. Jag la upp Mailfilter-ng som en grupp dit jag även push:at de senaste nyheter/uppgraderingar gällande Mailfilter-ng.
För er som är intresserade av att kika på det, så hittar ni det här (SAML-inloggning krävs):
https://forum.sunet.se/s/mailfilter-ng/
Mvh,
/P
Hej,
Vi har uppgraderat kontrollpanelen till MSUI 1.3.1,
som bla. innehåller en del API-förbättringar, stöd för "dotdomain routing” mm.
Release Notes:
* Updated dependencies
Backend
* Added support for validation of input and list type setting values
* Updated XHR endpoint for get domains, users and audit log now accepts multiple fields for filtering
* Updated get domains now accepts 'owner' and 'authentication' as filter option
* Updated audit log now includes source IP on successful login
* Updated alias validation now support dot domains (.example.com)
* Fixed session now uses a unique session name per instance
* Fixed session file storage now uses same TTL as session cookie
Frontend
* Added new FontAwesome icons
* Updated user form now has a "disable database login" option
* Updated domain form now support dot domains as alias
* Updated search component to allow multiple fields
* Updated settings page prompts when there are unsaved changes
* Updated settings page now show which settings and tabs that has unsaved changes
* Updated settings page now uses input validation for input and list setting types
Mvh,
/P
Hej
Lite fler frågor och funderingar och Default Settings.
* Vad är betydelsen med taggen "all" respektive "domain"?
* Om taggningen är viktig på något sätt, varför syns den bara under "Default settings" och inte när man tittar på en enskild domäns inställning?
* Vad är "system default" under Default settings? Det är uppenbarligen inte samma som "predefined-default" då "predefined-default" har ett flertal olika inställningar medan "system default" i princip är tom.
* Varför är inte "predefined-default" det samma som "system default"?
* Det verkar inte finnas något arv av inställningar, mer än att "Default settings" propagerar till underdomäner som har samma ägare och samtidigt inte har en egen "Default setting". Dvs. det verkar inte finnas något arv av "Default settings" så när man skapar en ny "Default settings" så startar man från noll (eller "system default" som i praktiken är tom f.n.) Eventuella ändringar direkt i en domän verkar heller inte ärvas till underdomäner.
Har vi förstått det rätt då?
* Det skulle vara önskvärt att t.ex. kunna ange en annan defaultinställning som grund när man skapar en ny default setting, eller kopiera från en befintlig, så man inte behöver börja från noll varje gång.
Går det att ordna?
* Skulle det gå att få en markering på de domäner som avviker från Default (t.ex. en asterisk efter namnet på default settings) så man lättare kan se vilka som skiljer sig?
* När man petar i settings så blir det lite lätt frustrerande när UIt känns inkonsekvent. Om det från början är ikryssat "Use system default" så kan man inte kryssa ur den, utan man måste ändra på inställningen först. Har man däremot ändrat inställningen och sedan kryssat i "Use system default" så kan man inte längre ändra inställningen (förrän man tryckt på spara eller laddar om sidan) utan då måste man kryssa ur kryssrutan först. Det enda som indikerar detta på sidan visade sig (noterade jag först idag) en ytterst liten kontraständring, från svart till mörkgrå för texten till kryssrutan och bakgrunden på inställningsknappen ändras från vit till ljusgrå. Jag har normalt färgseende och har ändå svårt att se denna minimala skillnad.
Går det att göra något åt det hela? Helst genom att det inte spelar någon roll i vilken ordning man klickar på saker. Alternativt att det alltid ska gå att klicka på kryssrutan "Use default settings" samtidigt som inställningsknappen bara går att klicka på om kryssrutan är urbockad. I sista hand att kontrastskillnaderna ändras till något mycket tydligare.
--
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
Vi i Uppsala är nyfikna om ni gör med ’spam action’ i konfigurationen på Halon. Standardvärdet är ju Reject vilket jag antar betyder att mailet inte släpps igenom. Frågan är om Halon är träffsäkert nog att vi inte behöver oroa oss över att riktiga/önskade mail filtreras bort? Hur resonerar NUNOC i frågan? och vad väljer ni andra för värde på spam action?
Bengt Smeds
Uppsala universitet
