I'm working on adding some postfix configuration to the installer/updater, and come across all the OS specific install/dist/lib/*.php files, and wanted to clarify what all needs updated for proper/full ispconfig support? Eg. I added some code to configure_postfix() in install/lib/installer_base.lib.php in a recent commit, and that's tested on a debian system. But I see a configure_postfix() in three distribution specific files here: Code: $ grep configure_postfix install/dist/lib/* install/dist/lib/fedora.lib.php: function configure_postfix($options = '') install/dist/lib/gentoo.lib.php: public function configure_postfix($options = '') install/dist/lib/opensuse.lib.php: function configure_postfix($options = '') Should I just put the same code changes in those three files, even though I can't test them (don't have any of those distributions installed)? Each of those three is about half the size of installer_base.lib.php, so I'm guessing they are simply not maintained as much (so maybe I don't need to worry about them, too?). Thanks...
Yes, theses classes are used on speciefed OS. If you want new features on opensuse too, you must also change opensuse.lib.php. I don´t think that you must test this with opensuses or any other OS. Just make sure, that other OS are shipped with postfix-version that supports your changes. It´s not enough to change lib/installerbase - all classes in dist/lib must be chancge. At least Debian Wheezy uses dist/lib/debian60
Ok, I'll copy my changes to those other three files too. debian60.lib.php doesn't override configure_postfix() from the base class so that one will be fine for the immediate changes I'm making; I'll just need to keep in mind to search dist/lib/* for the name of any changed functions in the future, too. Thanks...
I`m pretty sure that debian60.lib.php could be removed. I did not see any difference against the base-lib. But you should not change any defaults from postfix.
That seems a bit of an odd statement, as postfix has nearly 1000 config settings and ships in a "lowest common denominator" type setup, it's clearly intended to be configured (ispconfig itself has a fair bit of code specifically to do that) - what are the concerns that are coming to mind for you? Simply not to change anything that would introduce problems/user complaints in existing systems when they upgrade? Are some of the changes I made specifically are of concern? Surely some things shouldn't be done by default. Eg. I hope to add a good postscreen configuration to the setup, and plan to have that disabled by default, with a few configuration settings available in the gui once enabled. But postscreen can bite users who still might submit messages on port 25, so that seems like a safer option, even though it will likely affect relatively few servers (people running a new enough version of postfix to support postscreen, and keep ispconfig updated, but haven't switched to sasl/port 587). Many things are applicable to nearly every ispconfig server, and it seems like the more of that configuration that is done automatically, the better. Not one size fits all, but a very complete out-of-the-box config, with the necessary handles to change/override things when required. Eg. rate limiting of messages; servers will vary (sometimes a lot) in what is an appropriate limit, but nearly everyone "needs" that feature (also something I'd like to get added to the installer). Judging by changes/features contributed to another panel I've worked with (DTC), these types of things are well received and appreciated by panel users; and not just novice admins, but also experienced admins appreciate having a smaller todo list when setting up a server.
Postfix is one of the most used MTA and the defaults are working on every server. The typical server running ISPConfig is a simple server with web, mail and maybe DNS. I removed postscreen a while ago since i won´t force every client to send mail over the submission-port. Using rbl-lists on port 25 is ok for me. If a client is authenticated, the rbl-list is ignored. AFAIK this is not possible with postscreen. Before we adding new paramaters to the installer/interface, think about how many users will really need this. If you need a configuration that differs from the default, i prefer to use a conf-custome template.
If you have the ip addrs, you can add an ip addr (or two) to each mail server just for postscreen, and set your mx records to deliver there rather than the current name/addr that customers are using. Other than that, I think you're right that there's not a way to get bypass checks for authenticated clients, as postscreen isn't intended for client submission. On the rbl note, postscreen allows you to weight the lists, so you can require more than one rbl hit before blocking, and mix in whitelist scores, which can help when some rbl's are mostly useful but do tend to list things a little too aggressively. Examples in https://www.mail-archive.com/[email protected]/msg90763.html and http://www.mail-archive.com/[email protected]/msg95078.html
I`m not talking about my servers (or maybe yours). I installed ispconfig on a lot of servers and most of them have one ip. No dedicated setup, no vservers. Just one plain server with one ipv4.
Right, for the (common) single addr case, clients must use submission port if you want to utilize postscreen; appropriate info/warning should be on the postscreen settings page so people realize that choice when they enable it. For those with extra IP addrs, you could setup postscreen (and MX record) on a new ip address, so clients can continue to use port 25 on the old addr/name. postscreen also supports the idea of a "backup MX address" which will never accept mail delivery, but draws the connections of some spammers who bypass the primary MX address. I'm pretty sure at this point I won't get to a postscreen ui/integration before 3.1, but do plan on running it without the ui, and hopefully can work out the ui/settings/help info that will be needed to make it point-and-click usable for everyone in time. For the most part, no, there's a lot of overlap in functionality, with pro's and con's to each. I think there can be a place for greylisting based upon certain criteria, to help stop some of the spam runs that haven't made it to common rbl's yet, but it's not great for blindly running all mail through (especially if you also have postscreen). Eg. see https://www.mail-archive.com/[email protected]/msg93735.html though admittedly, I don't have such a setup working in practice; we've simply disabled greylisting everywhere postscreen is running, and in the few places it's not, we field the occasional support call for issues caused by greylisting affecting legitimate mail.
