-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dylan Bouterse Sent: Wednesday, May 09, 2007 7:43 PM To: [email protected] Subject: Re: [AMaViS-user] processing times
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary V Sent: Wednesday, May 09, 2007 4:51 PM To: [email protected] Subject: Re: [AMaViS-user] processing times Dylan wrote: > SA check: 223 (43%) > SA check: 5748 (95%) OK, so you know it's spamassassin network tests. Grab a test message and feed it to spamassassin in debug mode and pipe it through a perl function that Mark mentions: su amavis -c 'spamassassin -D < email.txt 2>&1' | timestamp where timestamp is a function in my .bashrc : function timestamp() { perl -MPOSIX -MTime::HiRes -n -e ' BEGIN {$|=1; $dp=0; $t0=Time::HiRes::time}; $t=Time::HiRes::time; $dt=$t-$t0; printf("%s%06.3f %4.3f %4.3f %s", POSIX::strftime("%H:%M:",localtime($t)), $t-int($t/60)*60, $dt, $dt-$dp, $_); $dp=$dt' $* } Or pipe it directly to the one liner: su amavis -c 'spamassassin -D < email.txt 2>&1' | perl -MPOSIX .... and look for the network tests. you can send output to a file (send to your amavis home directory) by tacking on something like this to the end of the statement: >/var/amavis/0.log 2>&1 & I noticed in mine: 14:43:17.936 3.994 0.000 [31178] dbg: uridnsbl: queries completed: 1 started: 0 14:43:17.936 3.994 0.000 [31178] dbg: uridnsbl: queries active: at Wed May 9 14:43:17 2007 14:43:21.357 7.415 3.421 [31178] dbg: dns: success for 8 of 9 queries 14:43:21.357 7.415 0.000 [31178] dbg: dns: timeout for bsp-firsttrusted after 6 seconds See the big delay? And I ran out of time. One thing that can make a difference is how responsive your DNS server is. Typically a local caching DNS server is recommended. Really I'm not surprised net tests take 5 seconds. What is more strange is how you get your other server to perform network tests in 1 second. Gary V Furthermore, if I pull down my ACL and do the following: [EMAIL PROTECTED] Mail-SpamAssassin-3.1.7]# pyzor ping 82.94.255.100:24441 (200, 'OK') Wala! Now I need to figure out what ports are not getting back in. If anybody has had any issues with this and can help, it would be greatly appreciated. Otherwise, may have to pull the sniffer out. Dylan Ok, I've managed to walk myself through this. I found some documentation (http://wiki.apache.org/spamassassin/NetTestFirewallIssues) that suggest Pyzor sends UDP to the server and expects a TCP response. I've found this to be quite the opposite. I opened up my ACL to allow all TCP traffic from the 82.94.255.100 server back into my filter and I got a timeout. I tried allowing only UDP on port 24441 from the 82.94.255.100 server and I got a timeout. Only when I allow all UDP from 82.94.255.100 do I finally get success! So, the solution if the firewall is preventing the Pyzor check is to allow incoming UDP from the Pyzor server you are using for your checks. If I wanted to spend more time maybe I could narrow down what range of UDP ports it's using but I don't mind allowing all UDP from one host. Hopefully this will come in handy for somebody down the line. Thanks for all the help getting to this point guys! Dylan ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
