I have the same problem after running 2.2.5 for a month or so. Each time
the dbmail-util -ay runs I get
Repairing DBMAIL for cached header values...
Ok. Found [169] un-cached physmessages.
And they don't go away in subsequent runs of dbmail-util.
The number of mails that got in the system duri
Paul J Stevens wrote:
/tmp is bit over 200 megs and is UFS.
That's way too small. That means /tmp will overflow if dbmail is
processing 200 megs of email at a time (lmtp+pop3+imap).
Well, it has worked on multiple servers for over 5 years now, some of
them web server, some do very nasty j
Hello,
What would be the currently most stable version around from the 2.2 series?
--
br,
Tommi
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
Niblett, David A wrote:
I do have a spare machine to try it on, but given my smaller
test and reports of others with similar sized DB's it will
potentially take many hours.
I had almost 4 gigs of mail (as a dumped file), took 10-15 minutes for
the conversion with the normal sql script.
This
Anne wrote:
Then the final step: dbmail-util -by...it took 4 hours!!! :-((
So long for my schedule. This really pissed me off. Argh!
Hmm I had 3+ gigs on my pgsql db. The migration script took like 10-15
minutes and the dbmail-util maybe 20 minutes max. I had similar results
with another
Aleksander wrote:
Tommi Lätti wrote:
You would want to up the log size also at the same time, but that you
can't do if your innodb is created already.
You need to dump your db, drop the db, restart mysql with new params
and then restore the db to increase the log size.
Are you
Good point. The default if you don't specify the size in my.cnf is 8M,
but the example my.cnf files clearly specify 50-80% of the computer memory.
CentOS/RHEL don't have a size in my.cnf, so the mysql default is used,
which appears to be 8M.
I'll bump that up and see how it goes.
You would
Jim Douglas wrote:
I noticed these errors in my dbmail.err file after restarting...
FATAL File [/var/run/dbmail/dbmail-imapd.pid] exists and process id
[4087] is running
FATAL File [/var/run/dbmail/dbmail-lmtpd.pid] exists and process id
[4084] is running.
Wild guess:
Your server rebooted/i
I think I'm done now, and everything is fine. Victory! :)
So what happened...
It became quite clear that the data-only dump I had, had it's
messageblocks already converted to bytea. Now what went wrong with
earlier restore attempts was that I was importing the data over to 2.0.9
schema where
I checked again with dbmailadministrator, here are screenshots from what
the difference looks like...
The mail I copied from another account:
http://www.blosphere.net/~sty/goodmail.png
The mail that were in at 2.0.9 and now converted:
http://www.blosphere.net/~sty/badmail.png
I think a convers
Okay,
dbmail-util -byv goes thru nicely, just 220 un-cached physmessages which
don't get repaired even with multiple runs of the util.
The tables also seem to have populated (listing only few here):
dbmail_datefield37092 rows
dbmail_envelope 73303 rows
dbmail_fromfield
Aaron Stone wrote:
On Tue, 2007-01-02 at 13:15 +0900, Tommi Lätti wrote:
Allrighty, I could check that with tcpdump maybe but I think I can
assume that it's now bytea... although the schema says text.
Well, if the schema says text, then the bytea conversion has not taken
Is there a w
Paul J Stevens wrote:
Tommi Lätti wrote:
Does the migrate2.0_2.2 script make so that the database is then
unusable for 2.0 series?
Check the text->bytea conversion of dbmail_messageblks.messageblk, the
first transaction block at the top of the migration script. That's the
only *real
A little update is in order.
I managed to restore the database back. Had to delete all indexes and
constraints, then restore the data and after that restore the indexes
and constraints.
Now I run the 2.0.9 imapd and it connects and all, but sees 0 messages.
I know the messages are there and
Hello,
Decided to go ahead and do the upgrade today, using postgresql as the
database and running 2.0.9.
Now, as I'm a good boy I of course took a full pg_dump from the database
and started then process. Compiled new binaries and so.
Now I ran the migrate2.0to2.2 script against the database
Aaron Stone wrote:
Sure, file a bug with the port maintainer. It also looks like FreeBSD's
Ports version of libSieve is stuck at 2.1.13, which is not in the stable
series.
There's a patch now in, so the ports going to get an upgrade. I just
patched and it worked nicely.
Then, let's try the s
Tried to do an upgrade tonight on a test server, identical to the
production one (from dumps), here's a quick recap what happened. The
machine is FreeBSD 5.4 amd64, postgresql 8.0.3, libsieve 2.2.3 (from
sources). Coming from dbmail 2.0.9.
First tried the ports version, seemed to be 2.2.1. Lib
Tom Allison wrote:
Any other web-centric stuff?
Like a dedicated sieve page as opposed to a webmail plugin?
I used to use smartsive (http://smartsieve.sourceforge.net/) for my
needs. I think I was using cyrus back then
Cyrus reminds me... are we getting idled any time soon? It's a great
fea
Marc Dirix wrote:
"imapsync" should do the trick for you.
I can vouch for this program too, used it for over 1000-user migration.
( Actually I seem to be in the CREDITS of the proggie :) )
--
br,
Tommi
On 13.9.2006, at 18.35, Ozgur Karatas wrote:
Merhaba;
siz mail attiginizda Outlook uzerinden bir taraftan da server
tarafinda
/var/log/mail.log dosyasina tail -f ile bakip attigi logu paste
edebilir
misiniz
iyi calismalar
Lets keep this list only in English, shall we?
--
br,
Tommi
Carl Taylor wrote:
I use the following script in the way you mention. Fill in the
variables between the ## ## below to match your system setup and set to
run from Cron.
Looks very nice, even has some essential features I forgot to mention.
Thank you, I'll put these on my test server next wee
I've been using dspam quite successfully for a year now, but I've come
to think if it would be possible to take this integration to a next
level, using public and spam folders.
All users currently use the webpage to manage their spamquarantine and
honestly, I'd like to partially get rid of tha
DK wrote:
I have bind9 running but if I don't use '-o disable_dns_lookups=yes' I
get an error (see error below). What do I need to do to get this
working with dns lookup?
dbmail-lmtp unix - - n - - lmtp -v
-o disable_dns_lookups=yes
Jun 21 16:31:02 safe postfix/l
Is it possible to use unix sockets for the lmtpd? Works nicely when
listening to 24, but if I add 'socket=/tmp/dbmail.sock' to lmtpd conf
then it just reports that 'address is already in use'
--
br,
Tommi
Paul J Stevens wrote:
Tommi Lätti wrote:
Paul J Stevens wrote:
Before you do though: confirm it's still a problem in 2.1. If it's
still there
in 2.1 please file a bug. Or a patch!
Hmm yes I could run a separate imapd from 2.1 on different port just for
testing...
I under
Jorge Bastos wrote:
> Hi,
>
> I'm going to develop a web interface to create user accounts, change
> password's etc etc.
Yes. I need this. Is it completed?
Well, I've been a happy user of dbmailadministrator
http://library.mobrien.com/dbmailadministrator/ for some tim
Paul J Stevens wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dbmail 2.0.8 released
This is mostly a bugfix release with some minor additional features.
* added ON UPDATE CASCADE to create_table files
* do not close database connection on startup (closes: #271)
* change dbma
M. J. [Mike] OBrien wrote:
Hi Tommi:
MUA solution. DBMail IMAPD supports RFC 2087 IMAP quotas. A script
should not be hard to do but would be super expensive on large systems
to maintain a real time polling of quotas. That's why the protocol sets
out methods for doing this from the M
I've set some quotas for users and I noticed that there's no
functionality inside dbmail to warn the user about the quota getting
close to full.
Is there any workaround that people use? Maybe a script or something?
--
br,
Tommi
Tom Hancock wrote:
We are strongly considering deploying a Postfix/Dbmail email solution.
We will have 4 servers that will be running postfix, dbmail, and other
ISP related applications. They will use a backend server for the
database storage. The backend server will be running MySQL for Dbmail
Eugene Prokopiev wrote:
Hi,
I tried to use dbmail 2.0.7 and dspam 3.6.2 in dbmail-lmtp (instead of
dbmail-smtp as described in
http://www.dbmail.org/dokuwiki/doku.php?id=postfix_-_dspam_-_dbmail for
perfomance reason).
I see valid LMTP exchange in tcpdump log:
I was trying to debug proble
Paul J Stevens wrote:
Before you do though: confirm it's still a problem in 2.1. If it's still there
in 2.1 please file a bug. Or a patch!
Hmm yes I could run a separate imapd from 2.1 on different port just for
testing...
I understand that upgrading the 2.0 db to 2.1 doesn't affect the 2.0
Getting bit frustrated how mail.app treats dbmail imap server...
For some reason, if mail comes thru certain smtp servers, the dates on
mail.app get screwed, showing in the preview pane that all messages are
dated in 2106...
But only if the mail has already been marked as 'read' (as in, read
I've run into a strange problem with dbmail while doing some migrations
from pop mail to imap on my server.
When I drag & drop mails from the local pop account to the imap server,
depending on which smtp server they came thru originally, all the dates
on the header window in mail.app 2.0 are i
Simon wrote:
Hi There,
It looks like we have reached the Max_data_length for the
dbmail_messageblks table, this is currently 4294967295 (which is 4GB
im gussing - which is about right). From the mysql docs, this can be
easliery solved by running:
ALTER TABLE tbl_name MAX_ROWS=10 AVG_ROW
Paul J Stevens wrote:
Taking foot out of mouth... Searching should work just fine, it's just
the sorting that's broken.
Looks like you hit a bug Tommi. Please try 2.0.5 or a recent snapshot,
set trace_level to 5 and post the resulting logs.
Ok, I did the 2.0 snapshot from aug.18, and now with
Paul J Stevens wrote:
Taking foot out of mouth... Searching should work just fine, it's just
the sorting that's broken.
Looks like you hit a bug Tommi. Please try 2.0.5 or a recent snapshot,
set trace_level to 5 and post the resulting logs.
Hmm okay :) But that has to wait tomorrow, I'll chec
Paul J Stevens wrote:
Don't search. Searching and sorting is incomplete and only meant for SM.
And even then only for charset us-ascii.
Yes I figured out that already from reading this list for long time... I
was more like after solutions. Since I cannot find any settings from
Pine to disable
fbsd5.4/amd64, dbmail-imapd 1576
When I'm trying to move from folder to another, I get an error message
"MAIL FOLDER "Lists" CLOSED DUE TO ACCESS ERROR"
When I put the imapd to trace=4 I see the following:
Aug 17 09:24:29 Sammael dbmail/imap4d[135]: COMMAND: [0304 SEARCH OR
(UNDELETED UN
Paul J Stevens wrote:
Try building dbmail with ./configure --enable-shared=no.
Mmm yeah that worked. I wonder why it fails on this machine and not on
the other...
Thanks anyways.
--
br,
Tommi
I think this problem has reared it's ugly head before, but I couldn't
find any solution to this specific problem from google et al.
anyways, this is the 'relocation R_X86_64_32' problem
What I understand from there, is that somehow the mysql shared library
is not compiled with -fPIC. Which is
Greg Muehl wrote:
After reading your email I noticed you had 127.0.0.1 in the main.cf like:
mailbox_transport = dbmail-lmtp:127.0.0.1:24
I had:
mailbox_transport = dbmail-lmtp:localhost:24
I changed mine to look like yours and wallah! Worked without this in the
file:
disable_dns_lookups=yes
Greg Muehl wrote:
Aug 9 16:15:34 redhat postfix/lmtp[12308]: fatal: unexpected command-line
argument: dbmail-smtp
Aug 9 16:15:35 redhat postfix/master[8569]: warning:
/usr/libexec/postfix/lmtp: bad command startup -- throttling
These two lines catch my eye... are you possibly trying to talk
Actually, I was just able to catch a trace=2 message from the logs. Just
after one user logged of, the parent process died leaving the following
lines to the log:
Aug 4 13:54:17 Sammael dbmail/imap4d[4517]: IMAPClientHandler():
Closing connection for client from IP [62.78.198.10]
Aug 4 13:54
I just went from 2.1-someversion down to 2.0-recentsnapshot and I
started noticing that the zombie problem had went away, but there was a
new problem that causes the parent process to die without any trace.
Running on FBSD-5.4-RELEASE/AMD64
I noticed this when lmtp suddenly stopped accepting
On 23 Jun 2005, at 17:08, Ville Ahonen wrote:
Paul, rev 1814 fixed the problem for me.
Ah please excuse my stupidity but how do you build the tools since
the snapshots are without any buildtools etc? Autoreconf doesn't help
either...
--
br,
Tommi
On 14 Jun 2005, at 12:35, Micah Stevens wrote:
How are you setting this up? Did you setup DSPAM as a transport in
Postfix,
and then send to dbmail? Or did you use some other method? I setup the
transport thing similar to a howto I saw on their site, and it
hosed my
setup, so I put it back.
On 14 Jun 2005, at 12:17, Sunny (Yion Kwang) Koh wrote:
Hello All,
I would like to know if anyone has used the users table in dbmail
as a basis for an internal corporate wiki which users are check
against that table for user id and password to allow them to surf
and edit wiki pages? Any
I've run into a problem when trying to implement LMTP deliver from
dspam... the problem seems to be quite simple, dbmail returns code
215 at the end of the communication and dspam expects to get 250.
IMO 215 is also right answer, but would there be a way to stab the
sources (I'm not a progr
On 20 May 2005, at 14:16, Sergey Otinov wrote:
There is no pthread lib in your libs list. Try to add it (-pthread)
into makefile.
May be this help you (for csh)
setenv LDFLAGS -pthread
put it into Makefile and that did it. Of course then I ran into the
timezone bug in the imaputil.c but t
On 19 May 2005, at 17:05, Paul J Stevens wrote:
Tommi,
Sounds to me like glib was compiled *with* thread support, even though
there is currently no thread implementation available on your system.
Perhaps installing a pthread implementation will help.
Hmm, as far as I can tell the system is
Well, tried to compile from sources today, and ran into several
problems:
When doing just the basic ./configure --with-mysql, it goes through
just nicely but then when making, stops at failure to find iconv.h
files. I edited the generated Makefile to add -I/usr/local/include to
the compil
Lorna Sanchez M. wrote:
Hi!
Thanks a lot!
Just one question more: does your implementation uses secure imap
(imaps) and secure pop (pop3s) implemented with stunnel? I ask because
I found this:
http://www.dbmail.org/dokuwiki/doku.php?id=stunnel
"You can use STunnel to provide an SSL encrypted co
Максим Черногор wrote:
dbmail 2.0.4 on FreeBSD 5.4
dbmail-lmtpd or dbmail-pop3d creates zombie processes.
Bug submitted months ago, see:
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=162
same with imapd.
--
br,
Sty
FreeBSD 5.3-RELEASE amd64
# gcc -v
Using built-in specs.
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
# gmake -v
GNU Make 3.80
gmake[2]: Entering directory `/usr/local/src/dbmail-2.0.4/sort'
/usr/local/bin/bash ../libtool --mode=compile
55 matches
Mail list logo
