Totally simple! See what Sam is saying is that you CAN change the message file as long as none of the key information changes location... so as long as headers remain the same size, the content can change... as long as body parts remain the same size, content CAN change.

So if we use submit to add the headers, before the structure is built, and just pad them to the largest size to be used, then we can edit them inside a filter without effect on courier.

e.g. add:

Spam-Status: XXX

Replace with: Spam-Status: yes OR Spam-Status: no_

The same could work for anything that desires to add a header to flag a status on a message without resubmission.

The first hack would be to simply add a constant with whatever headers hardcoded (this is within my C ability ;-)

The better hack would be to add support for a config file which would contain a template for all headers to add - could ideally be read as courier is loaded or as submit is run. I'm hoping there is someone C'ish enough to do this - or I can do the former, but the former certainly isn't polished enough for distribution.

Would still be interesting to see what happens... and as I indicated in the bug notice I forwarded to the courier list... SpamAssassin ack the problem, but keep putting off the fix for courier... if anyone interested in courier is PERL friendly, it would be a good thing to get fixed.

If your change makes the Received header more like an Exim receiver header, then it might fix the problem already - worth testing... an indication of the problem is triggering the dynablock rule on mail submitted through the courier server. At least I think that's how it works.

m/