[Pymilter] Maybe seperate peer queries?

[Todd Lyons]

On Mon, Mar 1, 2010 at 8:27 PM, Stuart D. Gathman <stuart at bmsi.com> wrote:
>> What do you think about a
>> new query type called P which does the same as a Q query except don't
>> create a new UMIS, so it doesnt push it onto the circular queue.
> That could be useful.  That would prevent voting later, but in many
> situations, it is purely a query.  Another way would be an empty or
> otherwise trivial UMIS to prevent adding to the queue.

I think I like that concept a lot better.  Maybe make a provision in a
query such that if the UMIS is less than X characters, it's treated as
a pure informational query, not as something that needs to be tracked.
 Additionally, the result returned could be altered to present more
detail.  I like to see the floating point numbers instead of just the
integers.  I considered altering the message header to do that, but I
figure you obfuscate that for a reason.

OT:
So far my two node gossip system has been running for a little over an
hour on a two server exim mail system.  I'm generating feedback solely
on the spamassassin score: less than 0 points is -1 (ham), 0-4.9
points is 0 (neutral), and more than 5 points is 1 (spam).  Thus far
I've seen on one gossip server:
283 neutral  (31.8%)
539 ham (60.6%)
66 spam  (7.4%)

This is _after_ all RBL checks and header checks.  To put it in
perspective, the gossip server generated 1280 PREPEND responses, but
of those only 888 actually made it past header checks to the point of
getting scanned for spam and sending a feedback response, so I'm
rejecting about 31% of email that made it past my RBL checks, valid
user checks, etc, due to malformed headers, viruses, phishing, etc
(but before spam checks).  That seems high though, so I might be
misinterpreting some data somewhere.
-- 
Regards...      Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm.  -- Marcus Aurealius