On Apr 1, 2010, at 4:05 PM, Victor Duchovni wrote: > Were you asking about using Postfix as a proxy in front of internal SMTP > servers, or using firewall reverse-proxy SMTP support to sit in front of > Postfix?
I was asking about Postfix running as a daemon on the firewall computer that handles routing and inspecting traffic between the WAN, the DMZ, and the LAN. This Postfix would intercept and inspect incoming SMTP connections (and drop some) before passing valid ones on to the real Postfix MTA running on a computer in the DMZ. A 3-hole PIX running Postfix, in other words. > The latter is definitely a very bad idea. Why? I can see how it'd be a duplication of effort, but I don't see how it would hurt. > The former is sometimes > appropriate, but fairly unusual, letting Postfix operate normally with > a store and forward queue is much more typical and usually the right choice. I know it's much more typical; I'd never heard of putting proxies on the firewall before (I'd never thought of the PIX stuff as a proxy, just a little content filtering (that was always getting me in trouble)). But popularity in itself doesn't make it the best way to do things. The argument is that a packet filter is easily made 'default deny' but a lot of cruft gets through because the packet headers may be OK, while the content is evil. An IDS/IPS is not effective because it's 'default allow' and is always chasing the latest exploit pattern. A reverse proxy, though, is an application level 'default deny'. Therefore, reverse proxy filtering can block content-based attacks that haven't been seen yet. (I know there's a lot more to Snort's rules than just the latest patterns, and that it's 'default allow' because that's the way the default ruleset is configured. I'm just repeating some of what they said, and I'm attracted to parts of the proxy argument.) -- Glenn English g...@slsware.com
