WU IMAP, imap proxy, Outlook Express

23.2.2006 12:32 | Přečteno: 1891× | poslední úprava: 23.2.2006 12:32

Na login serveru s několika stovkami uživatelů používáme wu-imapd. To je prestižní distribuce Washingtonské univerzity, kde IMAP vynalezli a kde také bylo napsáno RFC 3501. Zatím používáme pro poštovní soubory klasický formát mbox. Začali jsme mít problémy s přetížením hlavně odpoledne, kdy se zřejmě nejvíc buší do pošty. Nainstalovali jsme IMAP proxy z www.imapproxy.org v naději, že se tak vyhneme velmi častému opakovanému čtení velkých uživatelských INBOXů při každém dotazu od webmailu, Outlook Expressu a dalších mailových klientů, kteří nejsou ochotni použít perzistentní spojení. Výsledky jsou tak trochu všelijaké.

Máme tady Squirrel Webmail, ten samozřejmě na každý klik dělá nové IMAP připojení, u webmailu to jinak nejde. Na tohle je imap proxy hlavně určen a taky na to bezvadně funguje. Nějaké uživatele toho webmailu máme, takže k odlehčení provozu serveru skutečně došlo.

Imap proxy neumožňuje SSL spojení od klienta. Nevadí, spustili jsme si druhou instanci zprostředkovaně skrz stunnel na portu imaps 993. IMAP klienti nic nepoznali. Pořád všechno báječně šlapalo.

Jenže po nasazení do ostrého provozu si začali stěžovat uživatelé OE. Některým pořád vyskakovalo hlášení o nějakém timeoutu (každou minutu), po jeho odkliknutí bylo všechno v pořádku. Jiným taky vyskakovalo okýnko a k některým zprávám se vůbec nedostali. No a někomu to fungovalo dobře. Za jakých okolností to nebo ono se nepodařilo zjistit. Těch kteří si stěžovali bylo vlastně dost málo, ale i tak jsme pocítili potřebu jim to nějak spravit. Bohužel nezbylo než to všechno zase odinstalovat a začít jev zkoumat.

Imap proxy prý má nějakou možnost trasování, ale to se nám nepodařilo oživit. Možná to nefunguje, nebo jsme nepochopili návod. Připsal jsem si do zdrojáku nějaké ty ladicí mezivýstupy a zkoušel jsem, co to udělá. Na první pohled jsem viděl jedinou věc - OE běžně otevírá násobná spojení. V textu RFC 3501 se dočítám, že násobné spojení je jediná možnost, jak pracovat současně se dvěma a více mailboxy. Mám ale podezření, že OE otevírá dvě spojení selectovaná do jednoho mailboxu. Protože při testech jsem tam víc přihlášených mailboxů neměl. IMAP server potom obsluhuje jeden socket a na druhý zvysoka kašle. IMAP server může mít problém s přístupovými právy, ale bez imap proxy to funguje. Takže v tom to asi nebude. Zkusil jsem ostatně i převést testovacího klienta do formátu mbx, k němu WU imapd povoluje vícenásobné read-write přístupy. Chování se změnilo, ale timeouty hlášené od OE tam byly pořád. Imap proxy je napsán nad pthreads, člověk nikdy neví, kdy zaforkuje a kdy jenom vytvoří další vlákno. Pořád se tam nasazujou nějaké mutexy, tam někde třeba může být chyba. Já do toho nejdu.

Nakonec nevím skoro nic. vypadá to, že imap proxy se hodí jako front end k webmailům, k jinému typu IMAP klientů nikoli.

       

Komentáře

[Jan Kundrát (jkt)]

Na první pohled jsem viděl jedinou věc - OE běžně otevírá násobná spojení. V textu RFC 3501 se dočítám, že násobné spojení je jediná možnost, jak pracovat současně se dvěma a více mailboxy. Mám ale podezření, že OE otevírá dvě spojení selectovaná do jednoho mailboxu.

RFC 3051 (IMAP4rev1) a zejmena RFC 2683 (IMAP4 Implementation Recommendations, sekce 3.1.1) rikaji, ze vicenasobny pristup do jednoho mailboxu nemusi byt podporovan, a ze you must avoid making multiple connections to the same mailbox in your own client (for load balancing or other such reasons). Inu OE, no.

