http://bugzilla.spamassassin.org/show_bug.cgi?id=1375
------- Additional Comments From [EMAIL PROTECTED] 2004-02-03 22:27 ------- > q for the people who've tested Florian's patch -- what's the speed hit like? difficult to measure due to performance being relative to general system performance. Counting the number of DNSBL lookups seems necessary in this context as well. How'd we go about this? Local stats here, based on spamd logging: Celeron 533Mhz machine with avrg. load approaching 2.0 during mail receipt: full SA bayes, full SA network tests - minimum scan time per mail with spamd = 0.5s - stats since Nov 22nd (2.5 months of data): 57,779 mails scanned 397,921 cumulative seconds logged by spamd 6.88s average per mail scanned. 95th percentile: 25.5s 90th percentile: 16.7s 80th percentile: 10.2s 70th percentile: 6.2s - weekly averages in the last 4 weeks, (Sun-Sun): 7.1s (ending Jan 31) per mail scanned 8.7s (ending Jan 24) 12.6s (ending Jan 17) 10.8s (ending Jan 10) - 13 HOSTED_AT_* rules activated (score != 0) - 10 HOSTED_IN_* rules activated (score != 0) This system slows down to a crawl with a load > 5.0 when SpamShield, dummy-smtpd and spamd are cranking at sustained bursts of up to 5 sim. hostile SMTP connects/sec getting trapped, fended off and the connecting hosts firewalled in near-realtime. Some observations, and mitigation techniques to not fall prey to a message designed to generate a flood/DoS against SA: - should keep short-time (15 min.) stats on DNS response time, especially for re-use within the same mail body - score (possibly intentionally) slow DNS responses for the URLs from servers against them, especially for subsequent lookups - possibly forgo subsequent lookups against the same DNS servers marked 'slow' for other URL hostnames. - control DNS lookups very specifically, and prevent automatic recursive lookups, but do 2-stage queries instead: root-nameservers and those governing entire TLDs are seldomly slow, while delegated DNS servers in spammer-hand might be ; we only want to query the latter once or twice, if they're slow. - come up with a gradient score dependent on number of URLs encountered for a given mail. - create rule to look up directly-delegated DNS servers (from TLDs) in DNSBLs as well. Those pesky Ralsky servers in .CN and .BR - forget about looking up ANY DNSBL-listings for ANY FQDNs of email addresses, period. There's too few pieces of spam around that do NOT have http:// URLs and only provide an email address as a sole point of contact. We are covering those special pieces of spam with the nigerian rules (which need some updating, hmm). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
