Before you start ... think!

Running an email system on your Unix systems requires some thinking and preparation to avoid basic failures.

• What are your Use Cases/expectations?
• Do you have a good understanding of your Unix system apart from installing packages?
• Do you have some knowledge about the SMTP (Simple Mail Transport Protocol) its benefits and its shortcomings?
• Do you have 'customers' (and by that I include family members) depending on your service?
• Are you a system administrator/mail administrator in charge of a group of people depending on (uncomprimised) mail transfer and reliability?
• Do you serve with your mail system (MTA: Mail Transfer Agent) users depending on Microsoft products and in particular Outlook?

Please try to evaluate the questions and perhaps paint the scope of your requirements. I suggest to use a mind map.

The Use Cases

Essentially, you can install s/qmail successfully under all given circumstances:

1. You are courius and you simple want to see, you it runs and potentially benchmark with other MTA. Your are welcome!
2. You aim to use s/qmail for a smaller setup perhaps including a dozend users (or mailboxes). Carry on. But live could be more comfortable with Exim or Postfix because in general they are better integrated into your Unix OS by packages, and maintained by that way.
3. You are a mail admin setting up s/qmail because you are knowledgeable about qmail and you are looking for a refresh? Glad to meet you!
4. You are looking for a solution, where you can fine tune all filters to process emails and in particular understand those? That is the place to be!
5. You are a novice mail admin and 'minimalist' looking for an appropriate solution? Please go ahead. There is plenty to learn.

Based on qmail raised by Daniel J. Bernstein, s/qmail is a MTA following minimalistic principles: The less code, the better. Unlike qmail however, s/qmail includes much more features and is thus more complex. Complexity is the enemy of security, but I hope to provide a good balance to make s/qmail immune against attacks, provide a solid mail transfer agent, and also protecting the users from Internet harm coming through emails.

The Requirements

No good medicine without impact. Here are some of those:

• You need to have some solid understanding of Unix, your particular Unix flavor (Linux distribution ...) the command line (CLI) and willing to put hands on (perhaps) difficult files to straighten.
• Technically, your Unix needs to have a working compiler and the make utility.
• Since encryption is required, access to the OpenSSL/LibreSSL libraries and their header files is a must. On some Linux systems, you need to install libssl-dev.
• SMTP email relies on DNS (Domain Name System). The big providers demand some particular DNS settings, you must comply to (MX, SPF, DKIM, PTR). Thus, you need access to those settings, even if your DNS provider is not willing to provide those easily.
• Be prepared to read and understand the log information written and consult 'man pages'. In essence, digest the information from the source and not via a Google search (which may point towards a wrong direction).

Always consult (in this order):

1. The README file.
2. The CHANGELOG file.
3. The INSTALL file.
4. The on-line documention.
5. The man page of the program causing the trouble.
6. Inscribe to and consult the s/qmail mailing list.

Errors, Bugs, and all unwanted things

Unlike DJB, I don't claim that s/qmail is perfect. If you see a strange behaviour, consult the above steps - and in particular - the man pages. Try to determine the problem and describe it in a minimal working example (MWE). Attach the output of qmail-showctl and log output showing the problem, while perhaps masking user names and IP addresses.

Once you are conviced the problem can't be solved by yourself, consult (for general issues) the s/qmail mailing list. In case of security breaks or other important issues, send an email to: feh@fehcom.de. I'll accept PGP encrypted mails.