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
