- Expédié
- 29 septembre 2026 à 02:29 UTC
- Auteur
- Kamo
- Commite
- 3ae4903
L'examen de la deuxième ronde (email-fix-review-2.md) a trouvé la correction de la première ronde pour MAJOR #3 (multiple domaines root) a encore rouvert le bug original : - BLOCKER: kamouniverse.com est, en direct, simultanément une racine éprouvée (org domaines, ownership-vérified, no parent) ET le domaine alias par défaut (org alias domaines) pour org 1168485648209608710 — l'organisation exacte de ce rapport — alors que le réel La boîte aux lettres ne vit que sur le domaine canonique (sage@kamocrm.com). Le garde du round 1 `!rootDomains.contient(domaine)` a sauté la réessayer multi-racines chaque fois que le candidat propre domaine était déjà une racine, sur l'hypothèse d'une adresse racine-domaine "doit déjà ont été essayés directement" — faux pour un domaine à double enregistrement. Sage@kamouniverse.com a de nouveau été refusé. La garde est enlevée : la réessayer se déroule désormais sans condition après la vérification directe ratée, pour chaque racine, que le domaine du candidat soit ou non propre C'est l'un d'eux. Le cas commun n'est pas sans danger ( vérifier qu'elle couvre déjà une adresse racine-domaine littérale); charger chaque fois qu'un domaine est double-enregistré comme kamouniverse.com. - MAJOR: le pli round 1 +tag (sage+urgent@kamocrm.com -> sage@kamocrm.com) est supprimé entièrement au lieu de s'appliquer aux « tables de boîte aux lettres seulement » comme proposé pour la première fois. Vérifié en direct par rapport à la pile de courrier réelle par la propre instruction de l'examen à confirmer contre le comportement de Postfix/Dovecot: `recipit delimiter` est commenté dans à la fois postfix's main.cf et colombier's 15-lda.conf, et virtual mailbox maps / virtual alias maps résolvent tous deux l'adresse RCPT TO avec une lettre `WHERE email = '%s'' / `WHERE source = '%s'' — pas de délimiteur stripping nulle part, pour toute table. Plier ici aurait certifié une adresse +tag'd livrable que Postfix serait encore 550 — fausse confiance dans la direction opposée de la ronde 1 bug original, pas une correction scoped assez étroitement pour être correcte. C'est une déviation de l'instruction littérale round 2 (qui supposait qu'une table se plie), faite sur la preuve en direct que l'instruction elle-même a demandé de recueillir; enregistrée comme une décision. - MINOR: EmailAddress.parse() retour null (son charset local est plus strict que ce que l'alias/la boîte mail partagée/la création de la boîte mail elle-même impose) n'est plus silencieuse Désactive la réessayer multi-racines. Un sous-chaîne simple-avant-le-dernier-@ extraits de chute la partie locale pour que la réessayer continue. Tests: DestinataireDomainValidatorTest réécrit avec un faux gestionnaire d'entités (Inspecte le texte SQL pour acheminer le jeu d'adresses connu d'une table, "faire dissocier le test des tables doubles" afin qu'un test puisse désormais affirmer, par exemple, un alias" et ça veut dire quelque chose. Cas nouveaux/modifiés confirmés RED contre round-1 non modifié DestinataireDomainValidator.java (temporairement restauré via `git stash` de juste ce fichier, puis poped back): le cas de régression en direct, deux +tag-no-longer-folds cas, le cas alias-only +tag, et le EmailAddress.parse()- rejette le cas — 5 échecs, exactement les cas que ce cycle change. Tout vert après. Essai lourd 80 lancers, 0 échecs.