Primary target audience:
- system developers
- advanced system administrators
- very advanced users

Target scale: personal program, one account.

This program is not meant to send emails to "queueing" smtp servers which
expect user authentication. This program does act as a "real" smtp server
sending emails to "real" smtp servers.

This is, yet another, _naive_ SYNChronous SendMail, for linux. Features are:
- No libc: direct linux "syscalls" for x86_64 and aarch64/arm64 hardware
architectures. ulinux, the ultra thin user level linux abstraction layer,
should support not too hard addition of new hardware architectures.
- No brain damaged build system (GNU autotools, meson, cmake, etc).
- Include a minimal dns resolver (expecting recursion support from the DNS
servers) with a resolver.conf file parser.
- IPv4 and IPv6 (only IPv4 was properly tested though).
- SMTP transparency handling (<CRLF>.<CRLF> to <CRLF>..<CRLF> without "sed").
If you want to handle it yourself, you can disable it in config.h.
- "One Compilation Unit". Actually 1 C src file and 1 assembly src file.

How to build:
Copy "config.default.h" wherever suits your build system/scripts and
rename it to "config.h". Customize it with what you must/want.
Use/copy&customize the make_* included scripts.
In theory, you could compile with:
"cc -I$config_h_dir -c all.c -o all_c.o"-ish
You could assemble with:
"cpp -DASSEMBLER -I$config_h_dir all.S | as -o all_S.o -"-ish
You could link with:
"ld -o syncsm all_c.o all_S.o"-ish

See the specifics for each hardware architecture in the provided make_*
scripts. At the time of writing, only aarch64/arm64 requires to be
provided the linux used hardware page size, because this value is
dependent on chosen options from linux compilation: we don't want to
dynamically discover this value using the linux auxv process vector.

It is based on a gcc/binutils toolchain, but the ground work to allow
adding new toolchains without insane kludge should be around (namely not
too hard-ish dependency on C inline assembly).

To deal with the log, egrep and "egrep -v" are your friends. The log
level-ish/severit-ish of a line is at its start.

'nothing/nobody is perfect'

--------------------------------------------------------------------------------

This project uses "One Compilation Unit":
It's possible to use the C preprocessor to perform local (part of a
compilation unit) namespace transformations. But those latests are
applied to _all_ identifiers: type names, struct member names, function
names, variable names, enum member names, then have limitations. The
main limitation is identifier collision. The idea is to work around them
locally (the preprocessor will warn you about collisions). Another
limitation is, since tranformations are using the C preprocessor,
special handling of macros. See GLOBAL_NAMESPACE_RULES.

This system has enough expressive power to grow projects to very large,
then is kind of overkill here since it's a rather poor project from a
namespace point of view. It is another method than the classic
compilation unit based partitioning of namespace.

All that to say: this code organization allows to grow "One Compilation
Unit" projects to very large and keep namespace in check for writting
code.

Resorting to "beyond sanity" complex computer languages in order to let
them perform global namespage management is a blunt mistake. In other
words, it is way more _un_reasonable than this very method.

Of course, a natural border of this model is the one between C files and
assembly files (and no, inline assembly is not a good answer, for many
reasons).

This code should support easy ipv4 support removal refurbishment and
simplification for a clean ipv6 only implementation.