Alessandro Vesely <ves...@tana.it> writes:

I'd just like to inject some more food for thought into this discussion.

A year or so ago, I submitted a patch to include Courier's queue ID into the "Received:" header that Courier writes into a message. The purpose of this was to aid in the modification of messages during filtering. The way I envision this working is as follows:

Step 1: A message arrives and is fed through a courierfilter.

Step 2: The filter decides that the message needs to be modified in some way, so it writes some information into a database that describes the modifications to the message, using the queue ID as a key. For example, this database might be some sort of dbm file.

Step 3: The courierfilter then accepts the message, as is.

Step 4: Later in the message delivery chain, this same message is routed through maildrop. At this point, the message can be modified.

Step 5: A maildrop recipe uses this same queue ID to look into the database mentioned above. If it finds modification instructions that are keyed to this queue ID, it alters the message in the way that the instructions stipulate, and then it delivers the message or passes it on for further filtering.

Although this is a multi-step process that requires cooperating courierfilters and maildrop recipes, it doesn't require any changes to Courier's current message-delivery procedure.

The queue ID is the field within the first "Received:" header that looks like "id 080DDC27.45A9E14A.0000755B". It's guaranteed to be unique during all steps along the message delivery chain for any given message.