Sto cercando di capire come far sì che Discourse pulisca le liste email, in particolare le email respinte. Il sito utilizza un server SMTP privato per inviare email, ma la risposta è impostata per tornare a un indirizzo Gmail per l’accesso POP da parte di Discourse.
Quindi vedo le email respinte nella dashboard delle email Ricevute.
Discourse utilizza la reply_key per associare i bounce alle email inviate. Quando Discourse invia email, utilizza il valore reply_by_email_address come mittente della busta SMTP.
È necessario assicurarsi che il tuo reply_by_email_address includa una {reply_key} in modo che la tua istanza possa associare i bounce all’email inviata corretta.
Ad esempio, qui su meta è impostato su incoming+%{reply_key}@meta.discoursemail.com e qualsiasi cosa inviata a quell’indirizzo viene recapitata a questa istanza.
Grazie per la risposta. Sfortunatamente ho dovuto disattivare la reply_key dalla risposta all’email perché il nostro server di inoltro email non riconosce l’indirizzamento con il simbolo +. C’è qualche altra opzione?
Il tuo server di inoltro email non dovrebbe avere importanza, solo il server finale dove si trova la casella di posta. Le parti locali dell’email sono opache a qualsiasi server intermedio.
Non è Gmail come da:
Non sono sicuro se abbiamo un altro meccanismo per rilevare in modo affidabile i bounce.
Per chiarire, il server del dominio SMTP di destinazione che riceve l’email respinta non riconosce l’indirizzamento con il +, quindi inoltra le email in base al campo To all’indirizzo Gmail che viene raccolto da Discourse tramite POP. Ciò significa che se il campo To include la reply_key, quell’email non verrà inoltrata all’account Gmail utilizzato da Discourse.
Quindi non posso inserire la reply_key nell’indirizzo email, può essere inserita altrove? Nel campo oggetto o nel corpo o in un punto in cui Discourse possa analizzarla?
L’email inviata da Discourse proviene da discourse@xxx.com tramite un server SMTP dedicato configurato per Discourse (utilizzando l’indirizzo del dominio di Discourse).
Qualsiasi risposta o rimbalzo dell’email viene inoltrato dal server SMTP del dominio a discourse.xxxx@gmail.com. Questo server SMTP del dominio non può riconoscere l’indirizzo con +, quindi se includo la reply_key nell’indirizzo email di risposta, verrà scartata dal server SMTP del dominio. Posso solo impostare regole per inoltrare indirizzi email in arrivo discreti/unici.
Il forum Discourse utilizza quindi POP tramite GMail per accedere a tali risposte/email respinte inoltrate e le analizza.
Capisco cosa stai dicendo. Sfortunatamente, a causa di una limitazione delle regole del server SMTP, non posso configurare l’inoltro per i sottodomini, posso solo configurarlo per inoltrare ID email To univoci.
Tuttavia, ho una chiarificazione qui, più simile a una discrepanza nel modo in cui Discourse sembra funzionare:
Quando un utente risponde a un post via email, arriva correttamente: le risposte sembrano funzionare perfettamente anche senza alcuna {reply_key} configurata esplicitamente da nessuna parte (vedi gli screenshot sopra).
Tuttavia, quando un’email viene respinta, Discourse la categorizza come Ricevuta anziché Respinta.
I log degli errori mostrano che qualcosa in Discourse riconosce che si tratta di un’email respinta (vedi il log degli errori del mio primo post). Quindi, se qualcosa in Discourse riconosce che si tratta di un’email respinta, perché non viene visualizzata sotto Respinta invece che Ricevuta?
Quindi, perché quando un utente risponde a un post questo viene elaborato correttamente da Discourse ma non un’email respinta (e sembra esserci anche una disconnessione tra i log degli errori e la dashboard per le email respinte)? Mi sfugge qualcosa nella configurazione?
Ho anche provato a impostare le impostazioni di reply by email address in Discourse su discourse.xxx+%{reply_to}@gmail.com, ma poi quando l’email viene recapitata, Gmail sembra pensare che il dominio yyy.com (dominio SMTP di Discourse) stia cercando di falsificare il dominio Gmail e finisce per contrassegnarla come spam. Sembra che l’impostazione di un dominio di risposta diverso dal dominio del mittente attivi un errore DMARC e SPF.
ARC-Authentication-Results: i=1; mx.google.com;
spf=softfail (google.com: domain of transitioning discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com does not designate y.y.y.y as permitted sender) smtp.mailfrom=discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yyy.com
Return-Path: <discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com>
Hai disattivato find related posts with key (spero tu abbia letto l’avviso), quindi Discourse utilizza l’intestazione dell’email in-reply-to per determinare a quale argomento/post fare riferimento la risposta.
Non può farlo per i bounce: Discourse deve conoscere il messaggio specifico che è stato respinto e tali informazioni sono garantite solo in un punto: l’indirizzo To: (che proviene dall’indirizzo envelope-from del messaggio originale).
Affinché ciò funzioni, quando Discourse invia un messaggio, deve ricevere la risposta dall’indirizzo da cui proviene. Discourse cerca questo nell’intestazione To: (non nell’envelope-to).
sta falsificando il dominio di gmail
Se vuoi inviare posta da un indirizzo gmail, devi inviarla tramite i loro server. Ma a loro non piace.
Non sembra che tu abbia configurato DKIM per yyy.com; dovresti farlo. Se lo fai correttamente, DMARC dovrebbe passare.
Sì, è configurato e l’email “inviata” da Discourse tramite il server SMTP di yyy.com supera SPF, DKIM e DMARC senza problemi (almeno dalla pagina “Invia email di prova” nella console di amministrazione).
Questo problema si verifica se imposto un indirizzo Gmail come reply_by_email_address a un indirizzo gmail.com invece che all’indirizzo yyy.com. C’è qualcosa che posso fare per questa configurazione in modo che DMARC non fallisca quando impostato su reply_by_email_address a un indirizzo Gmail mantenendo il server in uscita come yyy.com?
Non può analizzare il resto del contenuto/allegati nell’email respinta per estrarre tali informazioni se non può trovare ciò di cui ha bisogno nel posto “ovvio” (o almeno fornire un’opzione nelle impostazioni per farlo con gli avvisi necessari sull’impersonificazione)?
L’allineamento DMARC fallisce poiché in questa situazione viene utilizzato reply_by_email_address come indirizzo envelope-from.
Praticamente l’ unica cosa che è garantito sia intatta su un rimbalzo è l’indirizzo.
Forse l’oggetto, ma non sarebbe pratico inserire queste informazioni lì.
Vedo che alcuni sistemi includono il messaggio originale come allegato… è teoricamente possibile che possiamo controllare i rimbalzi per un allegato per ottenere maggiori informazioni, se esistono.
Se ho capito bene, l’reply_by_email_address dovrebbe essere impostato nel campo reply-to dell’envelope inviato da Discourse (da yyy.com). Quindi, quando l’utente risponde, risponde all’reply-to email (gmail.com) anziché all’indirizzo originale (yyy.com). Pertanto, nell’envelope della risposta email, l’indirizzo from dovrebbe essere l’indirizzo email dell’utente e il to dovrebbe essere l’indirizzo gmail.com.
Perché l’reply_by_email_address verrebbe utilizzato come indirizzo from?
l’reply_by_email_address non viene utilizzato come indirizzo from ma come envelope-from, specificamente in modo che i bounce funzionino
Ecco un’immagine che dimostra come viene utilizzato ciascun indirizzo. Gli indirizzi stessi sono specifici per il nostro hosting, ma dovrebbero essere sufficienti come esempio.
Quindi, in pratica, reply_by_email_address viene utilizzato nell’intestazione from in modo che ritorni a quell’indirizzo email in caso di rimbalzo. E lo stesso indirizzo email è anche impostato nell’intestazione reply-to se le risposte via email sono abilitate.
Quindi, se la mia comprensione di cui sopra è corretta, allora se discourse potesse avere un’impostazione separata (reply_to_email) per l’intestazione reply-to, ciò risolverebbe il problema del fallimento DMARC. Quando si utilizza il dominio yyy.com (preso da reply_by_email_address) per from durante l’invio e gmail.com per il reply-to (preso da una nuova impostazione reply_to_email). Se l’email rimbalza, verrà comunque restituita a reply_by_email_address, ma se l’utente risponde, andrà a reply_to_email.
Per superare DMARC, SPF (che convalida l’envelope-from in combinazione con l’IP di invio) o DKIM (che convalida i campi From e checksum del messaggio) devono allinearsi.
Sembra che lo scopo di questo esercizio sia avere un indirizzo “reply-to” “carino”, a cui gli utenti rispondono?
Vuoi qualcosa del genere?
envelope-from: outgoing+12309847801923840923502389423@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
Devi avere quell’envelope-from in questo modo, altrimenti i rimbalzi non funzioneranno.
Sì, è corretto. L’idea è di avere l’envelope-from diverso dal reply-to.
Poiché il dominio envelope-from e l’IP di invio corrispondono, l’SPF dovrebbe passare, ma allo stesso tempo la risposta può andare a GMail per elaborare le risposte e se l’email dovesse rimbalzare, tornerà al server del dominio originale che potrà quindi inoltrare il rimbalzo alla casella di posta di GMail.
In realtà assomiglierebbe a questo:
envelope-from: outgoing@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
Nella mia configurazione l’outgoing non avrà un VERP perché il mio SMTP in entrata non supporta VERP (cioè, il rimbalzo non avrà un indirizzo VERP), ecco perché il reply-to viene inviato a GMail perché supporta VERP. Questo non dovrebbe causare un fallimento DMARC come sta succedendo ora.
