To postfix in particular i dont know, but a have ITIL and COBIT books for generic enviroments IT.
2016-09-29 2:32 GMT-03:00 Bill Cole < postfixlists-070...@billmail.scconsult.com>: > On 28 Sep 2016, at 10:58, Stephen Satchell wrote: > > For PostFix in particular? >> For mail servers in general? >> > > Nothing definitive, comprehensive, and usefully detailed because the world > at large cannot tell you who you are. RFC5321 covers the technical details > of SMTP well, but there are behaviors that it recommends which are widely > unsupported and others it strongly discourages which are widely practiced. > > Postfix is an extremely versatile tool. The specific tasks one applies > that tool to varies widely and what results are desired does as well. > Consider that there is over a megabyte of text in the Postfix README text > files, over a megabyte of man page content in 177 files, and 'man 5 > postconf' alone puts out over 650KB of text. There are 877 top-level > configuration items in the default Postfix configuration and it is common > for admins to have a use for adding a handful to scores of custom config > items like restriction classes and per-instance settings, particularly in > complex environments. A typical *simple* site is likely to change scores of > those 877 to meet local needs. Watch this list for a week or two and you > will see experienced professional mail admins recommending starkly > different configurations to neophytes, with none of them being objectively > wrong. If you factor out all of the matters of opinion and all of the > variables that differ between sites, you get a very short and basically > useless set of best practices: > > 1. Deliver all legitimate email to the right places. > 2. Do not deliver spam or any other species of email which is intended or > likely to harm recipients. > 3. Minimize delays. > 4. Minimize resource demands. This includes bandwidth, hardware, AND > wetware (that's actual humans, which are costly to operate and maintain). > 5. Minimize dependence on the resources and services of others, > particularly those with no contractual obligation to perform for you. See > Brian Krebs' recent Akamai experience for a demo of this issue in the area > of web DDoS mitigation. Note that neither Brian nor Akamai did anything > wrong. > 6. Minimize the ability of legitimate email to vanish silently while > simultaneously minimizing the ability of illegitimate email to generate > backscatter originating on your systems. > 7. Maximize the happiness of your users and email service peers with your > handling of email. > 8. Follow technical standards such as RFC5321 and RFC5322 as closely as > you can while prioritizing items 1-7. > 9. Balance the fulfillment of items 1-8 with the realities of technical > and personnel availabilities and costs to optimize the sustainability of > your mail system. > 10. Don't screw around with your users' email content. Deliver or reject, > quarantine or "spam folder" if they insist, but leave what's inside alone > as much as is possible. It's OK if you can't do total binary transparency > and so need to re-encode, but don't go whacking MIME parts you deem > dangerous while delivering the rest or encapsulating/defanging dangerous > messages but delivering them anyway. > > How do you do all those things? Well, that depends on many variables... > Who are you? *You* have to answer that. The answer has to include who your > users are and how they can be made happy. Hence, it also has to include who > they want to exchange email with and who they will tolerate being unable to > exchange email with seamlessly. > -- Atenciosamente, Rodrigo da Silva Cunha
