28. pepsi-ingress

Le serveur SMTP entrant (MTA) et le point d’entrée du pipeline.

28.1. Rôle

pepsi-ingress exécute le serveur SMTP qui reçoit le courrier, l’authentifie à la limite, et stocke chaque message accepté comme une ligne pepsi.workqueue à stage = init avant de notifier le dispatcher. C’est le seul composant qui parle aux clients émetteurs externes ; tout ce qui est en aval opère sur la ligne stockée. La référence exhaustive des options est pepsi-ingress(1) / pepsi.conf(5).

28.2. Fonctionnalités

28.2.1. Réception (RFC 5321)

  • Serveur SMTP/ESMTP avec transport par listener : en clair, mise à niveau STARTTLS (RFC 3207) et TLS implicite (RFC 8314) ; les listeners lient des sockets TCP, UNIX ou activées par systemd.

  • Corps de message via DATA ou CHUNKING/BDAT (RFC 3030).

  • Annonce SIZE (appliquant MAX_MESSAGE_SIZE → 552), PIPELINING, ENHANCEDSTATUSCODES, 8BITMIME (RFC 6152), SMTPUTF8 (RFC 6531) et DSN (RFC 3461).

  • N’accepte le courrier que pour ACCEPTED_DOMAINS (les autres → 550 relayage) ; accepte toujours le <Postmaster> sans domaine (RFC 5321 §4.5.1).

  • Acceptation durable : renvoie 250 seulement après la validation de la ligne ; une panne de base de données donne un 451 transitoire.

  • Concurrence de connexions bornée par MAX_CONNECTIONS et un budget de descripteurs de fichiers MAX_OPEN_SOCKETS ; la limitation de débit par source (CONN_RATE_PER_SECOND) et, sous pression, l’éviction de la connexion la plus longtemps inactive dans la plage source la plus gourmande, protègent contre l’abus de connexions.

  • Des timeouts de lecture par commande (COMMAND_TIMEOUT/DATA_TIMEOUT, RFC 5321 §4.5.3.2) ferment les sessions lentes ou calées, y compris une poignée de main STARTTLS bloquée.

  • Longueurs de ligne indulgentes. Les limites de la RFC 5321 §4.5.3.1.4/§4.5.3.1.6 (lignes de commande de 512 octets, lignes de texte de 1000 octets) lient les expéditeurs ; conformément à la recommandation de la même section que les récepteurs soient libéraux, l’ingress accepte des lignes plus longues. Les plafonds internes MAX_CMD_LINE/MAX_DATA_LINE ne sont que des garde-fous contre l’épuisement mémoire — une ligne sans terminateur qui dépasse le plafond ferme la connexion — pas une application de conformité.

28.2.2. En-tête de trace

  • Ajoute en tête un en-tête Received: RFC 5321 §4.4 avant l’authentification (de sorte que le sceau ARC le couvre), notant le client (HELO/EHLO, DNS inverse, IP), ce serveur, le type de transmission SMTP/ESMTP/ESMTPS/ESMTPA/ ESMTPSA (RFC 3848) et l’heure ; une clause for est ajoutée pour les transactions à destinataire unique. Pour une session chiffrée, la version TLS et la suite de chiffrement négociées sont ajoutées sous forme d’un commentaire (version=… cipher=…) après le mot-clé ESMTPS (RFC 8314 §4.3).

28.2.3. Authentification (notée à la limite)

  • SPF (RFC 7208), vérification DKIM (RFC 6376 / RFC 8463) et DMARC (RFC 7489), plus iprev/FCrDNS (RFC 8601).

  • Ajoute en tête un en-tête Authentication-Results (RFC 8601) avec le HOSTNAME de l’ingress comme authserv-id ; les verdicts sont aussi stockés sous state.auth (spf/dkim/dmarc/arc).

  • Fail-open : seul un échec DMARC certain sous DMARC_ENFORCE rejette (550) ; les erreurs DNS/d’analyse sont notées et le courrier accepté.

  • La vérification/le scellement ARC n’est pas effectué ici — c’est l’étape pepsi-stage-arc, de sorte que l’ingress ne détient aucune clé ARC. L’ingress note le contexte de session dont l’étape ARC a besoin sous state.origin.

