Patrick Fay put forth on 8/26/2010 10:21 PM:
Hi, I am running dovecot 1.2.11 on mac osx 1.5.8. Everything works perfectly with the application-level firewall off, but enabling the application firewall prevents dovecot connections. I have tried explicitly authorizing dovecot in the firewall, but it does not work. I have searched everywhere I can think of to look, and haven't found a solution, but have seen a couple other reports of what seems to be the same problem. The firewall logs the activity with what looks like a corrupt process name: a typical appfirewall.log entry looks like:
Aug 26 20:43:45 hostname Firewall[55]: Deny ^L connecting from XX.XX.XX.XX:37310 uid = 0 proto=6 Aug 26 20:43:53 hostname Firewall[55]: Deny ^H�^U���^Z connecting from XX.XX.XX.XX:37310 uid = 0 proto=6 Aug 26 20:44:09 hostname Firewall[55]: Deny ^L connecting from XX.XX.XX.XX:37310 uid = 0 proto=6 Aug 26 20:44:34 hostname Firewall[55]: Deny ^L connecting from XX.XX.XX.XX:37312 uid = 0 proto=6 Aug 26 20:44:45: --- last message repeated 6 times ---
where "hostname" is my server name and the XX's are my client's IP address. For all of the other services I've used, the process name (e.g. dovecot) should appear after "Deny" when blocking traffic, instead of the funny characters. Any advice on how I could resolve this issue would be greatly appreciated. Thanks!
The application level firewall in OSX is aimed at _client_ use, not server use. It's similar to Novell's AppArmor, etc. Leave it turned off.
Simply because a piece of software (in this case an OS) offers any given option does not mean every system needs it. Can you offer a compelling reason why you _need_ the OSX application level firewall enabled? Please point us to documentation that advises using it for any of your services/daemons.
-- Stan