Hej Dan,
On 25 May 2021, at 14:41, Dan Manell <dan.manell at
uu.se> wrote:
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.
Jaja och lägga in dem som alias för respektive dummy användare, blir ju strukturerat.
Problemet med det är att du inte kan söka på alias-adresser i MSUI just nu, utan då måste
du använda API:et för att söka efter under vilken dummy-användare en epost-adress ligger,
alt gå in i varje dummy-användare och kika manuellt.
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?
Inställningen slår igenom så när som på någon minut för hela klustret, men det som avgör
är ju att alla de som fastnade hamnar i en omsändningskö som kan ta lite tid på sig, så i
realiteten är det omsändningshastigheten i mailkön som styr.
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?
Blir de spam-klassade med säkerhet, borde de kastas direkt iof. Har sett det när DU la
över sin utgående trafik .
Lite osäker på vilken nivå “spam” ligger på, vad det gäller den utgående eposten… Nått jag
får återkomma om.
Att tillfälligt justera rate limit för någon enstaka
verkar inte vara möjligt i Halon
Vad syftar du på här? Är det TTL du menar?
, 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?
I huvudsak för att användarna ska kunna logga in i systemet och titta på/ändra sina
inställningar (förutsatt att epost = eppn)
Det andra är att ni får era användares epost-adresser automatiskt upplagda, så ni kan
sätta special-regler på dem.
Finns något "bäst-före-datum" för användare,
eller ligger de kvar i systemet för all framtid?
För alltid som det är just nu.
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.
Om er IdP släpper “mail” attributet till Halons SP, så kommer e-postadressen läggas till
som “alias” under användaren när den loggar på kontrollpanelen, och på så sätt så får
användaren möjlighet att ställa in regler för sin egna epost-adress.
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.
Precis, just knyta alla ej-primära epost-adresser till kontot måste göras via API:et idag.
Mvh,
/P
--
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