Hi Wietse > > On Tue, 05 Apr 2011 22:07 -0400, "Wietse Venema" <wie...@porcupine.org> > For more, see: > > http://www.postfix.org/POSTSCREEN_README.html > http://www.postfix.org/postscreen.8.html > > If any text in there is not 100% clear, send suggestions for > improvement.
Since you asked about clarity in documentation and suggestions ... I hope the following perspective will be of some help. It includes 'a suggestion for improvement'; just my $0.02. As a *new* Postfix user (retreating, or better, re-locating from Zimbra ...), I find the text of the online docs to be mostly thorough and exhaustive. I've of course read those docs & man pages, as well as relevant material from the two available, old books I've been able to find on Postfix, *before* posting my questions here. I have so much Postfix material printed out, I can't see the surface of my desk anymore ;-) I certainly do understand the typical response of simply providing links to existing docs, and suggesting to 'rtfm'. The presumption that materials have NOT been _read_, however, is not always a valid one. In some instances, although I'm reading and re-reading the docs, I'm not finding it an efficient process to get the info I need out. I'm finding I have to dig in a lot of different places to ferret out a single answer in the context of a 'real world' setup. And, I'm not being very successful at it. I'll shoulder my part of the bargain, and admit to lack of experience & understanding at this point. Two current examples. postscreen & stress support. I see in the postscreen docs that certain paramaters support stress parameters. To find out how to turn it on, I have to go to the stress docs, and find the "-o stress=yes" param, then surmise that it need to be added to the master.cf entry that contains postscreen, only in the postfix instance that invokes it, and not in the 'primary' config that's declared to be "more equal than others" ... In retrospect, or to the experienced user, the answer may be obvious. To me it wasn't. It could've been made much simpler, imo, without really changing the docs, but rather by having a commented set of config files from a single, working, 'complex' example -- where I could SEE what was done. as a 2nd example, TLS, which I'd mentioned in another message. again, I've found the docs & man pages, and read through them. I'm still not sure in how many places I'm supposed to add my key definitions, for example. Only in the postscreen containing postfix instance's main.cf? as "tls_" params for tlsproxy? Do I also need to add key defs in other instances' configs? And if so, as "tls_" params for tlsproxy or as "smtpd_" params? (this, e.g., "tlsproxy_tls_CAfile ($smtpd_tls_CAfile)" is not clear as usage from the docs ...). to have made this clearer, again, no change to the docs really required, rather that same "single, working, 'complex' example" would do ... Among the better examples I can reference of what, for me, has worked well in deploying a complex/dense product is 'Shorewall' documentation. That it's a different product, topic, application is acknowledged and of little relevance to my point ... If you take a look here: http://www.shorewall.net/Documentation_Index.html, you'll note an extensive list of 'use case' articles, tutorials, and documentation. In addition to its similarly exhaustive documentation on parameters and usage, I find these to be invaluable in actually getting a complex conifg up and running. I'm not suggesting getting to that point in one giant leap, and to attempt to cover all scenarios. rather, as a first step, pick/define _one_ more-or-less complex setup ***, using the tools-&-toys modern/latest postfix provides, and provide a known working set of configs for it. It would provide single, consistent context within which to understand and apply the individually well-documented componenets. With my luck, this already exists and I just haven't found it ... yet. HTH! DChil *** e.g., multiple instance, across multiple servers, listening at multiple IPs, servicing multiple domains, using TLS, stress management, etc. yes, i recognize it's challenging and requires effort to put something like that together. that's the point ...
