Valdis wrote: #Most spam-fighting efforts on the technical side make the basic assumption #that spam has similar characteristics to a properly designed TCP stack - that #dropped/discarded spam-grams will trigger backoff at the sender. Unfortunately, #discarding a high percentage of the grams will trigger a retransmit multiple #times. Actually, our experience *does* follow the backoff paradigm: if you block a particular source of spam, that rejection *does* seem to trigger "message volume" backoff at the source, with only periodic check probes apparently designed to see if the spam source is really still blocked (and of course it really still is). Now it is true that in many cases the spammer *will* do a set of probes in an effort to see just how broad a given block is (e.g., is it just a /32 that's being blocked? is it my entire netblock? is it a domain based filter? can I slide in via an open SMTP relay or an abusable proxy server?), but at least here at the U of O, we're NOT seeing spammers waste their time attempting delivery of hundreds or thousands of messages per day via hosts that have been identified and filtered. Regards, Joe