Hello everyone! Exchange 2003 SP2 on a SBS 2003 SP2. The first entry of Connection Filtering on Message Delivery Properties is ignored, no matter what it is. The others works without issues. Has anyone ever seen something like this? Any possible solution? Thanks!

Hi, Do you mean the first rule will be ignored and do not take effect? How about moving the rule down. If it works, I think you can workaround this issue by creating a test rule and move it to the top. Thanks, Simon

Hello Simon_Wu, Actually I was already doing that, but this issue is unexplained. The GFI antispam solution could be the cause, filtering at SMTP level for 'Directory Harvesting'. Disabled this feature, waiting for results... I'll keep this topic updated. Thanks!

Hello Simon_Wu, Actually I was already doing that, but this issue is unexplained. The GFI antispam solution could be the cause, filtering at SMTP level for 'Directory Harvesting'. Disabled this feature, waiting for results... I'll keep this topic updated. Thanks!

Still no solution on this, and even when the RBL is the second on the list Message Filtering misses it and later the GFI AntiSpam catches, using the exact same RBL, bl.spamcop.net. I'll keep trying any other solution, even updating the antispam. Could I trace what exactly Message Filtering does? how activate a detailed log of it or what third part tool could be used? Would be great to see what connections are denied...

Hi Clinger, Do you mean that all the rules you created to use the RBL "bl.spamcop.net" are not working now? Are the other rules working on your server? Is there any other tranport agent or applications running before your Exchange server? Are the GFI AntiSpam and Exchange 2003 running on the server? And did the GIF AntiSpam use the same RBL? Maybe you should check if the name "bl.spamcop.net" is resolvable on your Exchange server or if the DNS queries are slow. If the Exchange server is trying to query the RBL but not receiving a response at all or within the timeout period (probably a few seconds), it would accept the messages. On Exchange 2003, the best log we could use to check/trace the connection filtering is the SMTP logging, you could follow the steps below to enable this logging: 1) Open ESM, expand <Administrative Groups>--<Server>--<Your Server>--<Protocols>--<SMTP>--<default smtp virtual server> 2) Right-click the default smtp virtual server, press "properties" 3) On the "general" tap, click to enable "enable logging", format select "W3C Extended log File Format" 4) Press Properties button, recorder the "log file directory" and "logfile name" 5) Click "advanced" tap, select all logging options By default, the logs are put in "c:\windows\system32\logfiles\smtpsvc1\" And we could follow this article to check and make sure that rule has been created correctly. How to configure connection filtering to use Realtime Block Lists (RBLs) and how to configure recipient filtering in Exchange 2003 http://support.microsoft.com/kb/823866 Thanks, Andy

Hi Chao Lu and thanks for the reply, I'm using some RBLs on Exchange Message Filtering and the same ones at GFI MailEssentials, just the Spamcop RBL seems to fail but now I'm not so sure of that. This happened before with zen.spamhaus.org. Maybe the log of DNSBL from GFI is pointing to the wrong RBL, since a nslookup 2.0.0.127.bl.spamcop.net at this server gives the expected 'Name: 2.0.0.127.bl.spamcop.net' as reply. There are no other transport agents or applications running before this Exchange Server. I have enabled SMTP logging and I'll look for more detailed info. Edit: I've found that the full log has incomplete info: 2012-09-06 16:35:03 x.x.x.x externaldomain.com SMTPSVC1 MYSERVER x.x.x.x 0 RCPT - +to:user@mydomain.com 550 0 0 41 5766 SMTP - - - - (where's the RBL name?) This was the last line from telnet session started at my pc, a dynamic IP. On my telnet session I had the expected full response: blocked by zen.spamhaus.org. So, what could be done to have the exact SMTP level session logged?

Hi Clinger, Thank you for your reply. From your reply we could know that only the Spamcop RBL does not work on your server. Here I would like to confirm if the Spamcop RBL worked on your server before? To make sure that the DNS server has been set correctly to use the RBL, we suggest you to try the following steps on your Exchange server and see if you could get the correct result with your DNS server: Open command prompt Type "nslookup" Type "set q=txt" Type "set timeout=10" Type "2.0.0.127.bl.spamcop.net " (the real ip address in this case is 127.0.0.2) If you get: "Blocked - see http://www.spamcop.net/bl.shtml?127.0.0.2" then the DNS server is configured correctly. "Non-existent domain" then the ip address is not in the DNSBL list. DNS request timed out then the DNS server is not configured correctly And about the SMTP log, you are selecting the highest logging level now and as the message was not blocked by the connection filtering, no block response would be generated so we would not see the block record or RBL in the SMTP log now. Thanks, Andy

Hello Chao Lu! System was already giving the expected results from DNS requests. Issue was solved by updating the GFI MailEssentials with a newer build; GFI support doesn't pointed that the specific version that I was using could cause problems. So, the problem was, possibly: Some conflict between the antispam and ExchangeGFI MailEssentials reporting wrong DNSBL on logs About the SMTP log: connections being blocked by the Exchange Connection Filtering are reported as '...550...' but the log doesn't contain what specific DNSBL was responsible for the blocking: 2012-09-06 16:35:03 x.x.x.x externaldomain.com SMTPSVC1 MYSERVER x.x.x.x 0 RCPT - +to:user@mydomain.com 550 0 0 41 5766 SMTP - - - - (Where's the DNSBL name?) A simple query using the e-mail server's IP on a web service such as MXToolbox.com blacklists reveals the responsible DNSBL, but this information could appear in the logs. A external telnet from a dynamic IP to Exchange SMTP gives the expected detail level: 550 5.7.1 x.x.x.x has been blocked by zen.spamhaus.org Thank you!