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.