> -----Original Message----- > From: Lloyd Zusman [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 15, 2004 7:48 PM > To: Mitch (WebCob) > Subject: Re: [courier-users] Re: My Modest Proposal > > > "Mitch \(WebCob\)" <[EMAIL PROTECTED]> writes: > > > [ ... ] > >> So ... I would request that Sam just expose the internal message > >> structure to us during a global filter, and then give us the tools to > >> hang ourselves. > > > > I agree with you totally, BUT I thought this would be a low effort > > solution to allow header mods without the complications of forcing a > > rebuild of this internal sctructure - which is certainly beyond my C > > capability... with this, adding a Spam: yes or Spam: no_ is easy, and > > doesn't require a reject / resubmit. > > Have you looked through the code to see how easy this change would be to > write?
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. > >> I'm going to continue pushing for my "id" solution as part of the > >> "Received:" header. Please don't take this as a rejection of your good > >> ideas. I just think that a unique ID is a beneficial addition to the > >> "Received" header, especially since it's part of one or more RFC's, and > >> because other MTA's implement it. > >> > >> There is nothing about that "id" field which precludes any of your > >> suggestions. > > > > Nope - understood - the only qualm I had about this is that we are > > already partially screwed for spam assassin support - the more we mod > > our receive headers the worse it will be. > > Well, the "id" field has been in one or more RFC's for years. At least > one other MTA, namely exim, uses this "id" field exactly as I use it > here: it contains the queue ID (I just posted a patch to use this queue > ID instead of my own, home-grown unique ID). > > Therefore, I doubt that this will have any added impact on SpamAssassin. 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/ ------------------------------------------------------- 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
