Stavíme poštovní server: Nastavení správy ACL

5. 3. 2010 | Lukáš Jelínek | Sítě | 19937×

Nastavení správy ACL

Poslední ze tří kroků konfigurace je nastavení správy ACL. Informace o tom, jaká přístupová práva má kdo nastavena, je totiž potřeba někde ukládat – a to „někde“ se musí nastavit. Možností je více. V níže uvedeném řešení se ACL ukládají přímo v jednotlivých schránkách (jejichž uživatelé zapnuli sdílení), konkrétně v souborech nazvaných dovecot-acl. Je tu ale ještě jeden problém – sdílené složky se nezobrazují uživatelům, jimž byly nasdíleny (uživatelé musí přímo zadat jejich cestu, na výpisu složek je nemají).

Tento problém lze vyřešit globálním úložištěm ACL, kde budou uloženy informace, kdo komu sdílí přístup (samotné ACL informace ovšem zůstávají uloženy u jednotlivých schránek). V jednoduchých případech (tj. když se sdílí jen málo složek a jen malému počtu uživatelů) si lze vystačit s obyčejným souborem:

plugin {
  acl = vfile
  acl_shared_dict = file:/var/mail/shared/shared-mailboxes.db
}

První parametr říká, jak budou uloženy informace o ACL. V tomto případě se bude jednat o soubory pro jednotlivé složky; nevyužívají se globální přístupové seznamy, které by definoval administrátor a měly by přednost před tím, co si nastaví jednotliví uživatelé. Druhý uvedený parametr je cesta k souboru se seznamem nasdílených složek.

Při rozsáhlejším využití takové řešení brzy narazí na problémy s výkonem. Pak je vhodnější, aby byly informace uložené v databázi. Lze použít různé databáze (samozřejmě podle toho, jak byl Dovecot zkompilován – viz starší díly seriálu). Jedna z možností je například použít SQLite, což je výhodné proto, že není třeba řešit žádný samostatný databázový server, přístup do databáze je přes knihovní funkce.

plugin {
  acl = vfile
  acl_shared_dict = sqlite:/etc/dovecot/sqlite-acl.conf
}

Tím je vyřešena konfigurace na globální úrovni, teď je potřeba nakonfigurovat přístup k databázi. Uvedený soubor /etc/dovecot/sqlite-acl.conf musí obsahovat údaje potřebné pro správnou práci s databází SQLite:

connect = /var/mail/shared/acl.sqlite

map {
  table = acls
  pattern = shared/shared-boxes/user/$to/$from
  value_field = valid
  fields {
    mbfrom = $from
    mbto = $to
  }
}

Tento soubor definuje jednak cestu k databázovému souboru (parametr connect) a dále pak mapování databáze na rozhraní programu Dovecot. Tabulka se bude jmenovat acls, vzorek pro dotazovací klíč odpovídá formátu používanému i při ukládání do souboru. Podle dotazovacího klíče se vrací hodnota, ta je u ACL dotazů vždy rovna 1 – v tomto případě to bude atribut valid. Atributy mbfrom a mbto jsou mapovány na proměnné from a to. Při použití této konfigurace bude SQL definice tabulky vypadat takto:

CREATE TABLE acls (
  mbfrom VARCHAR(100) NOT NULL,
  mbto VARCHAR(100) NOT NULL,
  valid CHAR(1) NOT NULL DEFAULT '1',
  PRIMARY KEY (mbfrom, mbto)
);

Do této tabulky si bude Dovecot ukládat stejné údaje (tedy existující sdílení) jako v případě souboru. Databázi je samozřejmě potřeba vytvořit předem a nastavit jí přístupová práva pro čtení i zápis uživateli, pod kterým běží procesy pracující nad schránkami (tj. vmail).

Další důležité informace

Při vytváření složek prostřednictvím protokolu IMAP se práva dědí v tom smyslu, že pro nově vytvořenou složku se zkopíruje kompletní ACL ze složky nadřazené. Při změně ACL u nadřazené složky se však už ACL u potomků nemění.