28.2.4. Soumission (RFC 6409)

  • Un listener avec SUBMISSION = yes rend l’authentification du client obligatoire et applique les corrections de soumission (un Date:/Message-ID: manquant est ajouté). L’un quelconque de quatre mécanismes authentifie une session : une adresse de pair dans MYNETWORKS, les identifiants de pair d’une socket UNIX (AUTH_PEERCRED, la valeur par défaut sur un listener UNIX et refusée sur TCP), un échange SASL AUTH (SASL_TYPE = dovecot, proposé uniquement sur TLS) ou un certificat client TLS épinglé (TLS_AUTH_CLIENT). Une session authentifiée est notée avec state.local_origin = true ; USERNAME_MAP décide des adresses au nom desquelles l’identité authentifiée peut émettre.

  • La soumission exige un MODE protégé par TLS, sauf sur une socket locale du domaine UNIX, où le noyau fournit l’identité et où il n’y a aucun transport à protéger.

  • La socket de soumission locale qu’utilise pepsi-sendmail n’a besoin d’aucune section de listener : ingress en synthétise une pour [pepsi-sendmail] SOCKET à moins qu’une section explicite ne serve déjà ce chemin. SOCKET = none est le seul interrupteur qui la désactive ; ne pas parvenir à la lier est fatal.

28.2.5. Quota de boîte aux lettres

  • Lorsqu’une politique de quota de boîte aux lettres est en vigueur, un destinataire dont l’usage mesuré dépasse sa limite est refusé au RCPT (452 4.2.2 ou 552 5.2.2, selon [pepsi] MAILBOX_OVER_QUOTA). Ingress ne fait jamais que lire pepsi.mailbox_quota, et ne refuse que sur une mesure plus jeune que MAILBOX_QUOTA_MAX_AGE ; toute incertitude (aucune ligne, une mesure périmée ou absente, une erreur de base de données) accepte. MAILBOX_QUOTA_RCPT_CHECK = no (par défaut yes) reporte toute l’application au moment de la remise. Voir pepsi-quota.

28.2.6. Réception DSN (RFC 3461)

  • Valide et stocke RET/ENVID (MAIL FROM) et NOTIFY/ORCPT (RCPT TO) sous state.dsn ; les valeurs malformées sont rejetées 501.

28.2.7. Réception internationalisée / 8 bits

  • Accepte les corps 8 bits bruts et les en-têtes/enveloppe UTF-8 ; note la déclaration BODY= sous state.origin.body_8bit. BINARYMIME est rejeté (501). La ré-annonce/rétrogradation par saut a lieu plus tard dans les étapes de relais.

28.2.8. Décodage inverse SRS

  • Un destinataire dans SRS_DOMAIN dont la partie locale est un jeton SRS valide est décodé en l’expéditeur original et accepté pour relais vers celui-ci (même en dehors des domaines servis — le HMAC l’autorise) ; un jeton falsifié/expiré est rejeté (550). C’est ainsi que les rebonds reviennent aux expéditeurs originaux. Voir pepsi-stage-srs.

28.2.9. Stockage et notification

  • Stocke le message scindé en colonnes headers et body, avec l’enveloppe, les From:/Subject: analysés et les verdicts ; insère à stage = init / status = pending.

  • Réveille le dispatcher hors bande et de façon coalescée, au plus une fois par DISPATCH_WAKE_INTERVAL (5 ms par défaut), après le commit de la ligne. La transaction d’admission elle-même ne porte aucun NOTIFY : PostgreSQL retient un verrou à l’échelle de la base depuis le moment où une transaction met une notification en file jusqu’à son commit, de sorte qu’une insertion notifiante ne peut pas committer en groupe. Un réveil perdu ne coûte que le POLL_INTERVAL de latence du dispatcher.

28.3. Configuration

Lu depuis [pepsi-ingress] (politique d’acceptation, limites, timeouts, DNS), les sockets [pepsi-ingress-listener-*] (transport et authentification des clients, par listener), et les sections partagées [pepsi-postgres], [pepsi], [pepsi-sendmail] et [pepsi-srs]. La surcouche de configuration en base est appliquée par-dessus. Référence complète : pepsi.conf(5) et Configuration.

28.4. Sorties vers le pipeline

Sème le state de la ligne avec origin (provenance SMTP), auth (les verdicts SPF/DKIM/DMARC), local_origin, spam = false pour un message dont l’unique destinataire est <Postmaster> et, sur demande, dsn (paramètres RFC 3461). Voir Architecture pour le modèle d’état.

28.5. Voir aussi

pepsi-dispatch, pepsi-stage-arc, pepsi-stage-srs, Fonctionnalités prises en charge, pepsi-ingress(1), pepsi.conf(5).