Bart Burkhardt wrote:
Okay i got an pop3 and imap server running now. Yippi!
But now i still have some issues…
1.
I downloaded the latest version 2.0.3 and in this download there is a
file called INSTALL.postfix, and in that file there is still an error.
This error is known by Aaron, but still not updated.
It will be in 2.0.4
The file instructs this ..
If you want to decide if DBMail should be used per domain please add
the following in /etc/postfix/tranport: <domain>
dbmail-lmtp:<host>:<port>
/etc/postfix/tranport
Should be;
/etc/postfix/main.cf (in my case /usr/local/etc/postfix/main.cf, i run
FreeBSD)
No way. Transport statements like
<domain> dbmail:host:post
belong in transport.cf *not* in main.cf
But you're right about the INSTALL doc: there's a small typo there to be fixed.
It reads 'tranport' where it should read 'transport.cf'
2. I had the problem that my dbmal-imapd crashed with an errors about an
recurisive functio.
Please specify and include the relevant log lines.
After adjusting the default processen from 50 to 20
this problem went away. My question, why so many processes? If i do a ps
–ax i see pages of dbmail processes….
Feel free to tune the NCHILDREN option as well as the
MIN_SPARE_CHILDREN/MAX_SPARE_CHILDREN to your own circumstances.
Also when imapd crashed, i got a bunch og child processes, with the
dbmail.imapd.sh stop command i could not stop them….
That dbmail.imapd.sh script is not part of the dbmail package. Did you role your
own?
3. I had to copy dbmail.conf to /etc instead of the /usr/local/etc
Although the start script points to the /usr/local/etc when
starting it can’t find the dbmail.conf file.
Again: please specify the exact command sequence and include logs if possible.
All dbmail binaries should respect the -f option. If they don't that's a bug.
So is the /etc location hardcoded in the source or something?
It's hardcoded, but can be runtime overridden with the -f option.
4. On the dbmail website i read;
The The whole email is stored in the database. That includes
attachments.
I had a look in the database and noticed that the Mime data is
stored in the database, not the images as a blob file.
There no Mime dedecode funtions doing that.
Actually i was hoping that the system had MimeDecode possibilitys,
because seperating tekst from attachements is pretty cool for multiple
reasons.
One reason is to keep the db smaller(same attachment for multiple
users, only one attachement) two is that is would be possible to detach
an email so that the tekst is still there but the files are deleted
(Lotus Notes has such a detach function)
There's only one word here: kiss.
But to expand a little: dbmail didn't have (and still doesn't as far as 2.0
goes) good mime parsing capabilities. Those have only recently been added to the
CVS-head/SVN-trunk codebases by introducing gmime/glib.
Storing mime-parts in separate messageblks constitutes a major conceptual
change. It can be done. And perhaps it will be done if there's convincing enough
arguments in favor. But don't hold your breath.
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