Nepříjemnou vlastností využívání ACL (resp. nastavování ACL přes protokol IMAP) je špatná podpora u klientského softwaru. Například Mozilla Thunderbird (a to i ve verzi 3.0) podporuje ACL jen ve smyslu zobrazení – nastavovat nic nejde. KMail ve verzi 1.13 podporuje do určité míry i nastavování ACL (ve smyslu nastavování některých druhů práv), nicméně občas uživatele „odmění“ zhroucením celého programu. Lze však očekávat, že se podpora v blízké budoucnosti zásadním způsobem zlepší.

Možnosti ohledně správy ACL jsou nesrovnatelně větší. Existuje možnost (pro správce) vytvářet skupiny, nastavovat jim práva a vkládat do nich uživatele. Další možností je přístup ověřeným uživatelům, případně všem uživatelům – to je však standardně z bezpečnostních důvodů zakázáno a pokud by ho někdo chtěl umožnit, je třeba v konfiguraci v sekci plugin nastavit acl_anyone = allow.

Veřejné složky

V některých případech je výhodné mít na serveru i složky, které jsou veřejné a nejsou spjaty s žádným konkrétním uživatelem. Příkladem jsou složky se zprávami, které se týkají celé firmy. Jinou situací je využití IMAP složek k jiným účelům, tedy například pro uložení adresáře nebo kalendáře (toto využívají některá groupwarová řešení).

Pro veřejné složky jsou určeny samostatné jmenné prostory (jeden či více, podle potřeby), přes které se tyto složky zpřístupní. Že jsou složky veřejné, vůbec neznamená, že by nešla nastavovat práva nebo že by měl automaticky každý oprávnění dělat tam cokoliv. Tak to samozřejmě není a běžná bude naopak situace, kdy uživatelé budou mít právo jen číst, případně přidávat, ale nikoli měnit a mazat. Rozdíl je však v tom, že tato oprávnění může nastavovat pouze správce.

Základem veřejných složek je veřejný jmenný prostor. Jeho konfigurace může vypadat například takto:

namespace public {
  prefix = public/
  separator = /
  location = maildir:/var/mail/public/Maildir:INDEX=/var/mail/virtual/%d/%n/public
  subscriptions = no
  list = children
  inbox = no
}

Od jmenného pro sdílení se to liší jen málo – typ jmenného prostoru je jiný, jiné je i úložiště (napevno definovaný adresář) a umístění indexů. Nyní je potřeba zajistit, aby měl Dovecot (resp. příslušný uživatel, tedy vmail) přístup k úložišti. Prefix je zde public/, ale není to žádné dogma, může být i jiný, podle potřeby.

V úložišti se pak vytvoří potřebné složky (například pokud potřebujeme složku Abcd, vytvoří se adresář .Abcd a v něm nejlépe hned trojice adresářů new, cur a tmp, všechny samozřejmě se správným souborovým vlastníkem a právy).

V každé složce je pak potřeba vytvořit soubor dovecot-acl s vlastním ACL. Pokud soubor zůstane prázdný, nebude mít přístup nikdo. To ale obvykle nechceme, proto lze definovat potřebná práva – k tomu však musíme znát syntaxi souboru. Tady je jednoduchý příklad:

user=admin@moje.domena lrwstipekxa
user=franta@moje.domena lrwstipe
authenticated lr

Tento soubor definuje práva tak, že správce (admin@moje.domena) má všechna oprávnění, uživatel franta@moje.domena může jakkoli manipulovat se zprávami (nesmí však nijak manipulovat se složkami) a všichni ověření uživatelé mohou pouze zjišťovat existenci složky a číst obsažené zprávy. Použití authenticated samozřejmě předpokládá povolení této možnosti v konfiguraci – viz výše.

Jak si můžete všimnout, syntaxe se vždy skládá z uvedení subjektu (obecně nebo s identifikací) a masky konkrétních práv tvořené znaky udávajících jednotlivá oprávnění. Přesný význam typů subjektů a písmen používaných v masce najdete v dokumentaci k programu Dovecot.

Stejným způsobem lze v případě potřeby upravovat práva ke sdíleným složkám uživatelů (soubory dovecot-acl jsou stejné) nebo definovat globální ACL. Opět odkazuji na dokumentaci.

Po změně souboru dovecot-acl je vždy potřeba smazat soubor dovecot-acl-list, změny práv totiž mohou mít vliv na to, co se bude předkládat jako seznam složek klientům.