Protože při testech jsem tam víc přihlášených mailboxů neměl. IMAP server potom obsluhuje jeden socket a na druhý zvysoka kašle. IMAP server může mít problém s přístupovými právy, ale bez imap proxy to funguje. Takže v tom to asi nebude.

Tohle jsem uplne nepochopil.

Zkusil jsem ostatně i převést testovacího klienta do formátu mbx, k němu WU imapd povoluje vícenásobné read-write přístupy. Chování se změnilo, ale timeouty hlášené od OE tam byly pořád. Imap proxy je napsán nad pthreads, člověk nikdy neví, kdy zaforkuje a kdy jenom vytvoří další vlákno. Pořád se tam nasazujou nějaké mutexy, tam někde třeba může být chyba. Já do toho nejdu.

Mozna by se hodil log IMAP spojeni, ktere hazi chybu/timeout.

Nakonec nevím skoro nic. vypadá to, že imap proxy se hodí jako front end k webmailům, k jinému typu IMAP klientů nikoli.

Ciste teoreticky vzato by mela byt plne transparentni.

BTW, RFC 3051 jasne rika, ze timeout musi byt >= 30 minut, proto mi neni jasna poznamka ve FAQ od imapproxy o peti minutach. To je default nastaveni?

[krnoha]

Protože při testech jsem tam víc přihlášených mailboxů neměl. IMAP server potom obsluhuje jeden socket a na druhý zvysoka kašle. IMAP server může mít problém s přístupovými právy, ale bez imap proxy to funguje. Takže v tom to asi nebude.

Tohle jsem uplne nepochopil.

Nepochopil, protože jsem to blbě napsal. Při existenci dvou spojení selectovaných do jednoho mailboxu typu mbox to WU imapd řeší tak, že tomu staršímu spojení dá přístupové právo read-only. V RFC 3501 je napsáno, co to znamená. Toto učiní, ať je mezi klienta a server vložena proxy, nebo není. Proxy by v tom neměla hrát žádnou úlohu. Ale nějakou úlohu hraje, což zjistím, když ji vyřadím a připojím se stejným klientem přímo k imapd.

Nakonec nevím skoro nic. vypadá to, že imap proxy se hodí jako front end k webmailům, k jinému typu IMAP klientů nikoli.

Ciste teoreticky vzato by mela byt plne transparentni.

Navážu spojení 1, jsem read-write. Navážu spojení 2 do stejného mailboxu. imapd udělá spojení 1 read-only, 2 read-write. Ukončím spojení 1. Imap proxy ale spojení k serveru zachová pro pozdější použití. Navážu spojení 3. Proxy mlčky sežere sekvenci LOGIN a SELECT, načež nové spojení 3 propojí s kešovanou seancí, která zbyla po spojení 1. Spojení 3 má tedy oprávnění RO. Kdyby tam proxy nebyla, mělo by oprávnění RW a minulé spojení 2 by dostalo RO. Čistě teoreticky tedy plně transparentní být nemusí. Nicméně tvrdím, že některé pozorované jevy nejsou tímto mechanismem vysvětlitelné.

BTW, RFC 3051 jasne rika, ze timeout musi byt >= 30 minut, proto mi neni jasna poznamka ve FAQ od imapproxy o peti minutach. To je default nastaveni?

RFC 3051 hovoří o násilném ukončení spojení v případě neaktivity klienta. Timeout 5 minut se týká toho, jak dlouho držet kešované spojení poté, co se skutečný klient ukončil.

[Jan Kundrát (jkt)]

Nepochopil, protože jsem to blbě napsal. Při existenci dvou spojení selectovaných do jednoho mailboxu typu mbox to WU imapd řeší tak, že tomu staršímu spojení dá přístupové právo read-only. V RFC 3501 je napsáno, co to znamená. Toto učiní, ať je mezi klienta a server vložena proxy, nebo není. Proxy by v tom neměla hrát žádnou úlohu. Ale nějakou úlohu hraje, což zjistím, když ji vyřadím a připojím se stejným klientem přímo k imapd.

Aha. Co testy s jinym storage backendem, pripadne s jinym IMAP serverem? Sice je hezky, ze OE nerespektuje RFC, ale to uz vime a uzivatele zrejme migrovat nechteji.

