Hi Wietse, On Wed, 06 Apr 2011 14:07 -0400, "Wietse Venema" <wie...@porcupine.org> wrote: > I find that Postfix documentation can always be improved. Despite > a lot of review there are still inaccuracies and omissions. ... > Indeed. The current documentation focuses on the basics: being > precise (no errors or omissions). It's like an illustrated > encyclopedia. This does not help people who don't know what they > are looking for, or what solutions may exist for a problem that > may not be well understood.
Well stated. My challenge is likely self-imposed. I'm trying to implement/deploy Postfix as a "(my) real-world solution" that's a replacement for very functional, though still limited and somewhat opaque, solutions such Zimbra & CommuniGate. For me it is NOT an issue of free vs not; rather one of fully capable & flexible ... or not. To your point, I *do* know what capabilities I'm looking for. Simply not in the context of Postfix, or more precisely, within the context of its documentation. Yet. > Unfortunately, it's not practical for me to maintain lots of > ready-to-run examples beyond the examples in the README files. Certainly understood. Although, as counterpoint, One might argue that you'd "waste" less time kindly talking to the likes of "me" :-) > All the steps to turn on/off postscreen are documented in > POSTSCREEN_README examples at the end of the document. If the > description of any step is incorrect, or if a step is missing, then > a concrete suggestion for improvement is welcome. Again, I can't/won't argue that any particulary step is incorrect or missing. As others have already undertaken to point out, the documentation is 'clear', fulfilling nicely your goal of accurate/precise, and that I should simply RTFM. Again. All I can comment on is I took the time to read as much as I could lay hands on, and still ended up adding "-o screen=yes" to the 'smtp ... postscreen' line in that instance's master.cf. Wrong? Yes, apparently. Precisely stated in the docs? Must be. Everyone says it is. What's left? My own misunderstanding. The best solution, imo? For me, and simply in my opinion, as stated and requested ... a good, single working example config. Will it be done here? No, and I ACK your argument why not. > When you configure TLS for receiving email, then you configure TLS > for smtpd as documented in TLS_README. > > These settings for smtpd become the default settings for postscreen > and tlsproxy, as documented in their respective manpages. Because > of these default settings, postscreen and tlsproxy will use 100% > identical TLS settings as smtpd. The idea is to make it easier > than having to configure each program separately to do the same > thing. Again, I'm completely off base in what I gleaned from my reading. My (mis)understanding was that, especially in a multi-instance setup, the TLS config for tlsproxy needed to be in the main.cf for the specific instance that used it. I understood *no* inheritance from the primary config in /etc/postfix to any other instance. > I suppose you can recommend some changes for the examples at the end > of POSTSCREEN_README. Can't recommend what I don't understand. And adding specific changes for specific changes to individual component does two thing wrong, imo, (1) it unnecessarily 'fattens' already well written docs (2) completely misses the opportunity to 'tie it all together' in a/any single, rich context. which is, after all, what I believe to be my current challenge. > I would not recommend burdening TLS_README with explicit configuration > examples for postscreen and tlsproxy, because there is no good > reason why those daemons should use TLS configuration that is > different. To my earlier point. Your "don't burden" ~ my "don't fatten". We're in 'violent agreement'. > Someone would have to invest a huge amount of time not only writing > up "complete" examples, but also keeping them up to date on Postfix > development. !examples. example. !them. it. just one. chosen using your expertise, experienc, and discretion. Imo, building on Viktor's MultiInstance example would be a great start. As for maintaining it, that's where a wiki serves nicely. One can certainly argue 'just create it and post something yourself'. Unfortunately, that's kind of like walking into a room of 10 people and asking "what should we do"? 10 people, 20 opinions. i'm simply proposing that those with "guru status" (you know who you are) plant the seed of a good start. > That is the biggest problem with all the Postfix howtos on the web. > They often have errors, and they almost always lag years of Postfix > development. agreed. even in my short-term, limited, experience, that much is clear. books are outdated, howtos are wrong, 'shrines' have vanished or crumbled, etc. which is why i'm attempting to learn 'here' and with the latest, up to date, docs. > More practical, Postfix documentation is unlikely to evolve beyond > the examples in the README files, simply because the cycles don't > exist to maintain a set that is accurate, complete, and that > is up to date on Postfix development. And I recognize that may well and necessarily be the final word. Thanks for you interest and comments. Now I have to actually attempt to find a solution that works! :-) DChil
