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
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