Navážu spojení 1, jsem read-write. Navážu spojení 2 do stejného mailboxu. imapd udělá spojení 1 read-only, 2 read-write. Ukončím spojení 1. Imap proxy ale spojení k serveru zachová pro pozdější použití. Navážu spojení 3. Proxy mlčky sežere sekvenci LOGIN a SELECT, načež nové spojení 3 propojí s kešovanou seancí, která zbyla po spojení 1. Spojení 3 má tedy oprávnění RO. Kdyby tam proxy nebyla, mělo by oprávnění RW a minulé spojení 2 by dostalo RO. Čistě teoreticky tedy plně transparentní být nemusí. Nicméně tvrdím, že některé pozorované jevy nejsou tímto mechanismem vysvětlitelné.

Coz takhle opatchovat imapproxy, aby neuzivala spojeni, ktera jsou R/O? (IIRC musi IMAP server rict [READONLY] v odpovedi na SELECT). Ale nejsem si jisty, jestli by to nejak snizilo zatez, maximalne tak odstranilo problemy...

RFC 3051 hovoří o násilném ukončení spojení v případě neaktivity klienta. Timeout 5 minut se týká toho, jak dlouho držet kešované spojení poté, co se skutečný klient ukončil.

Aha, diky.

[krnoha]

Aha. Co testy s jinym storage backendem, pripadne s jinym IMAP serverem? Sice je hezky, ze OE nerespektuje RFC, ale to uz vime a uzivatele zrejme migrovat nechteji.

Zhruba tímto směrem budeme pokračovat. Ale to není tématem tohoto přízpěvu.

[Dunric]

S imap proxy zkušenost nemám, takže o rady se moc nepodělím, ale jak už vám bylo pod minulým blogpostem sděleno, s formátem mbox pro ukládání e-mailových zpráv díru do světa neuděláte. Já bych instalaci proxy řešil až jako další krok.

Z dokumentace k UW-IMAP:

 . mbx	This is the current preferred mailbox format.  It can be
 	handled quite efficiently by c-client, without the problems
 	that exist with unix and mmdf formats.  Messages are stored
 	in Internet standard CR LF format.
 
 	mbx permits shared access, including shared expunge.  It
 	preserves UIDs, and allows the creation of keywords.
...

The main difference from the mbox format is that each message in the file is preceded by a record that carries some message-specific metadata. As such, certain operations that used to require the entire mbox file to be rewritten can now be implemented by updating the fixed-size header record.

[Dunric]

Ještě odkaz na FAQ přímo na stránkách University of Washington

[krnoha]

Některé mailboxy některých uživatelů lze klidně převést na mbx. Nejde to udělat šmahem. S mailboxy generovanými procmailem díky pravidlům v .procmailrc tohle nejde. Některé automatické postupy generování mailboxů lze po individuálním prozkoumání přepsat tak, aby to pracovalo s formátem mbx. Jsou provozovány i aplikace, které interně volají mailx nebo se perlovsky hrabou přímo v mailboxu typu mbox. Některé věci by se některým uživatelům rozbily. Proto jsme začali s imap proxy.

[Jan Kundrát (jkt)]

Dejme tomu, ze mam svuj INBOX fyzicky umisteny na danem stroji, vsechny dalsi mailboxy jsou v ~/mail/ a nektere z nich jsou treba symlinky na NFS share, protoze kvoty. Ustoji UW-IMAP michani formatu mailbox a mbx v ramci jednoho namespacu? mbx si s NFS pry nerozumi:

Another problem is that the certain formats, including mbx, use advanced file access and locking techniques that do not work reliably with NFS. NFS is not a real filesystem. Use IMAP instead of NFS for distributed access.

[Dan Ohnesorg]

Podle toho co jsem vypozoroval OE jedno spojeni pouziva pro periodickou kontrolu poctu novych zprav v mailboxu a druhe pro jejich fyzicke stazeni.

Kazdopande me uzivatele OE donutili k prechodu na mbx uz nekdy pred peti lety. Sice bolelo predelat jim .procmail aby pouzivali dmail, ale nedalo se svitit.

Dneska jsme pred stehovanim na cyrus, protoze mbx ma problemy pri prekroceni pul giga v jednom souboru.

[Jan Kundrát (jkt)]

Podle toho co jsem vypozoroval OE jedno spojeni pouziva pro periodickou kontrolu poctu novych zprav v mailboxu a druhe pro jejich fyzicke stazeni.

Tim padem by ale klidne mohlo byt prvni spojeni R/W (cili SELECT) a druhy jenom R/O (EXAMINE), ne?

