README

   1 Primary target audience:
   2  - system developers
   3  - advanced system administrators
   4  - very advanced users
   5
   6 Target scale: personal program, one account.
   7
   8 This program is not meant to send emails to "queueing" smtp servers which
   9 expect user authentication. This program does act as a "real" smtp server
  10 sending emails to "real" smtp servers.
  11
  12 This is, yet another, _naive_ SYNChronous SendMail, for linux. Features are:
  13  - No libc: direct linux "syscalls" for x86_64 and aarch64/arm64 hardware
  14    architectures. ulinux, the ultra thin user level linux abstraction layer,
  15    should support not too hard addition of new hardware architectures.
  16  - No brain damaged build system (GNU autotools, meson, cmake, etc).
  17  - Include a minimal dns resolver (expecting recursion support from the DNS
  18    servers) with a resolver.conf file parser.
  19  - IPv4 and IPv6 (only IPv4 was properly tested though).
  20  - SMTP transparency handling (<CRLF>.<CRLF> to <CRLF>..<CRLF> without "sed").
  21    If you want to handle it yourself, you can disable it in config.h.
  22  - "One Compilation Unit". Actually 1 C src file and 1 assembly src file.
  23
  24 How to build:
  25         Copy "config.default.h" wherever suits your build system/scripts and
  26         rename it to "config.h". Customize it with what you must/want.
  27         Use/copy&customize the make_* included scripts.
  28         In theory, you could compile with:
  29                 "cc -I$config_h_dir -c all.c -o all_c.o"-ish
  30         You could assemble with:
  31                 "cpp -DASSEMBLER -I$config_h_dir all.S | as -o all_S.o -"-ish
  32         You could link with:
  33                 "ld -o syncsm all_c.o all_S.o"-ish
  34
  35         See the specifics for each hardware architecture in the provided make_*
  36         scripts. At the time of writing, only aarch64/arm64 requires to be
  37         provided the linux used hardware page size, because this value is
  38         dependent on chosen options from linux compilation: we don't want to
  39         dynamically discover this value using the linux auxv process vector.
  40
  41         It is based on a gcc/binutils toolchain, but the ground work to allow
  42         adding new toolchains without insane kludge should be around (namely not
  43         too hard-ish dependency on C inline assembly).
  44
  45 To deal with the log, egrep and "egrep -v" are your friends. The log
  46 level-ish/severit-ish of a line is at its start.
  47
  48         'nothing/nobody is perfect'
  49
  50 --------------------------------------------------------------------------------
  51
  52 This project uses "One Compilation Unit":
  53         It's possible to use the C preprocessor to perform local (part of a
  54         compilation unit) namespace transformations. But those latests are
  55         applied to _all_ identifiers: type names, struct member names, function
  56         names, variable names, enum member names, then have limitations. The
  57         main limitation is identifier collision. The idea is to work around them
  58         locally (the preprocessor will warn you about collisions). Another
  59         limitation is, since tranformations are using the C preprocessor,
  60         special handling of macros. See GLOBAL_NAMESPACE_RULES.
  61
  62         This system has enough expressive power to grow projects to very large,
  63         then is kind of overkill here since it's a rather poor project from a
  64         namespace point of view. It is another method than the classic
  65         compilation unit based partitioning of namespace.
  66
  67         All that to say: this code organization allows to grow "One Compilation
  68         Unit" projects to very large and keep namespace in check for writting
  69         code.
  70
  71         Resorting to "beyond sanity" complex computer languages in order to let
  72         them perform global namespage management is a blunt mistake. In other
  73         words, it is way more _un_reasonable than this very method.
  74
  75         Of course, a natural border of this model is the one between C files and
  76         assembly files (and no, inline assembly is not a good answer, for many
  77         reasons).
  78
  79 This code should support easy ipv4 support removal refurbishment and
  80 simplification for a clean ipv6 only implementation.