Na závěr ještě jednu důležitou informaci – pokud něco ohledně sdílení nebo ACL nefunguje správně, pak je to velmi pravděpodobně chyba v konfiguraci serveru nebo v implementaci klienta. Až teprve o hodně méně pravděpodobná je chyba serveru. Dobrým vodítkem při hledání chyb je sledování a záznam IMAP komunikace (například pomocí programů tcpdump nebo Wireshark) a porovnávání s tím, co to má podle specifikací dělat.

Konfigurace záložního serveru

Příštím dílem se seriál vrátí zase trochu více do oblasti přenosu zpráv. Tématem totiž bude konfigurace záložního poštovního serveru. Na první pohled triviální věc skýtá některá úskalí, která pak (pokud nejsou včas rozpoznána a eliminována) zcela oprávněně vrhají na celou koncepci používání záložních serverů špatné světlo.

       

Komentáře

[pet]

Jak se chová indikace nová / přečtená u sdílených složek? Je to tak, že když někdo přečte, tak je přečtená, nebo ji má každý jako novou dokud ji nepřečte? Nebo lze toto chování nastavovat?

[Luk]

Toto chování lze nastavovat. V té podobě, jak jsem to popsal, se stav přečtení uchovává pro každého uživatele samostatně. To zajišťuje ten parametr INDEX, který je definován pro každého uživatele specificky. Pokud by explicitně definován nebyl nebo byl definován jako společný, bylo by to společné pro všechny uživatele. Stav přečtení navíc může měnit jen uživatel, který má oprávnění "s" (teď si tedy nejsem úplně jist, jestli toto oprávnění není implikováno nějakým jiným, např. "w").

[Kamil]

Zdravim, mam nastaveno podle navodu, ale kdyz jeden uzivatel oznaci zpravu jako prectenou, maji ji prectenou i ostatni. Pritom kazdemu se ve slozce /shared vytvari vlastni index. Proc? Dik.

[Luk]

Takhle by se to chovat nemělo. Až budu mít čas, podívám se na to, co se tam přesně děje (a má dít).

[Kamil]

jj, budu rad. Dik.

[pee]

Vypada to, ze podle tohoto musi byt jeste ve sdilene "slozce" vytvoren soubor dovecot-shared.

[Luk]

Jak jsem se na to teď díval, tak bude opravdu ještě potřeba vytvořit tento soubor (když se vytvoří v kořeni Maildiru uživatele, bude se automaticky kopírovat do nově vytvářených složek), Dovecot ho bohužel sám nevytváří. Pozor na práva - vlastníkem musí být uživatel, který pracuje na úložištěm pošty (např. vmail) a práva mají být 0640 nebo 0660. Ještě zbývá vyřešit problém, jak zajistit, aby se u nově vytvořeného uživatelského účtu soubor sám vytvářel (aby se to nemuselo dělat ručně).

[Kamil]

Tak, to funguje. Stav precteni je uz u kazdeho individualni. Jen ale pro zmenu nemuzu prijit na to, jestli lze (a jak) nastavit, aby si kazdy mohl tu postu smazat jen u sebe. Ten kdo ma zakaz mazani, postu vidi porad, pokud ji smaze nekdo s pravy mazani. Nejak se v tom neorientuju..

[Luk]

Teď tomu trochu nerozumím. Jsou dvě operace mazání - označení za smazané (příznak \\Deleted) a úplné smazání. Kromě toho existuje ještě přesunutí do koše, které se standardně (např. v Thunderbirdu; pozor, například Outlook Express to neumí!) realizuje jako zkopírování do složky koše (Trash) a označení za smazané.

Pokud se zpráva smaže úplně, pak je prostě smazaná a nikdo ji nemůže vidět. Pokud se označí za smazanou, pak by ji tak měli všichni uživatelé vidět (nebo ji nevidět vůbec, podle nastavení klienta - Thunderbird takové zprávy standardně nezobrazuje). Nevím o tom, že by se označení zprávy za smazanou v Dovecotu rozlišovalo podle uživatele (i v případě, že se rozlišuje označení zprávy za přečtenou). Nicméně dokumentace o tom mlčí a nezkoušel jsem to, takže to není úplně jisté.

[Martin]

Dobrý den,

