Quanto segue è qualcosa che ho osservato tramite tentativi ed errori, ma per cui non ho trovato documentazione né ho incontrato un avviso o un errore.
Sul nostro sito, che è ospitato da Discourse (per il quale siamo molto grati!), l’impostazione di un indirizzo email in entrata personalizzato per una categoria sembra funzionare solo se l’indirizzo email è preceduto da “foo+” (dove ‘foo’ è lo slug generale per il nostro sito).
Nello specifico, spesso imposto una nuova categoria, imposto quello che considero un indirizzo email intuitivo per essa, invio un’email di prova a quell’indirizzo e non ricevo mai un messaggio di errore né lo vedo apparire nei log delle email ricevute o rifiutate del nostro sito. Poi alla fine mi ricordo le mie esperienze precedenti, imposto l’indirizzo su foo+<some name>, eseguo un altro test e funziona immediatamente.
Se non me lo sto immaginando, questo sembra comprensibile come mezzo per Discourse per distinguere le email destinate a un sito ospitato da un altro, ma volevo verificare di essere nel giusto. Oppure, se non lo sono, vedere se ci sono altre spiegazioni per cui le mie scelte iniziali di indirizzo email sembrano finire in /dev/null.
Può sembrare semplice/riduttivo dirlo ad alta voce, ma l’indirizzo email personalizzato funziona solo se viene effettivamente recapitato al sito.
Quindi non puoi semplicemente mettere qualsiasi cosa lì, l’indirizzo deve essere recapitato al sito per avere una possibilità di funzionare.
Non c’è modo per Discourse di effettuare alcuna verifica di quell’indirizzo per garantire che ciò accada, quindi spetta all’amministratore assicurarsi che ciò avvenga.
Sul nostro hosting consiglio di sfruttare alcuni indirizzi che abbiamo predisposto per essere recapitati al tuo sito:
{QUALSIASI COSA}@{IL TUO PREFISSO}.discoursemail.com
Per il nostro sito (ospitato), non mi ero reso conto che …@{OUR PREFIX}.discoursemail.com fosse un’opzione e ho sempre e solo provato a usare …@discoursemail.com come hostname perché è quello che usa l’indirizzo predefinito per “accettare email in arrivo” (e ho aggiornato la mia domanda originale qui sopra per cercare di chiarire questo, dato che avevo omesso l’hostname nella domanda originale). Ci proverò, grazie per il suggerimento!
Anche se capisco che Discourse non può verificare gli indirizzi email per le istanze self-hosted di Discourse, sarebbe possibile che le istanze ospitate generassero un avviso o un errore se l’indirizzo email non fosse di un formato atteso? (o un formato atteso quando si usa un indirizzo …discoursemail.com?
Credo che tu abbia confermato il mio sospetto che questo sia un problema specifico dei siti Discourse ospitati come il nostro. Non so quale livello di sforzo sarebbe richiesto per far sì che tali siti verifichino che gli indirizzi …discoursemail.com inseriti in questo campo siano validi, ma una tale funzionalità mi avrebbe risparmiato una discreta quantità di tempo e frustrazione negli ultimi anni di configurazione di nuove mailing list e alias, chiedendomi perché non funzionassero. Immagino che aiuterebbe anche altri.
In alternativa, anche un piccolo suggerimento (tool tip) su quel campo per un sito ospitato che indichi che un indirizzo legale deve essere slug+...@discoursemail.com o ...@slug.discoursemail.com sarebbe di grande aiuto. Anche se non so se rendere quel suggerimento specifico per i siti Discourse ospitati renda tale approccio impraticabile.
Questo non è vero: il vincolo è che l’email deve essere consegnata (non indirizzata) a uno di questi indirizzi per funzionare. Un esempio è la seguente configurazione che noi e molti dei nostri clienti utilizziamo:
(in Discourse) configurare la categoria Postings per accettare email in arrivo inviate a postings@contoso.com
(sul server di posta contoso.com) configurare postings@contoso.com per inoltrare a {ANYTHING}@contoso.discoursemail.com
risultato finale: la posta indirizzata a postings@contoso.com viene inviata alla categoria Postings
Questo funziona in modo efficace allo stesso modo di:
(in Discourse) configurare la categoria Postings per accettare email in arrivo inviate a postings@contoso.discoursemail.com
risultato finale: la posta indirizzata a postings@contoso.discoursemail.com viene inviata alla categoria Postings
@supermathie — Ottimo punto sul fatto che l’indirizzo di consegna sia più rilevante di quello a cui è indirizzata la posta.
Affino la mia precedente richiesta, penso che un avviso quando si tenta di inserire indirizzi email in entrata che corrispondono ai pattern @discoursemail.com o @*.discoursemail.com, ma che non iniziano con slug+… o non terminano con @slug.discoursemail.com sarebbe comunque prezioso per avvisare le community ospitate da Discourse.
Ciò consentirebbe ancora il tuo primo caso (poiché non ha discoursemail.com come suffisso) pur avvisandomi di aver tentato di configurare un indirizzo slug-users@discouresmail.com, che è il tipo di pattern a cui ho sempre fatto ricorso e poi mi sono confuso quando le email inviate ad esso venivano silenziosamente ignorate.
(Nota che anche il tuo secondo caso non genererebbe un avviso, supponendo che contoso sia lo slug della tua community).