Lähes täsmälleen kaksi vuotta sitten eli muistaakseni 14.10.2016 tein huvikseni hetken mielijohteesta hyvin pienen patchin Sendmail 8.15.2 MTA-ohjelmistoon. Mieleeni tuli tuolloin jostain syystä se tosiasia, että Cyrus IMAP järjestelmä tukee LMTP-protokollan IGNOREQUOTA-laajennosta, mutta Sendmailistä en löytänyt mitään tapaa saada se käyttöön. Ilmeisesti ominaisuus ei olekaan siinä lainkaan toteutettuna. Mikään kovin tärkeä ominaisuushan IGNOREQUOTA ei toki ole, mutta voi se silti olla joissain tapauksissa varsin hyödyllinen - riippuen aika paljon ympäristöstä.
Jos kyseessä on hyvin laaja sähköposti-infrastruktuuri, niin voisi olla kannattavaa rakentaa automatiikka, joka lähettää "Olet ylittänyt levytilasi" viestejä kun se havaitsee, että jonkun käyttäjän mailboxin quota on ylitetty. Siihen toimintaan IGNOREQUOTA LMTP-laajennos tuntuisi fiksummalta vaihtoehdolta kuin se, että quotarajoitus hetkellisesti kytkettäisiin pois, laitettaisiin varoitusviesti ja sitten taas quotarajoitus palautettaisiin. Myöskään se ajatus, että käyttäjän inboxiin appendoitaisiin viesti ohi normaalin LMTP-kanavan, ei tunnu kovin elegantilta. Eli yritän tässä sanoa sitä, että IGNOREQUOTA ei ole ihan täysin turhakaan ominaisuus, mutta en toki väitä, että se olisi keskeinenkään. Juuri sen vähäisen käyttötarpeen vuoksi Sendmailin kehittäjätiimi ei ehkä ole halunnut toteuttaa sitä.
Voisikin muuten olla ihan kohtuullisen mielenkiintoista vilkaista miten Postfix on hoitanut IGNOREQUOTA laajennoksen toteutuksen vai puuttuuko se kenties siitäkin.
Oli miten oli, niin aiempi Sendmail-artikkelini oli siinä mielessä kammottava, että C-koodimuutoksen ja keksimäni uuden Q-mailerflagin esittelyn jälkeinen pohdintaosuus oli aika juosten kustua soopaa. En ilmeisesti ollut jaksanut paneutua asiaan sen paremmin, vaan katsoin vain äkkiä, että noinhan sen ominaisuuden sai helposti lisättyä C-koodiin ja sen jälkeen mielenkiintoni asiaa kohtaan kai jo lopahtikin. Muistan sorkkineeni vain hyvin pikaisesti cyrusv2 mailerin määrittelyä ja sitten totesin testikoneella, että IGNOREQUOTA LMTP-protokollalaajennus tosiaan toimi oikein kun Sendmail oli LMTP-clienttinä ja Cyrus lmtpd vastaanottavassa päässä. Ja miksei olisi toiminut, sillä muutos oli äärimmäisen yksinkertainen.
Äsken sain kuitenkin korjattua Sendmail-artikkelini paljon fiksumpaan muotoon ja nyt siinä esitetty toteutusmalli on huomattavasti järkevämpi kuin aiemmin mainittu. En kuitenkaan poistanut vanhoja melko tyhmiä juttujani, vaan jätin ne sinne, sillä voi niissä kuitenkin jotain informaatioarvoakin olla - joskaan ei taatusti paljon.
Lisäsin uuden päivitetyn sisällön vanhan tekstini loppuun. Tässä on linkki korjattuun artikkeliini.
LISÄYS YLLÄ OLEVAAN BLOGIKIRJOITUKSEEN 2018-10-13: Itseasiassa ei se vanhakaan Sendmail-pohdinta niin kamala ollutkaan kuin muistelin. Alkuperäinen ajatus erillisen IGNOREQUOTA kykyisen Sendmail-instanssin ajamisesta vaikkapa kokonaan omassa, dedikoidussa virtuaalikoneessaan olisi ihan järkevää. Virtuaalikoneen saa pystyyn hetkessä ja resursseja nykyään riittää.
Se Sendmail siis lähettelisi vain niitä "Ylitit quotasi"-viestejä ja niitä toimitettaessa olisi aina IGNOREQUOTA laajennos kytkettynä päälle LMTP-protokollassa. Silloin ei tarvitsisi ollenkaan manageroida erillistä tietokantaa, joka kontrolloisi kenelle laitetaan viestit IGNOREQUOTA laajennoksella ja kenelle ei.
Sitä paitsi kun laajennoksen laittaa päälle vaikka tänään mainitsemaani /etc/mail/ignorequota.db tietokantaan, voi käydä niinkin, että vastaanottajan postilaatikkoon ehtii luikahtaa samassa aikaikkunassa muitakin viestejä kuin se "Ylitit quotasi". Se ei tietysti olisi mikään maailmanloppu, mutta kuitenkin rikkoisi perusperiaatetta, että jos quota on ylitetty, niin viestejä ei toimiteta - paitsi kenties näitä ylläpitäjien tiedotuksia. Toinen haittapuoli Sendmailin päässä olevassa tietokannassa on se, että sitten sitä pitää tosiaan manageroida eli kun noottia on laitettu tilan ylityksestä, sen jälkeen tietokanta-avain pitää poistaa, jotta quotarajoitus olisi taas voimassa.
Siispä tarkemman ajattelun jälkeen olenkin sitä mieltä, että tämä uudempi ratkaisumalli ei välttämättä olekaan valtavasti hienompi. Mutta se hyvä puoli tässä säätämisessä oli, että nyt tiedetään ainakin vaihtoehtoinen malli mikäli sillekin olisi jossain tarvetta.
Lisäksi pitää muistaa se, että Andrzej Filipin yksinkertainen, mutta äärimmäisen hieno Mailertable Rule Set on luonteeltaan täysin geneerinen. Eli nyt ainakin saatiin selville se, että kyseinen patchi toimii yhä edelleen hyvin ja sillä saadaan tarvittaessa tehtyä /etc/mail/mailertable.db tietokannan kautta periaatteessa millainen reitityslogiikka tahansa. Voimme valita sieltä oman custom rulesetin ja välittää sille parametrin. Eli FEATURE(`mrs') mahdollistaa paljon, paljon muutakin kuin tuon IGNOREQUOTA kontrolloinnin tänään esittämälläni tavalla. Valinnanvaraa on tarjolla vaikka millä mitalla.