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