Greetings.
I have looked at the qmail_bounce package, and am somewhat dissatisfied
with it. The logic is excessively convoluted (I want a single response
after a set time, etc.), several easily determined constants are
hard-coded into the program (the queue lifetime, control/me, others),
and it can't tell why the message was delayed. It's also written in
Perl and requires several supporting Perl files whose path must also be
hard-coded into the program. Once simplified somewhat, this program
could just as easily be written in C.
So, I want to write a new one. Ideally, I would like seomthing that
will respond to the sender once, after the message has been in the queue
for at least a configurable time interval. The notification message
should detail all the recipients that have not received the message, and
preferably a message indicating why delivery has been deferred. It may
also limit notifications to senders in rcpthosts, for servers that
function as gateways. The notification should contain at least part of
the original message to help the sender remember what was sent.
I am looking at three possible approaches for data gathering:
1. Use the same approach that qmail_bounce uses -- scan the qmail queue
files for "old" files. Pros: simple, and gives me the sender and
recipient and message times. Cons: still gives no indication about why
the message bounced, and must be run in a cron job.
2. Run as a front-end for qmail-local and (especially) qmail-remote.
Pros: reading the response from the preceding programs tells exactly why
the bounce happened and when, and the message content is available on
standard input. Cons: this requires renaming the preceding two programs
to new names and hard-coding their new paths (a nuisance for package
management systems like RPM, and makes aggregation of notifications
difficult.
3. Run as a reader of the qmail log file, potentially using a multi-file
reader to keep tracking when multilog's "current" file changes. Pros:
the complete state of each message is known at all points, and once this
state is built, timing and aggregation are simple. Cons: parsing the
logs could be expensive; starting the process in mid-stream results in
missing information; reading the original message requires either
knowledge of queue-split and the hash algorithm or a linear scan of the
queue directories.
Do I have any other options? Are there any other issues that I haven't
considered?
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
PGP signature
