Me too. If it's still a long way off, then maybe this is the way to go - on the other hand if Sam can provide some guidance as to where one would have to look to start making such a change - and perhaps what the bigger challenges are, then maybe we can amass enough effort amounst us to make it happen - eh?
m/ > -----Original Message----- > From: Derrick T. Woolworth [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 12, 2004 12:43 AM > To: Mitch (WebCob) > Cc: Lloyd Zusman; [EMAIL PROTECTED] > Subject: RE: [courier-users] My Modest Proposal > > > 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