užitečný článek, sdílení e-mailu více uživateli se pokouším uspokojivě vyřešit už delší dobu, zatím bez výsledku

O ACL ve spojení s poštou jsem dosud nevěděl, takže mám další námět pro pokusy.

Mám dotaz - je možné nastavit ACL tak, aby skupina uživatelů měla přístup k poštovnímu účtu s několika složkami, všichni by mohli zprávy číst, označovat za přečtené a přesunovat mezi jednotlivými složkami (např. doručené/vyřízeno/spam/smazat). Nebylo by ale možné e-maily smazat, resp. to by směli jen někteří pověření uživatelé.

Cílem je, aby se žádný e-mail nemohl "ztratit", protože běžný uživatel by jej mohl nanejvýš přesunout do chybné složky (spam/smazat), ale skutečně smazat by mohl jen pověřený uživatel.

Dá se to pomocí ACL provést?

Díky za odpověď

Martïn

[..... Izak .....]

Zkus KOLAB ... pravda, je to spise nahrada exchange, ale tohle tam funguje, vcetne kalendaru a jejich sdileni.

[Martin]

díky za tip; ještě to zkusím, jestli nebude stačit jenom ACL

[Luk]

Dá se to pomocí ACL provést?

To se dá provést poměrně jednoduše, a to například tak, že se definuje veřejný účet, v něm potřebné složky a definují se k nim ACL pro dvě skupiny, např. users a admins. První skupina bude mít všechna práva kromě "a" (administer) a "e" (expunge, tj. skutečné smazání), druhá bude mít i tato práva. Pak budou moci uživatelé ve skupině admins dělat všechno a uživatelé ve skupině users nebudou smět měnit práva a mazat zprávy (budou je moci označit za smazané, což je potřeba k tomu, aby šla zpráva přesunout - přesun = zkopírování + označení za smazané). Členství ve skupinách je třeba řešit ve správě uživatelů - seznam skupin oddělených čárkou se vrací v atributu acl_groups.

[Martin]

super, mockrát děkuji

[pee]

V prvni rade moc diky za prinosny serial Chtel bych se ale zeptat, umisteni schranek mam v teto strukture:

/home/vmail/domains/domena1/user1/mail
/home/vmail/domains/domena1/user2/mail
/home/vmail/domains/domena1/user3/mail

/home/vmail/domains/domena2/user1/mail
/home/vmail/domains/domena2/user2/mail
/home/vmail/domains/domena2/user2/mail
atd..

a v konfigu jsem tedy vyplnil:

location = maildir:/home/vmail/domains/%%d/%%n/mail/Maildir:INDEX=/home/vmail/domains/%d/%n/shared/%%d/%%n/mail

Je to dobre?

Musim vytvaret jeste rucne nejake dalsi adresare do mailboxu uzivatelu?

diky diky

[Luk]

Jak na to koukám, tak mi není jasné, proč je pod adresářem uživatele adresář mail a pod ním ještě Maildir. Není to zbytečné? Jinak nic dalšího by nemělo být potřeba vytvářet - Dovecot si potřebné adresáře vytvoří sám.

[pee]

Pravda, je to zbytecny, ale duvod je historicky z dob, kdy jsem dovecot nastavoval podle nejakeho navodu, kde to tak bylo. Jeste jsem pridal databazi zdileni do vfile, podle navodu a v thunderbirdu uz je vypsano, ze slozka je osobni a neni sdilena. Jak ale ted to sdileni zapnu (kdyz to nejde primo v TB 3.x)?

[Luk]

Jak ale ted to sdileni zapnu (kdyz to nejde primo v TB 3.x)?

Zapnout sdílení (resp. přidělovat práva - jakmile jsou přidělena nějaká práva, složka je sdílena) lze například přes KMail nebo Mulberry. Možná to bude umět i Evolution, ale nepoužívám ho, tak nevím.

[pee]

aha, a co to napsat primo do toho konfiguraku nekam (snad do toho vfile), ale nevim jak.. abych to mohl aspon vyzkouset.

[Luk]

Dá se to nastavit i ručně, způsobem popsaným u veřejných složek. Stačí vytvořit ve složce soubor dovecot-acl a do něj vložit nějaký seznam práv, třeba něco jako toto:

user=franta@moje.domena lrs

