On Sun, Dec 08, 2024 at 09:36:05AM +0000, Sad Clouds wrote:
> On Sat, 7 Dec 2024 23:50:14 +1100
> Viktor Dukhovni via Postfix-users <postfix-users@postfix.org> wrote:
>
> > No role. Where are you going with this "all the internal details
> > please" perspective?
>
> Hello, in the near future, I will be managing my own Postfix SMTP and
> Dovecot IMAP servers. It really helps if I can visualize the overall
> architecture on a single diagram.
>
> I've updated my diagram based on your feedback:
>
> https://drive.google.com/file/d/1ucICaBmaZw7z9_tImg-g5fu8J5-Pthpm/view
>
> If anyone can think of corrections to it, then let me know.
>
The diagram does not do a good job of distinguishing between arrows that
represent delegation of message processing and those are just interactions
with specialised supporting services.
- It looks like smtpd(8) on port 25 only uses cleanup(8) via verify(8),
that's not the case. The communication with verify(8) is an exception
for recipient/sender verification, not the rule, and actual messages
are passed through cleanup.
- The trivial-rewrite service is also a (be it critical) supporting
service, its job is to nomalise email addresses and map them to
(address class, transport, nexthop, normalised recipient) tuples.
It is consulted by at least qmgr, smtpd and cleanup, but isn't
directly involved in message handling.
- The poscreen service isn't always behind TLS proxy, IIRC the network
socket is passed to tlsproxy if the client chooses STARTTLS, which is
a non-default behaviour, only if one enables deep protocol tests.
- The scache service is used at most by (when connection caching is
enabled) smtp(8) and lmtp(8),
- The qmgr(8) process should not be confused with the queue
directories. It reads and writes the queue directories, but
the purple box is not the qmgr process it is the collection
of queue directories.
- While postdrop(8) writes to the "maildrop" directory, it then
attempts to notify pickup(8) (if running) that there's new
mail there to handle.
- The "flush" service is only needed if you need to support
"fast flush" (ETRN) or really want support to flush mail to a relay
domain that's been down for some time. I don't find either
compelling, and set "fast_flush_domains" empty. This eliminates
a performance cost.
- You don't have "proxyread" which is handy to for LDAP, MySQL, Postgres
table lookups and even "unix:*.byname" when chrooted. But in high
volume systems such tables must not be used for the transport table,
because qmgr<->trivial-rewrite lookups are sequential and should have
very low latency.
- The local(8) delivery agent hands off non-local addresses that result
from alias expansion or for ":include:some-path" list handling, (and
IIRC also owner-alias envelope sender changes) back into the queue via
cleanup(8).
- The tlsmgr(8) process has separate caches for client TLS sessions
(still applicable) and server TLS sessions (obviated by session
tickets). Within these physical caches it can store multiple logical
caches by partitioning the key space in support of potentially
multiple instances of each of the smtpd(8), smtp(8) and lmtp(8)
services.
It also implements a small in-memory cache for TLS session ticket
encryption/decryption keys, which it initially generates.
It also handles priming the entropy pool, though that's somewhat less
important lately, with OpenSSL PRNGs increasingly relying on strong
entropy from the OS platform.
...
Perhaps that's all you really wanted to know. I do think that a few
more focused diagrams where the relanships are more apparent might in
fact be better than an all-in-one view.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
