Lloyd Zusman [EMAIL PROTECTED] wrote: > You indeed have to read that message ID from the "Received:" header, > because there is no other place to get it.
I first thought I could get the queue ID from the control files's base name, as implied by the Courier queue documentation[1] in the section "Adding messages to the queue" in step G. But in step H it gets renamed to something different, so that's not an option. I think having to parse the message text, and the highly structured "Received:" header in particular, to obtain the queue ID is not very elegant. Sam, would it be a good idea if the queue ID were available from within the control file as a control record? > That's the reason and the > prime motivation for my putting forth that proposal and then doing the > work. I wanted to accomplish exactly what you are working on within > Courier::Filter (that is, to use that ID as a key for storing message > information that can later be retrieved in a subsequent Local Filter > step), and there was no way to do this unless such an ID were to be > included in the message itself. Yeah, I know the story. I also know that courierfilters cannot modify the message due to MIME-related optimizations in Courier. But now I'm beginning to wonder whether this is all still in proportion. All these inelegant work-arounds we're currently implementing are so complicated that the optimizations which prevent messages from being modified in the first place look pretty useless with regard to CPU load and memory usage. Maybe there should be a configuration flag to disable these optimizations if one wants courierfilters to be able to modify messages. Then all these work-arounds wouldn't be necessary. > Fortunately, that ID is guaranteed to always be found within the topmost > "Received:" header, so it should be fairly straightforward to extract it > during an early Courier:Filter processing step. Yes, it's inelegant, but at least it's not horribly ugly. ;-) References: 1. http://www.courier-mta.org/queue.html ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