Tím se uživateli franta@moje.domena přidělí uvedená práva (zjištění složky, čtení, nastavování příznaku přečtení). Pak je potřeba smazat ve schránce soubor dovecot-acl-list (Dovecot si vytvoří aktualizovaný) a ještě aktualizovat seznam sdílení. Pokud je tento v souboru, přidají se tam dva řádky tohoto typu (sdílená složka patří uživateli sdilejici@moje.domena):

shared/shared-boxes/user/franta@moje.domena/sdilejici@moje.domena
1

Ta jednička na druhém řádku je důležitá, střídají se totiž řádky klíč-hodnota (a hodnota je tady vždy 1).

[pee]

diky moc, funguje

[pee]

Tak bych mel jeste jeden dotaz. V clanku se pise, ze nasdilene slozky nejdou vylistovat (k odberu), pokud neni vytvoren seznam sdileni shared-mailboxes.db. Me se ale vytvori (s obsahem, jak pisete), ale Thunderbird nevidi ve "spravci odebirani" tyto nasdilene slozky. Kde delam chybu?

[pee]

vyreseno

v configu dovecotu jsem mel tu cestu spatne, to co je tucne neni soucasti meho umisteni, takze jsem odstranil (myslel jsem spatne, ze se NEjedna od podadresar /Maildir):

location = maildir:/home/vmail/domains/%%d/%%n/mail/Maildir:INDEX=/home/vmail/domains/%d/%n/shared/%%d/%%n/mail

[BoB]

Reknete mi nekdo (pro inspiraci), jak nastavujete prava uzivatelum napr. na schrance info@example.net?

[Luk]

V jakém smyslu? Jako jak se to udělá, nebo jaká práva má kdo získat? Jak se to udělá, to záleží na klientovi. Např. v Mulberry kliknu pravým tlačítkem na složce, dám Details..., přejdu na kartu Access Control List, tam stisknu Add user..., napíšu jméno uživatele a naklikám potřebná práva. Pokud potřebuji změnit práva některému existujícímu uživateli, na té kartě kliknu u daného uživatele na příslušná zaškrtávátka. To je celé.

[BoB]

Ve smyslu, jaka prava ma kdo ziskat

[Luk]

Vždyť to vyplývá z toho, jakou má kdo roli. V článku jsem uvedl i konkrétní příklad. Požadovaná práva pro konkrétní IMAP operace jsou uvedena v části 4 v RFC 4314.

[BoB]

No zatim jsem v tom nejak zamotanej. Jednomu "adminovi" jsem dal vsechny prava (resp. lrwstipekxa). Userovi jsem chtel dat jen pravo na zmenu priznaku precteni (resp. lrs). Kdyz ale neco user smaze (napr. ve squirrelmailu), mail tam zustane (protoze nema prava - to je ok), ale zaroven se mu jeste presune do kose (takze user, kterej nebude vedet, ze nemuze mazat, bude 100x mackat smazani zpravy a 100x se mu vytvori v kosi). Potom, jakmile nema pravo mazat ze serveru (parametr e), email mu nezmizi ani kdyz ho smazne admin (vytvori se u nej priznak D). To jen tak pro zacatek (jestli budete ochotny dal radit)

[Luk]

Kdyz ale neco user smaze (napr. ve squirrelmailu), mail tam zustane (protoze nema prava - to je ok), ale zaroven se mu jeste presune do kose (takze user, kterej nebude vedet, ze nemuze mazat, bude 100x mackat smazani zpravy a 100x se mu vytvori v kosi).

Tohle je proto, že klient maže právě tak, že zprávu zkopíruje do koše a pak označí jako smazanou. Jsou dvě cesty, jak to vyřešit. Čistší je dát uživateli právo "t", které umožňuje označit zprávu jako smazanou (to není destruktivní, není důvod toto právo zbytečně odpírat). Druhou možností je použít plugin (vytvořený kvůli OE), který změní chování Dovecotu (teď si ale nejsem jistý, jak interaguje s právy).

Potom, jakmile nema pravo mazat ze serveru (parametr e), email mu nezmizi ani kdyz ho smazne admin (vytvori se u nej priznak D).

