Apertura di una nuova richiesta di funzionalità qui, attualmente Discourse consente solo un singolo indirizzo email che viene utilizzato sia per envelope-from che per reply-to. Se un sito desidera utilizzare il proprio SMTP di dominio per l’invio di email ma desidera che le risposte alle email vengano inviate a un dominio diverso (ad esempio, Gmail), le email inviate falliranno DMARC. Separando questi due campi di intestazione si eviterà un errore DMARC e non si perderà la capacità di gestire le email respinte.
Non capisco come verranno gestiti i bounce in questo scenario. I bounce vanno all’envelope from, non all’indirizzo nel Reply-To. Quindi, se il tuo envelope from non è in grado di gestire email con tag VERP, sarai ancora nei guai.
Nell’argomento a cui fai riferimento, non spieghi perché la firma DKIM contro il dominio nell’intestazione From: non funziona. Ciò dovrebbe fornire l’allineamento DMARC, anche se SPF fallisce. Questo è l’approccio che prenderei, se fossi nella tua posizione (o quello, o rivolgermi agli amministratori del server SMTP in entrata di yyy.com con un forcone; che tipo di MTA non supporta alcun tipo di indirizzamento dettagliato?!?)
Funzionerà perché l’MTA supporta il catch-all. Sebbene non supporti VERP, può essere configurato per inoltrare tutte le e-mail non specificate a un indirizzo specifico, in modo che le risposte di rimbalzo non vengano perse.
Inoltre, se separi envelope-from e reply-to, envelope-from non ha bisogno di contenere un indirizzo VERP. Può essere un semplice indirizzo come discourse@yyy.com. Quindi, quando rimbalza, ritorna a discourse@yyy.com che non fallirà SPF.
Il reply-to può avere un indirizzo e-mail diverso che supporta VERP come discourse-yyy+sdfkj33@gmail.com in modo che, se consegnato con successo, quando l’utente risponde, arrivi al server Gmail che supporta VERP e non fallirà DMARC poiché il from è ancora yyy.com.
Sono d’accordo, ma non li produciamo noi. Poiché supportano il catch-all addressing, non supporteranno VERP. Sfortunatamente questa è la situazione, spero che con una piccola modifica Discourse sarà in grado di supportare un ecosistema più diversificato. Molti siti più piccoli che utilizzano Gmail per gestire le risposte si troverebbero in questa situazione.
Se il tuo MTA supporta un catch all, perché non puoi inoltrare le risposte con la stessa funzionalità ed eliminare completamente Gmail?
L’envelope from è l’indirizzo che deve supportare VERP, perché l’unico modo per identificare in modo affidabile la causa di un rimbalzo è tramite le informazioni nell’indirizzo envelope from dell’email originale, come spiegato in precedenza da Michael.
Ho i miei dubbi su questa affermazione. L’utilizzo di un indirizzo Gmail per le risposte è goffo, ed è sempre stato goffo; il mail-receiver è un modo molto più semplice, affidabile e meno goffo per gestire le risposte (e i rimbalzi).
Anche per quei piccoli siti che utilizzano Gmail, i più piccoli probabilmente ignorano i Termini di Servizio e utilizzano Gmail anche per inoltrare le email in uscita, e la stragrande maggioranza degli altri probabilmente non è vincolata a un MTA che non supporta l’indirizzamento dettagliato.
Perché è un catch all per il dominio, viene utilizzata una sola email per discourse.
Non necessariamente, al momento lo sto usando senza VERP e funziona. Il mio problema è che non posso far rispondere direttamente all’utente da gmail senza un fallimento SPF / DMARC a causa del modo in cui discourse imposta gli indirizzi envelope-from e reply-to. Invece devo far inoltrare la MTA a gmail. Se potessi rispondere direttamente a gmail (senza un fallimento DMARC/SPF) allora potrei usare VERP per proteggere le risposte, ma sì, il VERP verrà ignorato per le email respinte. È comunque più sicuro dell’implementazione attuale.
Non è un’opzione come ho spiegato qui. È pratico usare gmail solo per l’inbound. Impostare il proprio MX in entrata diretto quando si ha già un MX dal proprio provider di hosting può essere difficile per chi non è iniziato. Le risposte dirette di gmail sono molto più facili e meno soggette a errori.
Forse mi sfugge qualcosa nel tuo ragionamento. Vedo solo vantaggi nel separare gli indirizzi envelope-from e reply-to, supporta ecosistemi più diversi ed è più sicuro, aiutando a evitare fallimenti SPF/MARC.
Il mio ragionamento è che la risposta corretta al tuo problema, come espresso finora, sia configurare DKIM. Rendere la configurazione della posta elettronica ancora più complicata e soggetta a errori non è giustificato dal tuo caso d’uso, secondo me.
DKIM è già configurato, il problema è che SPF fallisce.
L’aggiunta di un campo extra per separare gli indirizzi envelope-from e reply-to fornirà molta flessibilità e consentirà anche a SPF di passare (cosa che non passerà se si dispone di un server SMTP che inoltra e-mail o non supporta VERP). Il campo può essere nascosto nell’interfaccia utente o impostato per corrispondere agli indirizzi envelope-from e reply-to a meno che gli amministratori non decidano specificamente di sovrascriverlo. La descrizione può rimandare a questa pagina. Tuttavia, non vedo come possa peggiorare le cose, può SOLO migliorare: o sono uguali (nel qual caso SPF fallirà in qualsiasi scenario descritto qui) o migliorerà la recapitalità.