I think its important to the evolution of Courier that it eventually support modification of messages from any courierfilter. I've never quite understood why this isn't allowed - possibly a filesize issue, security? I would only be guessing, but in the grand scheme of things I'm sure there's a lot of folks that would love this ability.
I'd like to hear from Sam regarding the effort to make this modification and perhaps why its so long in coming? Thanks, D -- Derrick T. Woolworth R&D Technology, LLC. 6701 W. 121st, Suite 310 Overland Park, KS 66209 Phone: (913) 491-0345 Fax: (913) 491-1645 Quoting "Mitch (WebCob)" <[EMAIL PROTECTED]>: | Hi Lloyd. | | Would like to hear what others think including Sam - but it sounds like the | best of a bad situation to me. I wonder how the effort and overhead you are | making compare with a patch to courier that would allow modification of | message files during global filtering. Although such an option may lower the | efficiency of delivery perhaps if submitted as a compile time option it | could be acceptable for inclusion in the distribution. | | Personally, I make my hacks as a last resort after trying to ellicit | support, as maintaining them - particularly when dependancies on the core | software may not be broken with future versions. | | I've seen people running filters twice to do rejection and modification | separately - maybe before embarcing on this you might want to do some | benchmarks? | | Just a few thoughts. | | m/ | | > -----Original Message----- | > From: [EMAIL PROTECTED] | > [mailto:[EMAIL PROTECTED] Behalf Of Lloyd | > Zusman | > Sent: Wednesday, February 11, 2004 5:21 AM | > To: [EMAIL PROTECTED] | > Subject: [courier-users] My Modest Proposal | > | > | > In one or two other threads, I mentioned a Modest Proposal for a small | > change in Courier. I'm about to start work on a patch and a piece of | > add-on software that implement this proposal, and so I want to describe | > it here, in a bit more detail. | > | > The problem I'm trying to solve is this: for reasons of efficiency, | > Courier's global filters cannot modify messages. Only local filters can | > do that. Because a global filter can cause an immediate failure during | > the SMTP dialog, there are some functions that are best performed during | > a global filter. But some of these functions make minor changes to the | > message, such as the addition of header fields. SPF is one such | > function. | > | > The recommended solution for this, namely having the global filter | > modify the control file in order to block message delivery and then | > re-injecting a modified version of the message, is cumbersome, | > inelegant, overly complex, and probably inefficient. | > | > Therefore, I propose the following: | > | > A small change is made to Courier (probably only a few lines of code in | > submit.C) which will cause a unique ID to be put into the "Received:" | > header for every message that Courier processes. Because this ID will | > be visible both during global and local filtering, it provides a way to | > match a message going through a local filter with its predecessor that | > might have gone through a global filter. This allows state information | > to be maintained for the life of a message through the local and global | > filters. | > | > I propose the generation of this unique ID instead of using the | > Message-ID header, because we cannot count on Message-ID being totally | > unique. | > | > How does this solve the problem that I mentioned above? Well, a global | > filter that wants to change a message can create an entry in a data | > store using this unique ID as a key. In this entry will be some sort of | > description of the change. Later, when the message passes through the | > local filter, the data store is accessed and the entry is looked up by | > means of this same unique ID. The local filter then interprets this | > data and makes whatever modification is necessary to the message. | > | > As an adjunct to this small patch to (probably) submit.C, I will also | > write a package that can be used within global and local filters to | > manage this data store. Since I'm using courier-pythonfilter for my | > global filtering, I will write this adjunct package in Python. Of | > course, there is no requirement to use this package. Many people | > will just want to ignore this unique ID, and others will want to | > use it in their own ways. | > | > An example should clarify this. Here's how this would work with SPF: | > | > 1. SMTP dialog begins. | > | > 2. A global filter is invoked at the appropriate time in order to | > perform SPF checking. If this test fails, the message is | > immediately rejected. But if it succeeds, we need to add an | > "SPF-Received" header to the message. | > | > 3. Still within the global filter, extract the new unique ID from | > Courier's "Received" header in the message. | > | > 4. Using my adjunct data store package, persist an appropriate | > SPF-Received header, using this unique ID as the key. | > | > 5. Global filter exits. | > | > 6. Later, the message is processed by a local filter ... in my | > case, this will be handled via maildrop. | > | > 7. Very early in this local filter's processing, 'xfilter' the message | > through a homegrown utility which extracts the unique ID from | > Courier's "Received" header in the message. | > | > 8. Still within this xfilter propgram, and using my same data store | > package, try to retrieve any information that might have been | > previously persisted for this message, keyed by this unique ID. If | > there is no such information, skip to step 11. | > | > 9. If information exists, interpret it. In this example, we have | > persisted an SPF-Received header. We then add that header to | > the message. | > | > 10. Delete the data that was persisted using this unique ID. | > | > 11. The xfilter program exits, outputting the possibly modified message. | > | > 12. Process the message through the remainder of the local filter rules. | > | > As you can see, the global filter remains lightweight and efficient, and | > the message modification still takes place in the local filter. The | > only change to Courier itself is the addition of the unique ID to the | > "Received" header, and this is a very minor change, indeed. | > | > I plan to patch submit.C to put this unique ID into the "Received" | > header. Then, I will write my data store package and the utility that | > will be called via xfilter. | > | > I will post everything here when this is working. | > | > Any thoughts? | > | > -- | > Lloyd Zusman | > [EMAIL PROTECTED] | > | > | > | > ------------------------------------------------------- | > The SF.Net email is sponsored by EclipseCon 2004 | > Premiere Conference on Open Tools Development and Integration | > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. | > http://www.eclipsecon.org/osdn | > _______________________________________________ | > courier-users mailing list | > [EMAIL PROTECTED] | > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users | > | | | | ------------------------------------------------------- | 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 | ------------------------------------------------------- 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