To je vlastnost. Klient se musí nastavit tak, aby nezobrazoval smazané zprávy, tj. ty s příznakem \Deleted (např. Thunderbird je nezobrazuje, Roundcube v defaultu ano, ale jde to vypnout, u OE je bohužel zobrazuje vždy; u Squirrelmailu si už nepamatuji, jak to je).

[BoB]

No dejme tomu, ze Squirrelmail nejak presvedcim, aby ty oznackovane D zpravy nezobrazoval. K cemu pak ale ma admin to pravo e, kdyz zpravu se serveru stejne fyzicky nesmaze? Nechci, aby mi tam "smazane" zpravy zabiraly misto a opravdu zmizly

[Luk]

Právo "e" dává možnost provést operaci EXPUNGE (což není totéž jako "smazání" formou nastavení \Deleted operací STORE, případně při operacích APPEND nebo COPY). Tato operace se standardně neprovádí při smazání zprávy (ať už administrátorem nebo kýmkoli jiným), nýbrž buď explicitně nebo při zavírání schránky. Např. v Thunderbirdu je na to funkce Provést údržbu složky, v Roundcube je to funkce Zmenšit. EXPUNGE při zavírání schránky lze nastavit v konfiguraci.

[BoB]

No, zkousel jsem ten pouze ve squirrelmailu. User smaze zpravu, oznaci se mu jako D, pak se prihlasi Admin a tim, ze ma pravo e Squirrelmail automaticky zpravu smazne. To mi prijde trosku spatny, protoze Admin se timto zpusobem vubec nedozvi o zprave, kterou eser smaznul

[BoB]

jinak ten Delete flag je aplikovan pro vsechny usery vc. admina, takze timto user muze zpravy jakoby mazat, respektive je skryt ostatnim uzivatelum, pouzivajici napr. Thunderbird. Nemelo by toto byt taky "lokalni" jako ten Read flag?

[Luk]

Protože jsem o tom psal už v jiné části diskuse, překopíruji to sem:

Nevím o tom, že by se označení zprávy za smazanou v Dovecotu rozlišovalo podle uživatele (i v případě, že se rozlišuje označení zprávy za přečtenou). Nicméně dokumentace o tom mlčí a nezkoušel jsem to, takže to není úplně jisté.

[BoB]

Jo, omlouvam se, nevsiml jsem si toho. Nicmene takovyto styl sdileni Vam osobne vyhovuje? Me ty prava pak prijdou takova konfliktni. Nakonec nam vsechno smazne beznes user s pravem t (i kdyz diky adminovi s pravem e) a ostatni useri neuvidi postu s priznakem D v Thunderbirdu, i kdyz jeste nebude smazana fyzicky. Kdyz zase uzivatelovi odeberu pravo t, muze brutalne zacit zaplnovat kos porad jednou a tou samou zpravou. Omlouvam se jeste jednou za to, jak jsem otravnej, ale prave z techto duvodu jsem chtel namet, jak mate nastavena prava ku spokojenosti

[Luk]

Začnu od konce.

prave z techto duvodu jsem chtel namet, jak mate nastavena prava ku spokojenosti

Tuto funkcionalitu k ničemu praktickému nepoužívám. Mám jednoho zákazníka, u kterého by to mohlo mít smysl, ale protože se sdílení muselo řešit už před x lety (kdy v Dovecotu ještě nebyla dodělaná podpora), řešilo se to společným využíváním speciálního účtu více uživateli. Dnes by se to dalo změnit, ale protože současný stav plně vyhovuje, není k tomu důvod.

Nicmene takovyto styl sdileni Vam osobne vyhovuje? Me ty prava pak prijdou takova konfliktni

Na tomto způsobu sdílení mi nic konfliktního nepřijde.

Nakonec nam vsechno smazne beznes user s pravem t (i kdyz diky adminovi s pravem e)

Pokud nebude mít admin nastaveno, aby se automaticky provádělo EXPUNGE (nebo nebude mít debilního klienta, u kterého to bude natvrdo nastaveno tak, aby se to provádělo), nic se nesmaže. Kromě toho, jak jsem už říkal, právo "t" je potřeba i k přesunu zprávy do jiné složky, protože toto probíhá pomocí překopírování a označení za smazané.

