: Loaded 0 events
2016-03-21 01:38:50 75322 [Note] /usr/local/libexec/mysqld: ready for
connections.
On 3/21/2016 3:39 AM, Reindl Harald wrote:
Am 21.03.2016 um 10:07 schrieb Jonathan Feally:
After taking a look in lmtp logs I found:
Mar 21 01:28:57 mail.consult-sc dbmail-lmtpd[74282
Email goes to la la land!
Change small sset api causes my mailbox messages listing to be 0 long.
Rolling back to finish initial sorted-set implementation is working. Tested
and had the problem with Tbird 3.1.2 and my Win Mobile 6.1 Phone - IMAP.
-Jon
On 8/10/2010 7:42 AM, Paul J Stevens
Hold it - I was mistaken. It was not the sset change, it was the
forward port fix for #851 change that caused the problems. I'm out of
brain power tonight to debug, but just so you know.
-Jon
On 8/11/2010 12:34 AM, Jonathan Feally wrote:
Email goes to la la land!
Change small sset api
New fixes seem to have fixed the issue. Chewing on new dog food now, yum!
Thanks,
-Jon
On 8/11/2010 1:12 AM, Paul J Stevens wrote:
Thanks for the heads-up. I'll fix this now.
On 08/11/2010 09:43 AM, Jonathan Feally wrote:
Hold it - I was mistaken. It was not the sset change
I tested MySQL proxy last year, and the delay inserted because of the
proxying was huge. DBMail has a lot of queries just to do simple things
(a lot of IMAP compliance) and it just slows it way down. I think
logging into a mailbox with a user will very little email in the INBOX
went from 0.5
Paul,
This problem still exists on FreeBSD - just did a fresh git and compile.
The version 0.9.9 is the version of mhash on the system as it is setting
the PACKAGE_VERSION defines/declares before we try to set them again to
our version. Perhaps we can just create our own DBMAIL_VERSION to be
of a mhash upstream release that fixes this, of
course, which it won't.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473204
http://mail-index.netbsd.org/pkgsrc-bugs/2008/10/19/msg028900.html
The netbsd patch is just too trivial.
If you have an elegant solution please share.
Jonathan
Nov 20 10:50:10 mail.consult-scs dbmail-imapd[99549]: [0x80373a080]
Debug:[server] server_daemonize(+302): sid: [99548]
Nov 20 10:50:10 mail.consult-scs dbmail-imapd[99549]: [0x80373a080]
Notice:[server] server_run(+594): starting main service loop for [IMAP]
Nov 20 10:50:10 mail.consult-scs
Aleksander Kamenik wrote:
Bret Baptist wrote:
Also looks like the internaldate as UTC is causing issues with Mac Mail
and
older Outlook clients. They are subtracting the time zone offset from the
received time.
I can confirm this. After upgrade to 2.2.12 MS Outlook 2000 user
Paul J Stevens wrote:
It looks like it is happening for post 2.2.12 inserted email. Perhaps only
with IMAP clients, but I was not able to confirm before I rolled back to
2.2.11.
Jon,
Any ideas here?
Oh thanks for passing the ball to me. What timezone is the server set
for?
Jonathan Feally wrote:
The correct operation would be to have the UTC timestamp stored in the
database. When read from the database, it is not adjusted other than to
add + for a timestamp to the reformatted time. The patches
http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h
Did you also backport the adjustments I made for the IPv6 stuff or was
that just your initial commit? It appears not.
see
http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?id=2b3944f4e9617388910a851b9d964b3e859c4099
and tweak
Did you autoreconf -i ??? That will usually create your configure script
and some other stuff.
-Jon
Michael Monnerie wrote:
On Mittwoch 07 Oktober 2009 Paul J Stevens wrote:
Download:
http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/snapshot/dbmail-2.2.12
.tar.bz2
Thanks. Just
The following is a view for MySQL that can be used with postfix to allow
a user to authenticate as one user, but be able to send mail from on of
the attached aliases. Aka, I authenticate as vult...@netvulture.com, but
can send email as jfea...@netvulture.com. With out this sender login
map,
George Vieira wrote:
Yeah I got dbmail configured for multiple servers hosting the same domain (or
others) but need an option to move users to another server hence the question
came up during this post.
DBMail Hyrda - (2.5.x) is planning on a split front-end, multi-back-end
setup to
Michael Monnerie wrote:
On Donnerstag 17 September 2009 Paul J Stevens wrote:
No way around that without full text indexing.
Any chance to have FTI support? PostgreSQL 8.3 has that built-in AFAIK,
so it could be interesting. Dbmail could support it if the DB supports
it, I just
/dbmail'
make: *** [all] Error 2
lira:/usr/local/src/postfix/git/jon/dbmail#
-Original Message-
From: dbmail-dev-boun...@dbmail.org [mailto:dbmail-dev-
boun...@dbmail.org] On Behalf Of Jonathan Feally
Sent: quarta-feira, 16 de Setembro de 2009 2:38
To: DBMAIL Developers Mailinglist
Jorge Bastos wrote:
On Dienstag 15 September 2009 Jorge Bastos wrote:
IMAPD crashed, and when I go to start him this happen.
Then the diff seems that the TCP connections are not closed on crash in
the one version, while the other does. Or the crash happens in a
different path,
I'm working on the more correct way to handle getaddrinfo as it can
return more than 1 address that should have a socket on it. This should
have the sockets with the REUSE flag on it and work correctly. Since the
IPv6 code, my box is completely unhappy with those and SEGFAULTS upon
start up. I
Your multiple IP's could be handled better with my testing branch. It
all depends on what you are putting in bindip.
My patch make no attempt to detect that we are already listening on an
IP:port pair, so some adjustment may be needed on bindip in some cases.
I was able to test a simple
bindip
Simon Gray wrote:
Michael Monnerie wrote:
Note:
Everybody who care about their data, you should leave this setting on
it's default 1:
innodb_flush_log_at_trx_commit=1
Also, this will only affect writes - rather than reads.
If you have minimal writes and the server is on a
Shane,
Briefly looking at the two RFC's, i think we could do this, but it will
take some work. This would have to go into the 2.3.x branch. What client
are you using that is supposed to support CONDSTORE and QRESYNC?
Paul,
I think we can add a modseq bigint to the messages table. This value
Ken D'Ambrosio wrote:
How much data are you searching through? (how big is your dbmail db?)
Roughly 100 GB; it's got 750K messages or so.
You need to clean and optimize your tables. With a quick calc, that
would put you at about 140MB/message. Are you on 2.2.x or 2.3.x?
You should
Ok - but your sliderule is bent too.
139KB/message looks more correct. I must have had too many 1024's in
there to the first time.
Ken D'Ambrosio wrote:
Thanks for all the pointers! Though I'm afraid your sliderule* dropped a
decimal: 1*10^11 / 7.5*10^5 = 13., or 13K/message. I'm
What database server and version are you using? This seems like an older
database not able to handle that query.
-Jon
David Young wrote:
Hi, I recently upgraded my dbmail to 2.2.11 and decided to create a
new email account/mailbox to make sure everything is working
correctly. I sent
sendmail_destination_recipient_limit = 1
This could be the wrong option, but I'm not sure of the right one if it
is needed at all.
Jonathan Feally wrote:
You can try to make your distribution lists using an external forward,
and set postfix to send the message to each recipient instead
You can try to make your distribution lists using an external forward,
and set postfix to send the message to each recipient instead of trying
to group them into a single message. This would effectively make the
message be received by dbmail-lmtpd and then resend the messages back to
postfix
Ok,
I will chime in now with your answer,
In your databases create the view to merge users with their aliases:
CREATE ALGORITHM=UNDEFINED definer=`ro...@`localhost` SQL SECURITY
DEFINER VIEW `dbmail_postfix_map` AS select `dbmail_users`.`userid` AS
`user`,`dbmail_users`.`passwd` AS `passwd`
Michael Monnerie wrote:
Why not just download source and compile it?
Packages are nice, but I never restrict myself to just the available
packages. If it isn't available as a package for a production box, then
test in dev real quick, then get it compiled in production and move on.
Of course
I have not added anything additional to track this issue. Did you try
your current binaries against a freshly created database? You can start
a 2nd instance on a different port using a separate dbmail.conf to
quickly test this.
-Jon
Jorge Bastos wrote:
Hi Jon,
To keep tracking the source
Part of fixing this bug was to make sure that the session is properly
closed and deleted. I can't find what has been missed on session cleanup
when comparing a session that is in an idle loop vs. a session that did
a logout. If I left the session cleanup broken (doesn't do it) then I
never got
Well,
If you are looking for the used space of the user in general, then
dbmail_users.curmail_size is the column you want.
SELECT curmail_size FROM dbmail_users WHERE userid=theuser;
But I think you want to get a per mailbox (folder) look, so:
SELECT users.userid user, mbx.name mailbox,
OK - 2nd try forgot the
WHERE msg.status 2
If you don't include the msg.status 2, then you will be counting all
messages, whether deleted or not.
status=2 deleted (expunge done), status=3 deleted waiting for purge run to
actually be deleted.
Well,
If you are looking for the used space of
Jorge Bastos wrote:
Hi Jon,
Jorge Bastos wrote:
John Paul,
To recreate the complete cache, can i:
---
Delete from dbmail_header;
Delete from dbmail_headername;
Delete from dbmail_headervalue;
Delete from dbmail_envelope;
Dbmail-util -by
Yes - delete from all 4 tables. Do
You are using dbmail-deliver with sendmail?
Try setting your syslog to level 511 and running again. I don't like the
syslog logging as it cuts off messages, but it should give us more than
stdout/stderr that is lost with sendmail piping to dbmail-deliver.
-Jon
--
Scanned for viruses and
Piotr Wadas wrote:
Error:[message] _header_value_get_id(+1577): SQLException: ERROR: value too
long for type
character varying(255)
Michael Monnerie wrote:
--sysconfdir=/etc/dbmail
I do not know if the man page compilation can use that setting to insert
the correct value. The man page will read:
-f configfile::
Specify an alternate config file. The utilities are currently
hardcoded to use /etc/dbmail.conf for their
Jorge Bastos wrote:
Hi Jon,
Did you missed my email? :P
I didn't miss it. Just haven't had time to reproduce yet. The bt will
show self=0x??? on imap_idle_loop()
The errorlog should also show that session.
-Jon
--
Scanned for viruses and dangerous content by MailScanner
You will need to be more verbose about your problems when requesting
help. We are not mind readers.
If you are trying to run 2.2.x, then you need to compile --with-mysql or
--with-pysql
If you are trying to run 2.3.x, then your libzdb needs to be compiled
with the correct database support.
Jorge Bastos wrote:
Howdy,
I’d like to confirm that i don’t have any lost mailbox’s on the DB,
can you give me an sql query example to check this?
Jorge,
I'm pretty sure that the dbmail-util -t already does that check. I have
a patch I'm testing to help with db locking during that type
Edson F. Cunha wrote:
Jul 28 14:13:42 x.x.xxx.xx lt-dbmail-pop3d[23598]:
Error:[server] server.c,server_run(+278): unable to drop privileges
Jul 28 14:17:09 x.x.xxx.xx lt-dbmail-pop3d[23674]:
Error:[misc] misc.c,drop_privileges(+76): could not find group nogroup
Looks like
Piotr Wadas wrote:
Hello,
I've read this (quite old)
http://www.nabble.com/Group-quotas-td7814443.html#a7814443
What's the current status of this ? client_idnr column is still present,
and there's field_cid in ldap configuration in dbmail.conf
Can I ask some up-to-date explanation how
Michael Monnerie wrote:
Is this a know bug?
When I receive mail from this guy, in Zarafa/Outlook it stores the
header like this:
From: =?windows-1252?Q?M._Oostergo?= m.ooste...@zarafa.com
Is this when you retrieve the message from a non-dbmail pop3/imap server?
But when received over
Casper Langemeijer wrote:
Hi All,
What is the correct way to implement out of office replies for dbmail
2.2? I see people on this list using sieve (vacation), but I've used
an entry in dbmail_auto_replies, and I think (but am not sure) that
I've seen that one work before.
auto-reply and
Michael Monnerie wrote:
select * from dbmail_messages where physmessage_id IN (select
physmessage_id from dbmail_subjectfield where subjectfield like
'Annoying%DELETE THIS MESSAGE%');
Instead of select * simply write DELETE and those messages are gone.
mfg zmi
I'm glad you responded
Jorge Bastos wrote:
Jon,
No good,
Still happens, on g_free(D-data)
Well, I'm at a loss on this. For now just comment out the changes and be
aware of the memory leak so you can use it.
To reproduce the problem, you are just having a client login, select
mailbox, send idle command, then
Jorge Bastos wrote:
John Paul,
To recreate the complete cache, can i:
---
Delete from dbmail_header;
Delete from dbmail_headername;
Delete from dbmail_headervalue;
Delete from dbmail_envelope;
Dbmail-util -by
Yes - delete from all 4 tables. Do take your daemons down while doing
Jorge Bastos wrote:
PS: there are some other issues with current GIT but I'll create a bug form
them.
The most crazy one if this fix:
http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?id=02b0fe06c4947fb50b
dcbe3ac39661006f78aa07
this causes an invalid pointer on dbmail-imapd (o posted
Jorge Bastos wrote:
Ops, still has the problem, check:
[New Thread 0xaecffb90 (LWP 19496)]
[New Thread 0xae4ffb90 (LWP 19497)]
*** glibc detected *** /usr/local/sbin/dbmail-imapd: free(): invalid
pointer: 0x0805cca0 ***
=== Backtrace: =
/lib/libc.so.6[0xb7c0cac5]
Perhaps we should have a status column on dbmail_users like we have on
messages.
0 = disabled
1 = enabled
2 = deleted
3 = purge ok
Then on the dbmail-util run it will moved deleted to purge - then
really delete the purge like we do with messages.
-Jon
--
Scanned for viruses and dangerous
All,
I finally got around to playing with timsieved and found that the
avelsieve was slightly busted.
Patch at:
http://www.netvulture.com/avelsieve_fix_prototype.diff
svn co
https://email.uoa.gr/repos/squirrelmail/avelsieve/main_plugin/trunk
avelsieve
You will also need the patch just
Jorge,
Please fill in answers inline:
Prior to moving to post 2.3.6 git head, what version were you running?
What upgrade sql scripts did you run?
Did you run the latest 2.3.5-2.3.6 upgrade script? It is different than
previous 2.3.5-2.3.6 in pre-2.3.6 git head
Version of gmime?
Way to
Jorge Bastos wrote:
@Jonathan: Do you have the script/the mail kept in you sent folder?
I'm not sure what is needed. The script for Uwe was based upon his
current database schema and i'm not sure what version level that script
took him to.
Send me offlist a mysqldump -d of your
With INNODB you need to run optimize table dbmail_mimeparts to reclaim
space. Deleted rows do not get overwritten, just lost from the index.
Optimizing will copy all active rows to a new file and then swap them,
and delete the original table. So you need to have enough free space for
the data
Dan,
I'm not sure who put that in the UPGRADING doc, but 5.0.x will work
fine. I have not tested 5.1.x for performance fixes in a while. 5.1.x
could be ok now, but if you can run 5.0.83 then do that for best bets. I
have not tried 5.4.x, so I can't comment on that other than its pretty
new.
Something is missing in the constraints or dbmail-util clean up. With 0
messages, then headernames/headervalues should be 0 as well. I'm glad to
see that headers is 0 as it should be.
These should clean up the extra rows. Please note that these will take a
while on a database with a lot of
There is a sql migration from 2.2 to 2.3 that needs to be done in
addition to dbmail-util runs. This could take longer than you expect to
do. I'm not sure what the response difference is between 2.2 and 2.3
that needs to be corrected. Perhaps I'll test it later to see what I get.
-Jon
Gordan
Paul J Stevens wrote:
New features in this release:
There is also a new option -M on dbmail-util to migrate 2.2 messageblks
stored messages to the 2.3 single-instance storage. Messages are moved
1 per run of dbmail-util. You can change the 1 limit with a -m #
argument.
-Jon
--
Jake Anderson wrote:
Any chance of debs of this?
It makes upgrading much easier ;-
Oh and is there anything to migrate headers over to the new storage as
well?
Debs would be Paul's dept.
Part of upgrading to 2.3.6 removes the old header caching tables and
creates new ones. dbmail-util then
Paul J Stevens wrote:
New features in this release:
There is also a new option -M on dbmail-util to migrate 2.2 messageblks
stored messages to the 2.3 single-instance storage. Messages are moved
1 per run of dbmail-util. You can change the 1 limit with a -m #
argument.
-Jon
--
Jake Anderson wrote:
Any chance of debs of this?
It makes upgrading much easier ;-
Oh and is there anything to migrate headers over to the new storage as
well?
Debs would be Paul's dept.
Part of upgrading to 2.3.6 removes the old header caching tables and
creates new ones. dbmail-util then
Jean Naimard wrote:
$ dbmail-users -l *
Jun 26 17:34:45 domus dbmail-users[11177]: Error:[sql]
dbmysql.c,db_connect(+172): mysql_real_connect failed: Access denied for
user 'dbmail'@'x' to database '/var/lib/dbmail/dbmail.db'
Failed. Could not connect to database (check log)
Command
Piotr Wadas wrote:
dbmail_physmessage| 994
dbmail_fromfield | 994
These match - that is good - should be one from header for each message
dbmail_envelope | 1057
A couple extra maybe?? Not too far off.
dbmail_tofield| 5011
This is
Piotr Wadas wrote:
The count(*) result is zero, anyway rows are still available in mentioned
tables, as listed :/
Well then it sounds like the tables just need to be shrunk/optimized in
postgres. I'm not sure what the syntax is to do that as I'm a mysql guy.
-Jon
--
Scanned for viruses
Jorge Bastos wrote:
I think there's something incomplete on that function 'cause when I used the
git version when that was added, messages were not being completely removed.
It might be that we are missing the partlists cleanup. If the parts
aren't being deleted, then that
What tables still have a lot of rows?
select count(*) from dbmail_xxx;
For a single user, you should probably have 10 rows in all of the
tables. Let me know what tables still have more than that.
-Jon
Piotr Wadas wrote:
Garbage collection on dbmail_mimeparts is still missing.
: [Dbmail-dev] New Idea
Jonathan Feally wrote:
Jorge Bastos wrote:
166319344 bytes RX, well not possible!!
I assumed that the values would start at 0. I have set them to 0 at
the
clientbase_t creation so give that a shot.
Jon,
Not such a strange
Jesse Norell wrote:
That's exactly what dbmail_pbsp does already, just in a separate table.
Maybe you just need to enable pbsp in your config file? (I don't
remember that support being removed, but it's possible. It's still in
the sql schema though.)
The pbsp is only used with the pop3
Since I made the patch, I'll comment:
Messages at this point do not have to be moved to the new single storage
structure. Retrieving messages that are not found in the partlists table
will be attempted from the messageblks. This option is there to
convert/move the messages stored with the 2.2.x
content by MailScanner
From 00280656be2f31d3e620b30bf7960c0ad7463a22 Mon Sep 17 00:00:00 2001
From: Jonathan Feally vult...@netvulture.com
Date: Fri, 12 Jun 2009 17:16:32 -0700
Subject: Add dbmail_authlog table and code to record logins, logouts, r/w byte
counts. Fixes pop3 bailout.
---
sql/mysql
Paul J Stevens wrote:
But first, let's get 2.4 ready, starting with 2.3.6! Almost there, we are.
Someone been watching Star Wars has he?
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Paul J Stevens wrote:
Some kind of replication of the dbmail_users table across database
servers would still be required, like we do now between ldap and sql.
That would allow *any* of the database backends to function as the
primary backend - in fact, any of the active daemons/tools would be
Michael Monnerie wrote:
But how do you delete messageblks without their entire message? There
are lots of constraints all over the place. You'd need to redefine
those. OK, as there will be no more old inserts, it shouldn't really
hurt to loose those.
If per-user is not good - what would
Paul J Stevens wrote:
Jon,
there's no need to update the header cache.
Ok, I wasn't sure. I didn't think it needed to be done. Throttling the
movement would be difficult. While the processing could be done on
another box separate of the production daemons, the database load and
disk
Paul J Stevens wrote:
Other than the lack of any perceivable added benefit (for me at least),
my main objections are with regard to change management and security.
For example, I like being able to stick /etc/dbmail/ into a git
repository. And I *really* don't want my ldap bind_dn parameters
Michael Monnerie wrote:
Also, have a single upgrade script to upgrade any schema version to the
newest would be very appreciated. So people who have an early 2.2 would
also get the newset indices etc. A table version would be nice to have
where a single dbmail-schema value is included.
Jake Anderson wrote:
Aaron Stone wrote:
We dropped the dbmail_config table very early on, between DBMail 1.1 and
1.2. There were good reasons to have a configuration file, and once things
started going in there, having two places to configure the daemons seemed
like a bad idea. One
cff34685a26a080ef3f43e7c32c33dcc2839a595 Mon Sep 17 00:00:00 2001
From: Jonathan Feally vult...@netvulture.com
Date: Mon, 1 Jun 2009 09:42:57 -0700
Subject: [PATCH] remove auto_reply and auto_notification completely
---
dbmail.conf | 20 --
sql/mysql/2_3_5-2_3_6.mysql |4
Paul,
You missed the DATE sort option.
SORT has options for:
ARRIVAL (internal_date)
CC
DATE
FROM
SIZE
SUBJECT
TO
with the optional REVERSE tag in front to sort in opposite order.
I'm not sure it runs any faster with views than with the larger query.
Since you are left joining the view, it does
Nachricht-
Von: dbmail-boun...@dbmail.org [mailto:dbmail-boun...@dbmail.org] Im Auftrag
von Jonathan Feally
Gesendet: Donnerstag, 28. Mai 2009 03:46
An: DBMail mailinglist
Betreff: Re: [Dbmail] dbmail performance test
It would be very nice if you were to compare the new 2.3.x from git vs
What is the command line you/your client is issuing? I do not think that
it is a sort, as message-id is not one of the fields for sort that can
be used.
-Jon
Maxim Podorov wrote:
I installed the latest code, fixed DB structure, rebuilt caches, and now
the IMAP search on text headers
Paul J Stevens wrote:
Jonathan Feally wrote:
What is the command line you/your client is issuing? I do not think that
it is a sort, as message-id is not one of the fields for sort that can
be used.
Still, the setup in dbmail-mailbox.c,_append_join_headervalue is broken
imo
That's the yucky part, that is not needed.
I just pushed a cleanup that should at least put us back to where we
were before the headertable change in terms of correctness. There are
very likely still some issues with search as Michael reported, but
hopefully no new issues.
I had the sql
Paul J Stevens wrote:
Jonathan Feally wrote:
The emailaddr column is used for sorting only. The headervalue column is
what is used for the where clauses.
Jon, in your latest code, the emailaddr/emailname columns are never used
again after insertion. We really shouldn't be storing
Thats ugly. I am having no issues on my FreeBSD box. Just run a fresh
clone a few minutes ago. I'm not sure where that confstatBD6747
directory came from. My guess is something is broken on your box. Did
you try it on another machine?
-Jon
On 5/30/2009 11:17 AM, Uwe Kiewel wrote:
Hi,
Sounds like we need to setup on the first x chars for indexing of those
columns. How many addresses were in the to: field? I'm not a postgres
guy, so I don't know how to do an index on the first x chars of the
field. From the error message below, it looks like we could use a size
of 2048.
a lot more brain power to program this once, but I think it's a
huge benefit over the currect (2.2.x) situation.
On Donnerstag 28 Mai 2009 Jonathan Feally wrote:
From the error message below, it looks like we could use a size
of 2048.
MySQL can only index 255 chars :-(
mfg zmi
It would be very nice if you were to compare the new 2.3.x from git vs.
2.2.x. I suspect that the size of the database will be much less than
your 2.2 install and would like to see what performance difference there
really is. If you were to run this test, please copy all the messages
into a
Looks like I missed that use of the datefield. I'll get a patch over to
paul for commit later on today. Your attempt will work for the time
being, but the joins need to be done a bit different for performance
reasons.
-Jon
Максим Подоров wrote:
Paul, during IMAP search, SQLExceptions are
See -
http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/tree/dbmail.schema?h=dbmail_2_2
We no longer use svn. I'm not sure as to how correct this schema is, but
it should be better than what that old svn version shows.
-Jon
Gordan Bobic wrote:
Hi,
Can anyone confirm if this is the most up to
dbmail off the same user account?
Thanks.
Gordan
Jonathan Feally wrote:
See -
http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/tree/dbmail.schema?h=dbmail_2_2
We no longer use svn. I'm not sure as to how correct this schema is, but
it should be better than what that old svn version shows
Kevin,
Since you are just trying it out, give the 2.3 branch a test. When 2.3.6
comes out, I would say you would be relatively safe to move to the new
2.3.x storage infrastructure. A few more changes are going to be in the
database schema in 2.3.6. Possible a couple more that I'm working on
Kevin Monceaux wrote:
I tried to build 2.3.5 and hit bug 757. The version of libzdb in
ArchLinux's package repository is version 2.4.
libzdb 2.3 and 2.4 support will be in 2.3.6. I think I'm holding up the
2.3.6 branch with my latest ideas. I'll get to work on giving Paul the
final
A simple way to determine who is at fault is to set
tmpdir=/usr/mysql.tmp in my.cnf.
cd /usr
mkdir mysql.tmp
chown mysql:mysql mysql.tmp
vi /usr/local/etc/my.cnf
insert or change tmpdir=/usr/mysql.tmp (this does not effect the
/tmp/mysql.sock)
/usr/local/etc/rc.d/mysql-server restart
It is not a hugh deal as a bigint(21) column can hold something like
|9223372036854775807 messages. The cause of this is the way that
messages are delivered. They are first delivered to
_...@!internal_delivery_user!@__ to create all of the physical message and
cache entries. Then, for each
When you import a message with the script, is there a header being
inserted that matches your existing UIDL's? If you UIDL is being put in
the message headers, then we should be able to grab that out of the
header and update uidl all in sql. If that is the case, send me some
sample header
Check your mysqldump -t dbmail against the create_tables.sql to find any
differences that need correction. You could also sent that output to me
offlist so I can try to figure out where it went wrong.
Also, you are moving from which 2.2.x to 2.3-git (post 2.3.5)??
-Jon
Uwe Kiewel wrote:
idle_status = (yes/no) will change the behavior of what is sent to the
client when the idle timeout hits and the client has said idle. Normal
output is to only send information about the SELECTed mailbox. This
option will check all subscribed mailboxes, and send information about
any mailbox
Yeah - thats not the right flag. use -d for no data.
Thats what I get for using my memory instead of my man!
-Jon
Uwe Kiewel wrote:
Jonathan Feally schrieb:
Check your mysqldump -t dbmail against the create_tables.sql to find any
differences that need correction. You could also sent
I have been using trunk as is since you applied my last patch. I haven't
been able to catch the 100% load issue since then, but I have also been
restarting every 2 hours via cron just in case it happens when I'm out
and about. So far its working good with no issues on T-Bird.
-Jon
Paul J
1 - 100 of 164 matches
Mail list logo
