again packet filter rules

The job of the firewall I agree is to keep unwanted traffic out of your local network, but thats not the main focus of the smtp proxy.

It is there to protect your internal server against attacks, filter spam (and viruses) etc, and having the proxy on the firewall does take a load from the internal box as it is doing spam filtering, DNSBL look-up's etc instead of the internal mail server.

Its true, that if you can achive the same setup with qmail/spamasssin/MailScanner etc but not in the same easy to manage way.

That aside, I understand your confusion, because i wanted to do a similar thing a while ago, and found that the proxy is not protected by the firewall packet filter rules. Perhaps the astaro team can comment as to why this is?

Lastly, your English isn't great, but its hundreds of times better than my German [:)]

One reason it's architected that way: by simply enabling proxies, all functionality needed by the proxy gets delivered. If the proxy's behavior was interrelated/dependent upon the rules being configured right, you would have an exponentially greater number of posts here.

Granted, if you were to architect it the other way, you could support more complex controls; but the design of the proxy should be focused on just its functionality, not iptables. Someday, maybe Astaro will take the trouble to add fields to the proxy's configuration page to accomplish this level of control; in the meantime, you can do it from CLI.

Another interesting thought would be to offer a choice at time of proxy configuration as to whether it sits behind the iptables. That's a whole new dimension of complexity to introduce under the hood, though. The proxy would need to sit in its own virtual DMZ running on the box, right? [If you were to confine the proxy to sit behind just one internal NIC, then you would lose the access control for that NIC's LAN; and that wouldn't be very intuitive -the proxy is on the box, not behind a NIC] So Astaro would have to synthesize network address spaces for each proxy they used. And all that might be a bit much for some people to get their heads around; it would be somewhat daunting for some to configure and troubleshoot.

I suspect Astaro chose to keep it simple, figuring that most proxy settings can deliver on the essentials of what you need, and the development time is better spent (at this point in time) improving the functionality of the proxies (and maybe adding even more proxies in the months and years to come? SIP?? UPNP??); although I for one would certainly welcome the introduction of such a virtual DMZ proxy architecture as an option to Astaro...