Čili - pokud bude mít uživatel právo "t", může zcela bezpečně zprávy "mazat" (kdy se zpráva označí za smazanou a u některých klientů se ještě před tím zkopíruje do koše) a přesouvat. Žádná zpráva nemůže zmizet. Administrátor si musí ohlídat, aby nedělal operaci EXPUNGE jindy, než když ji udělat chce. Pak bude všechno fungovat ke spokojenosti.

[BoB]

Diky za trpelivost Skoda, ze ten delete je globalni, ale to uz jsme resili. Tzn. ze pokud nebude mit admin pravo e, tak nemuze provest "udrzbu slozky" v TB?

[Luk]

Tzn. ze pokud nebude mit admin pravo e, tak nemuze provest "udrzbu slozky" v TB?

Přesně tak.

[petr_p]

Thunderbird dělá expunge při otevření schrány (respektive možná pouze při prvním otevření). Při zavření nikoliv.

[BoB]

A to same dela Squirrelmail, proto si diky tomuto (mozna jen vychozimu nastaveni) smazu maily, co User oznacil jako deleted. Proste at je to s pravy a posloupnosti ukonu jak chce, diky userovi muze admin o zpravy prijit

[Luk]

Thunderbird dělá expunge při otevření schrány (respektive možná pouze při prvním otevření).

Toho jsem si nevšiml. Nikdy mi to při spuštění neudělal. Možná pokud je zaškrtnuté Provést údržbu složek, pokud se tím ušetří...

Při zavření nikoliv.

Při zavření to dělá (tedy přinejmenším pro inbox), pokud je zaškrtnuté Při ukončení provést údržbu složky s doručenou poštou.

[petr_p]

Já nevím, ale mně po Thunderbirdu pravidelně na serveru zůstávají správy označené na smazání. Rovněž v Bugzille je na to vlákno.

[Karel]

Ja bych se chtel pro zmenu zeptat, jak tuhle posloupnost sdilenych slozek muzu zmenit v Thunderbirdu. Treba ta slozka example.net je jakoby aktivni, presto, ze se neodkazuje na zadnou IMAP slozku a proto by mela spis byt zasedla stejne jako ta info nebo shared, jen nevim jak to nastavit.

[Karel]

Příloha:

• slozky.png (11332 bytů)

jeste prikladam tu mou strukturu slozek

[Luk]

S tím jsem se také setkal. Jde téměř jistě o chybu Thunderbirda, protože když jsem to tehdy testoval přímo z konzole proti serveru, choval se server tak, jak měl (tj. vracel v seznamu složek jen ty, které jsou skutečně složkami, nikoli jen úrovněmi hierarchie).

[Karel]

Dekuji za odpoved. Da se ta struktura nejak zmenit? Jedna se mi o inbox info, ktere jsem mel drive reseny symlinky a proto podslozka Info byla krasne v rootu firemni postovni schranky. Ted musi uzivatel naklikat tri urovne, aby se na ni dostal. Vim, je to hloupost, ale zvyk je zvyk.

[Luk]

Samozřejmě, že se dá struktura změnit. Nastavuje se to tím parametrem prefix.

[Karel]

aha, a jak to zadam, aby sdilena slozka byla primo v rootu emailove schranky?

[Luk]

Tohle bohužel nejde (ve jmenném prostoru shared, tj. složky sdílené jednotlivými uživateli). Jde, aby byly složky ve druhé úrovni, pod identifikací uživatele - a to tak, že první úroveň je např. %%u (to se nastaví do prefixu) a pod tím už jsou jednotlivé složky. Dovecot nesežere žádný prefix, který by neobsahoval buď %%u nebo %%n. Čili lze nastavit něco jako toto:

prefix = %%u/

Pak pokud bude uživatel třeba franta@moje.domena a bude sdílet složku Projekty, složka se objeví jako franta@moje.domena/Projekty. Sdílet složky tak, aby se objevovaly v kořenu, lze jedině přes veřejné jmenné prostory (public) - tam už se dá nastavit prakticky cokoliv. Viz příklad v článku.

[Karel]

Ano, tohle ( prefix = %%u/ ) je zrejme to co hledam, ale mam nekde chybu, protoze se mi zacnou Shared slozky vytvaret na serveru uplne jinde, nez kam odkazuje location. A napr v me bezne IMAP slozce napr. Projekty vytvori podslozka INBOX atd.. Proste to nejak neposloucha.