> /^209\.192\.46\.212$/ DUNNO > /virt.*domain\.com/ DUNNO > > And still getting blocked.
Well, is it the start and end of the HELO? How about without the anchors? If there is a leading or trailing space, the ^ and $ anchors will cause a failure to match. I hope you remembered to postfix reload when you modified the regexp. They are not has mapped, so the postfix program needs to be reloaded to detect regular expression changes immediately. Otherwise it takes a while. Did you try turning it in to a warn_if_reject to get a little more logged and look at that? You might also turn up the logging levels in the master.cf to get a huge, ugly volume of data, but then you can see exactly when the reject happens. Then you can back down the logging levels again and address that area. This is another postfix reload change. One other simple thing is to make all your header checks unique in the results. You have the following reasons for rejecting things: check_helo_access regexp:/etc/postfix/helo_hostnames.regexp, reject_invalid_hostname, reject_non_fqdn_hostname check_helo_access hash:/etc/postfix/helo_hostnames.map So in /etc/postfix/helo_hostnames.regexp, at the end of every reject message put helo_hostnames.regexp. For example: /localhost/ 550 Invalid host name. helo_hostnames.regexp Do the same sort of thing for /etc/postfix/helo_hostnames.map 127.0.0.1 550 Invalid host name. helo_hostnames.map Then you will see which file is rejecting. Also, if the reject_invalid_hostname, or reject_non_fqdn_hostname is the culprit, this will become more obvious. Without seeing the unmodified regexp file and log lines, it is hard to suggest more. But hopefully you now have enough to expose what is doing the reject, which can lead you to how to fix it. And now I am going home and won't be looking at things till Monday. --Eric
