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
