blob: 7873725b963a0086ac28842aeaf4a8d450e7fd2d (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
Upgrading from DBMail 2.2 to DBMail 3.0
Dependencies
* Database: MySQL 5.0, PostgreSQL 8.3+, or SQLite3
* Glib: (>= 2.8.0)
* GMime: (>= 2.2.0)
* Optional: libSieve (>= 2.2.1)
* Optional: LDAP such as OpenLDAP or ActiveDirectory.
* openssl
* libmhash
* libzdb (http://www.tildeslash.com/libzdb/)
* libevent
Config Changes
* [DBMAIL] section
Dbmail allows you to select the database backend and authentication
module in the config file.
driver=mysql/postgresql/sqlite
authdriver=sql/ldap
The old TRACE_LEVEL is now not used anymore, and
TRACE_SYSLOG/TRACE_STDERR are now deprecated.
Logging has been broken up into 8 logging levels and each level can
be individually turned on or off. The Stderr/log file logs all
entries to stderr or the log file. Syslog logging uses the facility
mail and the logging level of the event for logging. Syslog can then
be configured to log data according to the levels.
Set the log level to the sum of the values next to the levels you
want to record.
1 = Emergency
2 = Alert
4 = Critical
8 = Error
16 = Warning
32 = Notice
64 = Info
128 = Debug
255 = database queries (very verbose)
Examples: 0 = Nothing
31 = Emergency + Alert + Critical + Error + Warning
511 = Everything
FILE_LOGGING_LEVELS = 7
SYSLOG_LOGGING_LEVELS = 31
Schema Changes
Migration scripts from the previous stable releases are provided in
sql/mysql, sql/postgresql and sql/sqlite. Please test them first
before applying them to your live database. Especially people who have
modified their tables, and users using databases that go back to 2.0
or earlier should take special care.
The schema for 3.0 adds new tables for single-instance storage of
mimeparts, and for supporting user labels on messages in IMAP.
Migration of old data is supported through dbmail-util, but until
you migrate the old data will remain accessible. New messages will
be stored in the new schema.
Also, the header caching tables have been revised. This means they
will have to be dropped, re-created, and re-filled using:
dbmail-util -by
Server Changes
Dbmail until 2.2 used a pre-forking server design with a dedicated
connection to the database backend for each forked process. Even with
a hundred or so concurrently connected clients this stretched the
scalability of the database backends.
Starting with version 2.3.3 dbmail has switched to a single process
that uses a event-driven architecture to handle many many concurrent
clients. Where needed a pool of worker threads is used to process
database transactions. Currently, only the IMAP server is multi-
threaded. Database transactions are handled by a single shared
dynamic database connection pool to minimize the number
of overall database connections.
All this means that a number of configuration options are now
redundant. You can remove the following items from dbmail.conf:
NCHILDREN
MAXCHILDREN
MINSPARECHILDREN
MAXSPARECHILDREN
MAXCONNECTS
---
EOF
|
