If you want a unique (enough) id, why not take the md5sum or sha1sum of the entire message, headers included? Why not it's inode? (Guaranteed to be unique over the lifetime of the file on a given partition.)

It seems to me like all of this work could be avoided if there was a *reasonable* way to

a) inject new messages in place of old ones (this implies that we "stop" delivery of a current message and "start" (better yet, start over with) delivery of a new message.

b) replace *in-place* an existing message. Courier would somehow have to notice this and re-parse the mime structure, etc... of the message and perform whatever other checks it already performs.

The thing is there that "filter" implies a certain mode of operation. By that I mean that it's logical to think that things *ought* to work a certain way, and that way being:

at any stage of the filtering process, the message may be altered in any way. return codes are meaningful. subsequent filters will get the new message (provided return codes say 'stop here', etc...). Think about dot-courier like meaning. Indeed, having "grown up" with qmail, I really dig the idea that I can make my message pass through any number of "filters" that do any damn thing they please to it. I regard some aspects of qmail's .qmail file handling as broken, but the overall concept is very powerful.

I think that what people really want here is the ability to do the same between the esmtpd and the final "queueing" of the message. Sort of like this:

esmtpd -> temporary queuing -> filters -> final queueing (or failure)

and not just for esmtpd but all forms of delivery.