Postfix softquota

Dokumentáció

A következő a feladat:

1. Postfix – maildir

2. Courier IMAP MTA

3. Virtuális user-ek – LDAP Active Directory

4. Spamszűrés

5. Hard és softquota a virtuális fiókokon

Az első négy pont megvalósításával nincs semmi különösebb probléma. Az utolsó pontnál ütköztem akadályokba.

( york | 2006. 01. 18., sze – 18:08 )

Sziasztok

Nem tudja valaki miert nem resze a VDA patch a postfixnek?

Ha a VDA kodja valamiert nem felel meg a postfix fejlesztoknek akkor miert nem irjak meg ezt a szinte nelkulozhetetlen szolgaltatast?

York.

( necrolite | 2006. 01. 18., sze – 18:13 )

Vegigolvasva a leirast teccett a dolog bar nekem a kvota ezen ertelmezese idegen.

A Lotus Notes kvotaja miszerint is ilyenkor levelet fogadni tudok (azaz a kvota akar tul is lepheto) de kuldeni nem, sokkal eletszerubb. Nem keves letfontossagu level (Controlling, Purchasing, Management) level menne ilyenkor vissza es nem hinnem hogy a kov. hetekben be kellene meg mennem a gyarba dolgozni ha ezt beujitanam... So-so technikailag cool de ahogy a greylist/blacklist nem egy 100% megbizhato ez is a valo eletben elegge visszauthet...

Wietse Venemanak több indoka is volt erre. GOTO postfix archívumok.

A softquota: applikációk által alkalmazott kvóta

hardquota: operációs rendszer által támasztott kvóta

Abban az értelmezésben, ahogyan a postfix is használja.

maildropnál az a titok, hogy egy maildropnak a postfixtől kell megkapnia a levelet. Azaz meg kell oldani, hogy olyan user kapja meg, akinek maildrop fogja kézbesítei a levelet. Hátránya: több réteg. Előnye: nem kell belenyúlkálni a postfixbe és állandóan verziókövetni.

( rage | 2006. 01. 18., sze – 22:02 )

VDA oldalan tokeletesen le van irva, hogy mit csinalnak ok:

-Mailbox / Maildir size limit, known also as "soft quota", to avoid user take all you disk space

-Customizable "limit" message when the soft quota limit is reached. NOTE: message is sent to senders, but NOT to the owner of the mailbox.

Hát pont ezaz! Pont ez nem tetszik nekem. Ha betelik a user fiókja és nem kap semmilyen értesítést erről, akkor egyszer csak azt veszi észre, hogy nem kap egyetlen levelet sem. És ennyi. Max ha az, aki levelet akar neki küldeni valamilyen más módon nem értesíti a címzettet, hogy 'Hé öreg! Betelt a postafiókod. Takarítsd már ki!'.

Végül is így is működhet, de nem túl szép :-)

Nekem is ez a megoldás tetszene a legjobban. Postfix adja maildropnak, ő pedig dobja a maildir-be. Viszont maildrop-nak hogyan tudod szűkíteni a keresési feltételt LDAP-ból?

Pl.: (&(|(sAMAccountName=%s)(mail=%s)(wWWHomePage=%s))(objectClass=user)(userAccountControl=512))

Nem találtam olyan példát, ahol az LDAP_MAIL-nek komplexebb feltételt lehetett volna megadni. Bár lehet, hogy rosszul közelítettem meg a dolgot.

Mondjuk a posfix hackelését meg lehetett volna kerülni azzal, hogy bedobok egy scriptet a cron.daily-be, ami lecsekkolja a postafiókok méretét és ha valaki túllépett egy méretet, akkor kapja a figyelmeztetést.

De ez már így alakult :-) Minden esetre nekem ez a postfix-es megoldás jobban tetszik!

közben felmerült bennem egy kérdés, ami nem hagy nyugodni, mivel ettől is függ a válasz, hogy miként kezeled ezeket a dolgokat?

Te miként autentikálod imapra a felhasználókat? Csak mert LDAP-nál akkor kell egy mezőt használni és azt mindenképpen töltögetni kell az AD-ben, mint mondjuk a posixheztartozó attribokat. Ez nekem nem a legbarátibb :)

Ha jól értem, akkor mindenkinek egy kvótája van. Akkor miértnem volt jó pam-winbind és a local daemon? Meg van oldva az azonosítás és a user kezelés is. Azzal még más egyéb dolgokat is le tudsz kezelni. Venema szerint a kvótakezeés az legyen a rendszer része vagy LDA-ké. A postfix egy smtp(-lmtp-qmqp) szerver. Valahol igaza van.

Ha különös oka volt a virtualnak, akkor ok, maradjon. A virtuallal lemondasz a procmail/maildrop filteringről, ugye tudod? Gondolom itt nem ez volt a legfőbb gond.

Időval meg kell majd nézni alternatív megoldásokat, mint a Cyrus, hátha ismét használható :)

Télleg, Dovecotot használta már eredményesne valaki? Elméletileg nem ismeri a kvótát.... de hátha mégis.

A userek sAMAccountName-el jelentkeznek be és utána a courier-authlib bindeli össze a levelezőben megadott jelszóval. A sAMAccountName ugye mindenképp kitöltésre kerül, tehát nem igényel plusz adminisztrációt (max. ha az aliasokat is felviszem, de az sem tekintendő plusz adminisztrációnak, hiszen valahova úgy is fel kell vinni őket). Remélem jól értettem a kérdést :-)

A virtual-ra azért van szükség, hogy lokálisan semmiképp ne lehessen bejelentkezni a mailserverre mailuserként, mivel a szerver kint lóg a neten. Ok, be lehetne állítani /bin/false-ra a shell-t, így viszont a userek egyáltalán nem léteznek lokálisan a mailserveren.

A Cyrus-on gondolkodtam, de valamiért nem tetszett. Már nem emlékszem, hogy miért :-)

Miert mondana le a procmailrol? Postfixet ugyan meg eletemben nem hasznaltam, de qmail-ldappal mar csinaltam ilyet, ott a deliveryProgramPath mezot megfeleloen kitoltve meg tudtad hivni a procmailt. Most rakerestem a postfixes ldap semara, es abban is van ilyen. Ez nem mukodne? Pedig filoztam, hogy postfixezni kellene qmail helyett, mert korulmenyes, a postfix pedig rengeteget fejlodott, miota utoljara neztem.