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.
