KamoCRM

Recuperare ogni dominio di proprietà incondizionatamente, e cadere il +tag fold

FixEmailService
Spegnimento
29 settembre 2026 alle ore 02:29 UTC
Autore
Kamo
Impegno
3ae4903

Round 2 recensione (email-fix-review-2.md) trovato il round 1 fix per MAJOR #3 (multiple domini root) ha ancora riaperto il bug originale: - BLOCKER: kamouniverse.com è, live, contemporaneamente una radice provata (org domains, proprietà-verificata, nessun genitore) E il dominio alias predefinito (org alias domains) per — l'esatto org della presente relazione — mentre la realtà mailbox vive solo sul dominio canonico (sage@kamocrm.com). La guardia rotonda 1 `!rootDomains.contains(domain)` ha saltato la riprovazione multi-root ogni volta che il candidato il proprio dominio era già una radice, sul presupposto un indirizzo root-domain "deve già sono stati provati direttamente" — falso per un dominio a doppia registrazione. sage@kamouniverse.com è stato rifiutato di nuovo. La guardia viene rimossa: la riprovazione ora scorre incondizionatamente dopo il controllo diretto manca, per ogni radice di proprietà, sia che il proprio dominio del candidato capita di essere uno di loro. Redundant-but-harmless per il caso comune (il diretto controllare già copre un indirizzo root-domain letterale); porta-carico ogni volta che un dominio è a doppia registrazione come kamouniverse.com. - MAJOR: il giro 1 +tag (sage+urgent@kamocrm.com -> sage@kamocrm.com) è rimossa completamente piuttosto che portata a "tavoli di posta elettronica solo" come primo proposto. Controllato dal vivo contro la mail stack reale per le istruzioni della recensione a conferma contro il comportamento Postfix/Dovecot: `recipient delimiter` viene commentato in entrambi postfix's main.cf e tortocot 15-lda.conf, e virtual mailbox maps / virtual alias maps entrambi risolvono l'indirizzo RCPT TO con un letterale `WHERE email = '%s'` / `WHERE source = '%s'` — nessun delimitatore stripping ovunque, per qualsiasi tavolo. Piegare qui avrebbe certificato un indirizzo +tag'd consegnabile che Postfix sarebbe ancora 550 — falsa fiducia nella direzione opposta dal 1 ° round bug originale, non una correzione portata limitata abbastanza per essere corretta. Questa è una deviazione dal tondo letterale 2 istruzione (che presumibilmente qualche tavolo fa piegare), fatto su l'evidenza live che l'istruzione stessa ha chiesto di raccogliere; registrato come una sentenza. - MINOR: EmailAddress.parse() restituire null (il suo charset locale è più rigoroso di quello che alias/shared-mailbox/mailbox creazione stessa fa rispettare) non più silenziosamente disabilita la ricerca multi-radice. Un semplice sottostring-prima-last-@ estratti di fallback la parte locale in modo che il retry ancora corre. Test: RecipientDomainValidatorTest riscritto con un falso da tavolo EntityManager (Ispezionare il testo SQL per indirizzare il proprio set di indirizzi noto di una tabella, per la recensione "fare il test doppio dire i tavoli a parte") così un test può ora affermare ad esempio "conosciuto solo come un alias" e avere significa qualcosa. Nuovi/casi cambiati confermati RED contro tondo unmodified-1 RecipientDomainValidator.java (temporaneamente restaurato tramite `git stash` di solo quel file, poi popped indietro): il caso di regressione live-shape, due +tag-no-longer-folds casi, il solo alias +tag caso, e il EmailAddress.parse()- respinge il caso — 5 fallimenti, esattamente i casi che questo round cambia. Dopo tutto verde. E' un test di mvn pesante. 80 run, 0 guasti.

Tutte le modifiche

Come quello che vedi la spedizione?

Tutto questo arriva nel vostro spazio di lavoro da solo. Iniziare sul piano gratuito e leggere di nuovo questa pagina in un mese.

Inizia gratis per sempreVisualizza il prezzo