Avsender-alias for Mailman
Se EpostDriftMailman for kontekst.
Bakgrunn
Ved IDI har man av forskjellige, inkludert historiske, årsaker operert med flere gyldige adresser per bruker, hvorav de "ekstra" adressene typisk er forskjellige representasjoner av brukers personnavn. Typisk vil en bruker ha fornavn.etternavn, fornavn.mellomnavn.etternavn, fornavn.m.etternavn samt både "aa" og "a" transkribasjoner av "å", og tilsvarende for "æ" og "ø".
I tillegg til at epost-tjener aksepterer flere alias per bruker for innkommende epost, så vil epost-adresser i utgangspunktet også omskrives på utgående epost, slik at brukernavn@idi erstattes med fornavn.etternavn@idi.
Problem
Systemet beskrevet over kan være problematisk dersom mottaker forventer at en gitt adresse skal brukes, og blir forvirret dersom bruker veksler mellom "ekvivalente" adresser. Dette er noe som bruker gjerne ikke gjør ofte, men hos oss er det ikke uvanlig at brukere melder seg på epostlister med brukernavn@idi, men sender epost med fornavn.etternavn@idi som avsender. Dersom listen er sperret for avsendere som ikke er medlemmer, eller lignende, så vil eposten modereres, noe som medfører tidstap og ekstra arbeid for moderator.
Problemet forsterkes av epostlister med "automatisk" medlemskap; altså lister hvis medlemskap bestemmes av andre parametere enn hvorvidt bruker har meldt seg på listen eller ikke. Hos er seksjonlistene eksempel på slike lister. Dersom bruker meldes på listen med en annen adresse enn den vedkommende bruker som avsender på epost, så vil man få problemer.
Videre kan det nevnes at @stud og @idi-domeene delvis overlapper, så bruker X@stud er samme som X@idi, gitt at X eksisterer i begge domener.
Løsning
Mailman gir mulighet for å spesifisere avsender adresser som skal godkjennes til en liste til tross for at disse ikke er medlemmer. Det er dermed mulig å vedlikeholde settet av "ekstra" adresser på denne lista, slik at problemet beskrevet over omgås. Det er tungvint å holde denne listen konsistent for hånd, og det er heller ikke uproblematisk å gjøre dette automatisk, da denne listen bør kunne være et supersett av settet av "ekstra" adresser for medlemsmassen.
Vi har derfor valgt å løse problemet ved å gi Mailman muligheten til å sjekke for "ekstra" adresser direkte. Dette gjøres ved at epost-adressen mappes til brukernavn (evt at den kommer inn som brukernavn), og deretter mappes brukernavn til alle ekstra-adressene. Dette settet av adresser brukes så for å autorisere adressen for en gitt bruk.
Denne løsningen er transparent for medlemmer og liste-administrator.
Operasjon
I vanlig operativ drift er dette systemet vedlikeholdsfritt, utover vedlikehold av databasene.
Databasene som brukes er /etc/mail/paliases.db og /etc/mail/paliases_r.db. I tillegg brukes filen /etc/mail/paliases_r_tmp.db som en temporær fil mens man generer databasen, slik at klienter (Mailman) ser en konsistent versjon.
Begge databasene genereres fra smtp:/local/mail/src/Makefile, men paliases.db har lages ikke primært for dette systemet. Paliases_r er fullstendig gitt fra paliases, og krever ikke vedlikehold, mens paliases i noen tilfeller må gis en hjelpende hånd ved endringer. Dette vedlikeholdskravet er imidlertid ikke introdusert av dette systemet.
paliases_r kan regeneres slik:
smtp:~$ cd /local/mail/src smtp:/local/mail/src$ touch /etc/mail/paliases.db smtp:/local/mail/src$ make paliases_r.db
Det er også mulig å slette paliases_r.db for å tvinge regenering, men da vil databasen være utilgjengelig for Mailman og andre eventuelle brukere inntill den er regenerert (noe som tar mindre enn ett sekund ...).
En enkel konsistenssjekk på paliases_r er som følger:
smtp:~$ makemap -u hash /etc/mail/paliases_r |wc -wl
1662 4178
smtp:~$ makemap -u hash /etc/mail/paliases |wc -wl
2516 5032
smtp:~$ expr 4178 + 2516 - 5032 - 1662
0
Altså: summen av antall ord i paliases_r og antall linjer i paliases skal være det samme som summen av antall ord i paliases og antall linjer i paliases_r ...
Filer
- /etc/mail/paliases.db - mapper "ekstra" navn til brukernavn
- /etc/mail/paliases_r.db - mapper brukernavn til liste av "ekstra" navn
Begge filene må være leselige for alle, mode 644 eller "bedre".
Implementasjon
Det er to aspekter ved implementasjonen, nemlig
- generering av paliases_r, og
- sjekk av "ekstra" adresser i Mailman.
Genereringen av paliases_r er enkel, og utføres av en liten perl-snutt i smtp:/local/mail/src/Makefile.
Implementasjonen av denne funksjonaliteten i Mailman er forsøkt gjort så lite obtrusiv som mulig, og all logikk er lagt i en egen modul ( MailmanHacks.SenderMap ) for å endre footprint av Mailman minimalt.
I selve Mailman er endringen begrenset til noen få linjer i Mailman/Handlers/Moderate.py, i funksjonen process().
Stock kode:
# First of all, is the poster a member or not?
for sender in msg.get_senders():
if mlist.isMember(sender):
break
else:
sender = None
Hos oss er dette byttet med følgende:
# First of all, is the poster a member or not?
sender = None
for s in msg.get_senders():
if sender: break
for alias in MailmanHacks.SenderMap.expand_adress(s)
if mlist.isMember(alias):
# use the adress that is actually a member ...
sender = alias
break
Som det fremgår av koden over, så sjekker Mailman hvorvidt en liste av avsender (tatt fra headere fra innkommende epost) er medlem av listen, og bruker den første adressen som er medlem videre. Dersom ingen adresser er medlem, settes 'sender' til None.
Endringen gjort lokalt er å utvide denne sjekken til å ekspandere alle kandidat-avsendere til en liste av ekvivalente-adresser ( brukernavn samt eventuelle "ekstra"-adresser) og så sjekke disse for medlemskap. Den første adressen som er medlem bruker som sender videre i koden.
Ellers vises det til MailmanHacks for dokumentasjon av den modulen.
Videre utvikling
Fremfor å fikle med prosess()-logikken direkte, og fremfor å begrense denne utvidelsen til Moderate.py, så bør koden implemnenteres som en MemberAdapter, og da kanskje som et filter foran "stock" MemberAdapter, slik at man beholder fleksibilitet i "bakplan". Dette er dog noe mer arbeid.