[Dan Ohnesorg]

Naopak, prvni by melo spadnout do RO a druhe do R/W, nicmene principielne by to chodit melo. Jenze vite jak je to s sedou teorii a zelenym stromem zivota. Proste se objevuji nahodne se vyskytujici, nereprodukovatelne, zivotni situace a cim vyse postaveny manager, tim u nej nastavaji casteji

[Jan Kundrát (jkt)]

Jiste, ale ja bych to teda napsal tak, ze spojeni A bude mit R/W do mailboxu (polling novych zprav, presuny etc, proste datove nenarocne prenosy) a spojeni B bude read only (explicitne, tj. nepouziju SELECT, ale EXAMINE) a budu ho pouzivat pro cteni velkych dat (maily).

A nebo to udelam korektne, cili jenom jedno spojeni a data budu cist po castech, abych si nezablokoval spojeni.

[krnoha]

Proste se objevuji nahodne se vyskytujici, nereprodukovatelne, zivotni situace a cim vyse postaveny manager, tim u nej nastavaji casteji

Takže manažer zapláče, odevzdá funkci a vrátí se k poctivé práci. Načež zjistí, že už je na to moc senilní.

[Důchodce]

Na taková slova pozor, viděl jsi co kolem senility bylo včera na rootu.

[krnoha]

Děkuji. SuSE Open Xchange taky používá Cyrus. Myslím že to znamená dedikovaný poštovní server, kam uživatelé přímo do souborů nemůžou, žejo. Jednou to tak stejně musí skončit.

[Dan Ohnesorg]

Jo tak nejak to je, uzivatele potom musi k souborum pristupovat jen pres IMAP/POP3. To celkem neni problem, zvlada to v pohode pine i mutt a nic jineho asi vetsina unix* uzivatelu nepouziva.

Me jako mnohem bolestivejsi nez migrace na imap prijde to, ze uz se neda pouzivat procmail. Do slozek se posta tridi pres sieve, coz je jazyk v nekolika drobnostech chytrejsi nez procmail a v tisici zakladnich vecech mnohem blbejsi. Nejsou tam spoustet externi programy, nejde poslat na mobil jen cast emailu, nejdou pri forwardu menit/pridavat hlavicky. Clovek s tim jak bez ruky. Navic k tomu nejsou zadne solidni nastroje na editaci. Musi se to na server uploadovat specialnim protokolem, ktery neni vesmes nikde podporovan. Ve vi a emacsu ano, ale rozhone pro to neni do windows zasuvny modul pro total commander nebo nejake winscp.

[Jan Kundrát (jkt)]

Musi se to na server uploadovat specialnim protokolem

Viz dovecot WIKI, treba on to ma jenom jako soubor .dovecot.sieve...

[Jan Kundrát (jkt)]

Tak jsem si na #dovecot (freenode) popovidal s jeho autorem. Dovecot umi mbox a navic si k nim udrzuje index, ktery ale musi castecne predelat pokazde, kdyz ke zmene mboxu dojde "zvenci", tj. mimo IMAP. Vzhledem k tomu, ze vetsina lidi disponujicich obrovskym INBOXem a pouzivajicim OE zrejme nebude s mboxem manipulovat neIMAPoidnimi prostredky, videl bych to jako vcelku zajimavou moznost, ktera by mohla stat za otestovani.

