|Main Archive Page > Month Archives > postfix-users archives|
> > On Tue, 05 Apr 2011 22:07 -0400, "Wietse Venema" <email@example.com>
> For more, see:
> If any text in there is not 100% clear, send suggestions for
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
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
With my luck, this already exists and I just haven't found it ... yet.
*** 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 ...