Re: [exim] Exim with SQL message store

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: John Jetmore
Dátum:  
Címzett: Marten Lehmann
CC: exim-users
Tárgy: Re: [exim] Exim with SQL message store
On Mon, May 10, 2010 at 11:15 AM, John Jetmore <jj33@???> wrote:
> On Mon, May 10, 2010 at 10:33 AM, Marten Lehmann <lehmann@???> wrote:
>> Hello,
>>
>> exim is our MTA of choice for more then 10 years now, but we are very
>> unhappy with the message queue. Header, body, delivery attempt logs and
>> delivery hints are spread throughout dozends of subdirectories, text
>> files and berkeleydb files, which make it very hard to look at the queue
>> in depth, like "show subject and queue-in date of all messages by
>> authenticated_id x and freeze them". The exim tools are a nice start for
>> easy tasks, but it is almost impossible to work with the queue and query
>> or operate on it directly since it is mostly text based and only exim is
>> able to get the structure with its parsing routines.
>>
>> I have not looked into the queue source in detail, but does exim keep an
>> abstract layer to access to queue, so it would be possible to replace
>> the current text file queue to an sql backend? Or does each exim twiddle
>> directly in the files, adding delivery attempt counts, new headers etc.?
>
> This sort of stuff is almost exactly why I wrote exipick, have you
> looked at it?  Taking your example, I'd do it in two passes, but it's
> still fairly do-able:


I misinterpretted your examples, here's what you actually stated:

display:
exipick --show-vars h_Subject,received_time 'authenticated_id eq X'

freeze:
exipick -i --show-vars h_Subject,received_time 'authenticated_id eq X'
| xargs exim -Mf
>
> exipick has been pretty stable for a while because it does what I want
> it to do and no one's asked for it to do more.  If you think the above
> id interesting and have ideas for refinements I'd be interested in
> hearing them.
>
> As for a queueing abstraction layer, you're out of luck with what's
> currently in the code.
>
> --John
>