Am 30.01.2012 09:24, schrieb Paul J Stevens: > On 01/29/2012 10:47 PM, Reindl Harald wrote: >> Interesting - Pauls Reply was blocked by Barracuda-Spamfirewall >> Seems this was only a temporary problem Zeit: 2012-01-27 10:05:06 >> Aktion: Geblockt Begründung: Barracuda Reputation (213.214.111.4) >> Absender-IP-Adresse: dbmail01.icns.fastxs.net[213.214.111.4] > > 'Reputation' based on what? RBLs are a completely failed concept imo.
on the other hand we have days with 250.000 blocked messages from the barracuda-appliance and their blacklist and no complaints about false-positives most of the time >>> This will break IMAP body searches (who uses those??) >> >> hmm - i do :-) > > What client? thunderbird >> what i am missing are the parameters for connection pooling the >> "dbmail.conf" from the last RC-sources looks like the dbmail 2.2.x > > It's there alright: > > # Number of database connections per threaded daemon > # This also determines the size of the worker threadpool > # > #max_db_connections = 10 oh - sorry for my bad eyes :-( >> AFAIR pooling is only for imap currently and nor for POP3 or am i >> missing something here? > > You are. > > All 3.0 programs use libzdb for the database handling. This implies a > connection pool. good to hear - my last information is nearly a year old and was FAIK the RC announcement > All 3.0 network daemons use a non-blocking async network architecture > for communications with clients using libevent. cool! > However: database queries are blocking! So when I first did the > libevent transition I quickly ran into throughput issues caused by > longer-running database queries. When everything is handled by one > single thread this led to pretty poor performance when more than say > 10 imap clients were connected. > > This was solved by making the IMAP code - and only the IMAP code - > multi-threaded. Now for IMAP a pool of worker threads is created; one > thread for each database connection in the database pool. These > workers pull their workload of an async message queue filled by the > main thread which deals with all the network IO. The workers do their > thing and pass the message back to the main thread via a separate > message queue. did i say i love your work often enough? > pop3d, lmtpd and timsieved however just run one single main thread. > pop3 queries are pretty fast, lmtp is asynchronous be nature (no > humans waiting), and timsieve is run only infrequently, with low > volumes and fast queries. many thanks for all this informations! > Admittedly if you run very heavy POP3 traffic you will have to make > provisions if real-world testing proves throughput to be too low - for > example startup multiple pop3d processes on different ports and run a > load-balancer in front. If there is serious interest in better > throughput for pop3 I may reconsider but it just didn't seem to > warrant the investment at this time. we are running dovecot as proxy in front of dbmail for several reasons what should relax this * auth-daemon for postfix-sasl/imap/pop3 * SSL encryption since only native supported with the new version * replacement % -> @ before the real login (legacy history from EIMS mailserver) * security at all - even if dbmail would have a security whole i guess it would be extremely hard to trigger it through the proxy thank you for all this informations and this really fine piece of software and best wishes from vienna! -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
