[Mimedefang] MIMEDefang 2.57-BETA-1 is available

[Steffen Kaiser]

On Thu, 4 May 2006, David F. Skoll wrote:

> The reason I said the change is controversial is this: If you have a
> working filter that "accidentally" relies on state being preserved
> across filter_relay/filter_sender/filter_recipient/filter_begin, that
> filter will almost certainly STOP WORKING.  Whereas with older
> versions of MIMEDefang, such filters would fail only occasionally,
> with the new version, they will fail almost all the time.
>
> In my opinion, this is a Good Thing, because it exposes buggy filters
> quickly.  Nevertheless, do not upgrade to 2.57 unless you're quite sure
> your filter is correct.

Hmm, about the save-the-state topic:

Would it possible to think about to _save_ the state between all the 
functions?

The man page itself tells what to do, however, when the SMTP dialogue is 
rather straigth forward, I mean, when the client does not pause before 
sending the next data, the probability is high, that the same slave is 
still idle and can be passed to request to.

Normally one needs to save the state before finishing the filter_relay, 
filter_sender, filter_recipient and restore it before processing it. 
However, the Multiplexor could call a function to save / restore the data 
itself, if it detects that the slave had been working on another 
transmission in the meantime.

So, saving/restoring the data takes place only, when needed.

Mimedefang could use the mechanism itself, instead of parsing COMMANDS 
each time, it gather the already seen stuff from the saved state and 
captures only new COMMANDS.

Frankly, I have only very few information I would be interested to keep 
from filter_recipient to filter_begin in my current filter, so I would 
probably not benefit from this change much. However, would mimedfang 
itself benefit from the pre-compiled information (say a Storable or 
something like that)? When the saved status is unreadable (e.g. in case of 
a crash), one would need to fall back to COMMANDS file and/or (for the 
user information) tempfail the transmission.

I wonder if there will be any benefit at all. On a low-noise system, the 
spurious save/restore wouldn't count much, I suppose; on a high-load 
system with many connections at the same time, the slaves will probably 
never handle the same transmission twice. So this technique would only 
lower the load on mid-size servers that want to save data, because it had 
to be computed twice (or more often).

Bye,

-- 
Steffen Kaiser