Hey Sam - Thanks! I think I understand a lot better, and imagine others do too... And of course if it isn't said often enough - we appreciate that you have a day job too and that there are always priorities... Now, for those of use who want to hack... I have a counter proposal...
First the long term (perhaps nirvana like) and then the short term hack. Long term, it would be nice if a filter could signal - perhaps by exit code, that the structure needed to be reread and reparsed before continuing. On returning a certain exit code, courier could know that an acceptance was given, but that the message was changed, and force an rebuild of the memory structure you mentioned, using the message file as source. There may be a more efficent way to do it, such as distinguishing between header only vs. body mods, etc., but at least this would make the reparsing overhead only a burden to those of us who need it - and it would still be better than resending - right? Short term hack: So we can only make a change if it doesn't alter the position or structure of existing data. That's the key. So lets do just that. Define a buffer size, intended to be large enough to record whatever information you want to modify in a filter.... Then, much like Lloyd has suggested, path submit. Submit will now create a new header: X-Filter-Info: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX You could of course substiture X for any character you like - so long as it doesn't break mail header standards. Then, you could wrap your arbitrary filter data in base64, pad with X's, and replace the old header installed by submit. No message structure alteration, and an editable payload. Could even be done multiple times as needed for diferent filters or purposes - create as many "place holder" padded headers as needed - in fact this could be done generically, by "including" this value from the config file - so that a recompile isn't needed to change the headers.... As submit starts it could append a value from /etc/addheaders to the message. Anyone like this idea? Gets us to the editable header stage a lot quicker, without as much overhead doesn't it? Would I screw something up doing this? Sam: Thanks again for your efforts and the explanation. m/ ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
