On Mon, Sep 25, 2000 at 04:08:08PM -0700, Ihnen, David wrote:
> I want to make sure I don't email djb without having a real legitimate
> question.
Don't email djb with qmail questions *ever*. That's what this list is
for.
> Are any of you aware of qmail internal data structure/logic documentation
> for the qmail programs?
There's INTERNALS, and "The big qmail picture" somewhere at
www.nrg4u.com (link is on www.qmail.org).
> It sure works nicely, but its a desert in there when you gain your
> sustenance from comments so you have a clue what each function is recieving,
> doing, and returning.
You need to get the hang of djb's coding style. Once you're into it,
it's very workable.
> From my browsing I have determined there is some extensive array data
> structure in memory whose definition is not quite obvious. (to me at least)
>
> So why would I ask such an absurd question?
>
> I'd like to show some people with cranial-rectal syndrome that are busily
> reinventing the mail delivery wheel that the back end they already have
> programmed can be inserted into qmail's processing.
That's usually possible, yes :)
> Instead of going straight from reciept to the delivery queue, it would go
> into a processing queue, and hopefully in a manner similar to
> qmail-remote/qmail-local rules, a qmail-process queue would then kick off a
> various processing filters based on a number of rules. The messages may or
> may not be returned to qmail for delivery after processing.
>
> Do you think its possible to insert such logic without changing the whole
> flow of qmail?
Just replace qmail-local with your program? What's wrong with .qmail,
perhaps?
> Its important that I maintain the original envelope, which to my knowledge
> will be lost if I try to use .qmail sorts of mail processing functionality.
Fix your knowledge. qmail protects envelope information with it's life.
Envelope information is *relevant*, and it's still there in .qmail.
Greetz, Peter
--
dataloss networks
'/ignore-ance is bliss' - me