18:44 < jkt|> one of my colleagues is having troubles with uw-imapd and OE
18:44 < jkt|> so we're seeking for some replacement
18:46 < DanGer> dovecot! 
18:47 -!- johill [n=johannes@p5487D669.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)]
18:47 < jkt|> I'm not the one who will be responsible for a move
18:47 < jkt|> but
18:47 < jkt|> our employees have their mail in a mbox format
18:47 < jkt|> and they use some tools directly accessing the files
18:47 < jkt|> (they have shell access)
18:48 < jkt|> and OE opens an IMAP connection, works for a while and then disconnects
18:48 < jkt|> so I'm courious if this kind of load can be handled by dovecot
18:49 < jkt|> efficiently :)
18:51 < tss> mboxes + users accessing them directly isn't all that great idea
18:51 < tss> but i don't know any problems with that as long as everyone uses same lock settings
18:52 < jkt|> direct access might be only for reading, I don't know details
18:52 < tss> danger: and i don't really know why that old_password() seems to be a problem only with dovecot. guess i should look into it some day
18:52 < jkt|> does dovecot support multiple concurent r/w access to the same mailbox-type mailbox?
18:52 < tss> jkt|: mbox format itself doesn't support that
18:53 < tss> but i guess it depends on how you define concurrent :)
18:53 < jkt|> two IMAP connections both having selected the same mailbox
18:53 < tss> that's not a problem with dovecot
18:53 < jkt|> will it degrade on of them to the r/o?
18:53 < tss> if the mbox has changed it will be resynchronized
18:54 < tss> it doesn't
18:54 < jkt|> well, they say that there are several major problems:
18:54 < jkt|> a) users use huge INBOXes
18:54 < jkt|> b) outlook closes connection often
18:54 < tss> dovecot's indexes help with huge mboxes
18:54 < tss> reopening mailboxes is very fast because of indexes
18:55 < jkt|> even when in old "mbox" format?
18:55 < tss> yes
18:55 < jkt|> great
18:55 < tss> only slowdown comes when some external program has modified the mbox file
18:55 < jkt|> I see
18:55 < tss> then dovecot has to read it all over again entirely
18:55 < tss> but that still works, only a bit slower than it needs to
18:56 < jkt|> that won't be much an issue as the users using only INBOX usually don't access thei mails without IMAP
18:56 < tss> with large mailboxes mbox_very_dirty_syncs=yes setting could be a good idea
18:56 < tss> if you don't care that then dovecot doesn't always notice if some external program has changed mails' flags for example
18:56 < jkt|> tss: is that safe?
18:56 < jkt|> I mean, I don't knwo anything about dovecot, so feel free to say rtfm
18:56 < tss> only problem is that dovecot doesn't notice all mbox modifications immediately
18:56 < jkt|> provided it's documented :)
18:56 < jkt|> hmm
18:57 < tss> but i'd say it's safe and a good idea :)
18:57 < tss> perhaps i should even make it a default setting
18:57 < jkt|> could you please define "immediately"?
18:57 < jkt|> I mean, how long does it take?
18:57 < tss> well, that depends ..
18:57 < jkt|> and if it is guarranted that it ever happens
18:58 < tss> you see, when a message's flag is changed in mbox file, it may mean that it only changes a single byte in the file
18:58 < tss> so the file size doesn't change for example
18:58 < jkt|> yup
18:58 < jkt|> er
18:58 < tss> in that case dovecot doesn't see that change with very-dirty-syncs unless it for some reason has to re-sync the whole mbox
18:59 < jkt|> well, I'm not familiar with mbox format
18:59 < jkt|> but it seems to me that flags are stored in X-IMAP field in the header
18:59 < tss> not really
18:59 < jkt|> or X-status
18:59 < tss> Status and X-Status
19:00 < tss> Dovecot's dirty-syncing is anyway a tradeoff between noticing changes that non-Dovecot has done and not wasting time re-reading mbox files
             where only new mail was appended to
19:00 < jkt|> well, but some of my messages have just "X-Status: A\r\n"
19:01 < jkt|> so appendindg a flag would change the size, right?
19:01 < jkt|> typos--
19:01 < tss> possibly. depends on the program that changes the mbox
19:01 < jkt|> okay
19:01 < tss> some programs leave padding in some headers
19:01 < jkt|> I'll try to persuade them to give dovecot a try
19:02 < tss> and they move the data only enough so that the padding is increased/decreased
19:02 < tss> dovecot, uw-imap and pine do this at least
19:02 < jkt|> I see
19:02 < jkt|> well, thanks a lot :)
19:15 < jkt|> er
19:15 < jkt|> another question
19:15 < jkt|> when a new mail arrives to the mbox
19:15 < jkt|> isn't it neccessary to rebuild the index?
19:26 < tss> rebuilding at least is a wrong word. "synchronizing" is better :)
19:26 < tss> since only the new mail is added there then
19:27 < tss> with dirty-syncing dovecot reads only the second-last and the new mails, and adds the new mails
19:27 < tss> without dirty-syncing the whole mbox file is read and new mails are added
19:27 < tss> (and with dirty syncing if the second-last mail doesn't start from the expected position, the whole mbox file is read)
19:28 < jkt|> I see
19:28 < tss> guess i should write this down somewhere in wiki
19:28 < tss> i like dovecot's dirty syncing feature a lot :)