Bert Slagter wrote:
> Hello all,
>
> Using a webmail client I insert messages in the database directly
> (dbmail_messages, dbmail_physmessage, dbmail_messageblks). DBMail 2.2
> has all kinds of (very useful) cache tables, like dbmail_envelope and
> dbmail_datefield.
>
> The dbmail_util program repairs these messages without cache entries:
> dbmail-util -b. I did this manually, first dbmail-util -b and then
> dbmail-util -by.
>
> Repairing DBMAIL for cached envelopes...
> Ok. Found [89] missing envelope values.
>
> The problem is that now every physmessage has 2 (two!) dbmail_envelope
> entries.
>
> mysql> select * from dbmail_envelope where physmessage_id = '353694';
> +----------------+--------+--------------------------------+
> | physmessage_id | id | envelope |
> +----------------+--------+--------------------------------+
> | 353694 | 353651 | ("Thu, 08 May ... smail.net>") |
> | 353694 | 353740 | ("Thu, 08 May ... smail.net>") |
> +----------------+--------+--------------------------------+
> 2 rows in set (0.00 sec)
>
> This results in messages being listed twice in our webmail overview.
>
> I've three questions:
> 1. Is it a bug in dbmail-util that two entries in dbmail_envelope are
> inserted?
Not in dbmail-util, but in the schema. There should by a UNIQUE key on
the physmessage_id field.
Double entries could happen if two dbmail-util processes are running
simultaneously against the same database.
Dbmail-util -by does:
- collect a list of physmessages which do not have any values in the
_headervalue table. In that case assume no caching has been done for
that message.
- for each physmessage in that list: retrieve the message from the
database and re-do *all* headercaching.
In your case, I can't even be sure the messages where stored 'correctly'
to begin with, making it rather difficult to tell where this came from.
Please consider that dbmail-util -by is *not* designed to detect and fix
all inconsistencies in your cache tables. It was meant only as a
one-shot migration tool.
Inserting messages into the database directly (without respecting the
cache tables) is a /bad/ idea. I've said so before many times. It will
be near impossible in 2.4 with the single-instance storage paradigm.
The only supported injection pathways are: dbmail-smtp (aka
dbmail-deliver in 2.4), dbmail-lmtpd, and IMAP APPEND.
In your case: please use IMAP APPEND or dbmail-smtp.
> 2. Should I trust that dbmail_envelope has only one entry per
> physmessage? This increases speed because no "GROUP BY physmessage_id"
> has to be done.
GROUP BY is not used by the dbmail-imap server. If you talk to the
database yourself, you should add the UNIQUE key as I said above.
> 3. Is it a problem if a message doesn't have cached headers/envelope for
> normal imap access?
It is a problem. Those tables are used by and for normal IMAP access.
x FETCH 1:* (ENVELOPE) hits the _envelope table
x FETCH 1:* (BODY.PEEK[HEADER.FIELDS (From To Subject Date)]) hits the
_headervalue table
x SEARCH 1.* (BEFORE 1-Jan-2008 SENDER [EMAIL PROTECTED]) hits the
_headervalue tables
etc....
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
