38. pepsi-stage-relay-to-internet

Remise directe vers le MX avec MTA-STS.

38.1. Rôle

pepsi-stage-relay-to-internet remet un message directement aux serveurs MX du domaine destinataire, en effectuant sa propre découverte MX et sa propre application de la politique TLS. C’est l’une des deux étapes de remise interchangeables. Référence : pepsi-stage-relay-to-internet(1).

38.2. Fonctionnalités

38.2.1. Découverte MX (RFC 5321 / RFC 7505)

  • Résolution MX propre, hôtes essayés par préférence croissante (préférence égale dans un ordre aléatoire) ; un domaine sans MX se replie sur ses enregistrements d’adresse (MX implicite, RFC 5321 §5.1).

  • Le Null MX (RFC 7505, 0 .) et un domaine inexistant sont des échecs permanents, jamais des réessais.

  • Sélection d’adresse Happy-Eyeballs parmi A/AAAA, intersectée avec ADDRESS_FAMILY ; les adresses résolues sont mises en cache par adresse (avec la santé de la connexion) dans la table pepsi.dns_address, de sorte qu’une adresse fonctionnelle est préférée jusqu’à expiration de son TTL DNS.

38.2.2. Sécurité du transport (RFC 8461 / RFC 6125)

  • Découverte et application MTA-STS (RFC 8461) (sauf si MTA_STS = no) : une politique enforce restreint la remise aux hôtes MX listés via STARTTLS avec un certificat qui valide pour l’hôte (RFC 6125). Une politique testing est validée de la même manière et le résultat noté pour le TLS Reporting, mais un échec se rabat sur un STARTTLS opportuniste vers tous les hôtes MX ; sans politique, la remise utilise un STARTTLS opportuniste. Les consultations de politique ne sont fail-open que lorsque rien n’est en cache. La sous-commande mta-sts affiche la politique applicable.

  • DANE/TLSA (RFC 7672), par hôte MX : DANE = off | warn | strict, par défaut warn. Lorsque des enregistrements TLSA utilisables existent et que le RRset MX est sécurisé par DNSSEC (Pepsi lit le bit AD du résolveur ; il ne valide pas DNSSEC lui-même), ils l’emportent sur MTA-STS pour cette connexion — à ceci près que le mode warn ne remplace jamais la validation PKIX d’une politique MTA-STS enforce. Une discordance d’enregistrement utilisable diffère la remise sous strict et se contente d’avertir sous warn. Un hôte dont les enregistrements TLSA sont tous inutilisables doit tout de même proposer STARTTLS (RFC 7672 §2.2).

38.2.3. Remise, réessai et rebond

  • Envoie avec l’expéditeur d’enveloppe propre au message (expéditeur nul pour les rebonds), un destinataire par tentative : une ligne à plusieurs destinataires est d’abord scindée en une ligne par destinataire.

  • En cas de succès, termine la ligne (ou avance vers NEXT_STAGE).

  • Backoff exponentiel sur échec transitoire (RETRY_INITIAL/RETRY_MAX_INTERVAL/RETRY_FACTOR) ; au-delà de MAX_LIFETIME, un échec transitoire devient permanent.

  • Détection de boucle via MAX_HOP_COUNT en-têtes Received:.

  • Un échec permanent d’un message ordinaire achemine vers BOUNCE_STAGE (ou marque la ligne failed) ; un échec permanent d’un rebond ne rebondit jamais à nouveau — une copie part vers POSTMASTER s’il est défini, sinon elle est abandonnée.

38.2.4. Propagation et génération de DSN (RFC 3461)

  • Propage RET/ENVID/NOTIFY/ORCPT au MX seulement lorsqu’il annonce DSN.

  • En cas d’échec permanent, remet les NOTIFY/ORCPT/ENVID du destinataire à l’étape de rebond, de sorte qu’un DSN d’échec n’est généré que s’il a été demandé.

  • DSN de succès (Action: delivered) lorsque ORIGINATE_SUCCESS_DSN + NOTIFY=SUCCESS ; DSN de délai (Action: delayed, une seule fois) lorsque DELAY_DSN_AFTER s’écoule et que NOTIFY=DELAY.

38.2.5. Adaptation du contenu (RFC 6152 / RFC 6531)

  • Adapte le message aux extensions que le MX annonce : ré-annonce BODY=8BITMIME / SMTPUTF8 lorsqu’elles sont prises en charge, sinon rétrograde le corps (RFC 2045) et les en-têtes UTF-8 (RFC 2047). Une adresse non ASCII qui ne peut pas être représentée vers un saut sans SMTPUTF8 rebondit, tout comme un corps encore 8 bits après la rétrogradation — la RFC 6152 §3 n’autorise aucune tentative de l’envoyer.

38.3. Configuration

[stage-<name>] avec PROGRAM = pepsi-stage-relay-to-internet : SERVER_NAME (obligatoire), NEXT_STAGE/BOUNCE_STAGE, POSTMASTER, les timeouts (CONNECT_TIMEOUT/COMMAND_TIMEOUT/DATA_TIMEOUT), la politique de réessai (RETRY_INITIAL/RETRY_MAX_INTERVAL/RETRY_FACTOR/MAX_LIFETIME/ DELAY_DSN_AFTER), MAX_HOP_COUNT, le DNS (DNS_SERVERS/DNS_TIMEOUT), MTA-STS (MTA_STS/MTA_STS_TIMEOUT), DANE et ADDRESS_FAMILY. Les durées doivent utiliser les unités h/m/s. Référence complète : pepsi-stage-relay-to-internet(1).

38.4. État

  • Entrées : state.dsn (propagation + conditionnement des rapports) et state.origin (indications 8BITMIME/SMTPUTF8).

  • Sorties : attempts/last_error/delay_sent à la mise en pause ; un objet state.bounce (permanent/success/delay) lors de l’acheminement vers l’étape de rebond ou de la mise en file pour celle-ci ; last_error au fail terminal. state.dsn et state.origin sont préservés.

38.5. Voir aussi

pepsi-stage-relay-to-smarthost, pepsi-stage-bounce, Fonctionnalités prises en charge, pepsi-stage-relay-to-internet(1).