Michael Lang wrote: > thinking about, what's more complex, using another 'singlepoint of > failure' within your filter (ramdisk, dbbackend, cache,...) or just > using Mimedefang 2.56 which just handles slave requests with one > instance (so your query can be stored for one email in Variables).
Michael, you are living dangerously. *Most* of the time, 2.56 handles all requests for a given e-mail in one slave instance. However, that's not always the case. If you rely on that behaviour, your filter will occasionally fail in mysterious ways. In 2.57, the filter will fail reliably, which (IMO) is a lot better -- it at least makes incorrect assumptions obvious. > I'm running 2.56 as i additional count RFC ignorant or CountryBases > Scores to Spammassassin Tagging scores from filter_recipient to > filter_end so the request must stay on the instance, but maybe thats a > feature Request for David to be able to select the Queuing/Scheduling > Algorithm within the same Version ? ... Sorry, no. Changing the scheduling algorithm won't help, because depending on mail load and when a slave happens to be terminated, there's no way to guarantee that all requests for a given message happen in the same slave. Regards, David. _______________________________________________ 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
