Sembra esserci un gran numero di casi strani in cui le e-mail non dovrebbero essere effettivamente rifiutate, ma lo vengono comunque. Questo significa che a volte gli utenti inviano e-mail di supporto che non riceviamo mai.
Ad esempio, le e-mail inviate al nostro indirizzo di supporto da indirizzi mac.com vengono spesso rifiutate perché prive di corpo (Email::Receiver::NoBodyDetectedError). Spesso queste e-mail hanno effettivamente un testo nel corpo, quindi potrebbe esserci un problema di analisi.
Ma oltre a risolvere la causa di questi rifiuti errati, sarei felice se potessimo ricevere un avviso ogni volta che si verificano nuovi rifiuti, così da poterli esaminare e verificare se il rifiuto era appropriato.
Ciò potrebbe avvenire sotto forma di un’opzione per inviare avvisi al personale per tutti i rifiuti, o di un’opzione per mettere semplicemente in copia (CC) tutte le e-mail di rifiuto al personale.
In caso contrario, se non vogliamo perdere nessuna e-mail di supporto in arrivo, dovremmo controllare continuamente l’elenco delle e-mail rifiutate nel back-end di Discourse. Questa procedura è laboriosa e non necessaria.
Credo sia meglio concentrarsi sull’esempio specifico. Hai detto “spesso” rifiutate, hai notato qualche pattern qui nel contenuto dell’email? Se fosse un problema costante, mi aspetterei che tutte le email da mac.com falliscano.
Beh… ‘spesso’ nel senso di ‘abbastanza spesso da essere un po’ fastidioso’. La nostra principale preoccupazione è che non vogliamo che le persone si arrabbino per una presunta mancanza di risposta da parte del nostro team di supporto.
Ho cercato schemi nei casi che ho notato. Inizialmente pensavo che potesse esserci un problema nel modo in cui mac.com gestiva le e-mail, ma ho successivamente determinato che abbiamo circa 30 utenti con indirizzi mac.com che non mostrano alcun problema.
Ho anche pensato che, se mac.com avesse un client di webmail, potrebbe gestire le e-mail HTML in modo non standard. Ma non sono nemmeno sicuro che esista un client di webmail per mac.com.
Pensavo di aver capito quando mi sono reso conto che l’incidente più recente riguardava e-mail che contenevano solo righe citate nel corpo, ma i test successivi hanno mostrato che Discourse elabora correttamente tali e-mail.
Rivedrò i log per vedere quanto spesso si è verificato questo tipo di cosa e, naturalmente, cercherò schemi. Stavo solo pensando che, finché esiste la possibilità che Discourse commetta occasionalmente errori del genere, un’e-mail di avviso sembra una precauzione abbastanza semplice.
Grazie per il chiarimento. Quindi, fondamentalmente, qualsiasi problema relativo alle email provenienti da indirizzi mac.com dovrebbe interessare anche gli indirizzi me.com e altri indirizzi iCloud.
Non c’è un vero schema. Ci sono 21 casi in cui il motivo del rifiuto non è del tutto chiaro o sembra errato.
1 x “Impossibile elaborare l’email: il corpo è troppo simile a quanto pubblicato di recente”
8 x “Impossibile elaborare l’email: Email::Receiver::BadDestinationAddress” - questi sono piuttosto misteriosi; perché gli indirizzi sono errati?
3 x “Impossibile elaborare l’email: Email::Receiver::NoBodyDetectedError” - due sembrano avere un testo del corpo normale; uno riporta semplicemente “nessun corpo”
1 x “Impossibile elaborare l’email: Email::Receiver::TooShortPost”
6 x “Impossibile elaborare l’email”
1 x “Impossibile elaborare l’email: Spiacenti, i nuovi utenti possono inserire un’unica immagine in un post.”
1 x “Errore non gestito: errore di sintassi, espressione non riconosciuta: #xxxxxx-email:product at company dot com”
Molti di questi riguardavano tentativi legittimi di comunicazione da parte dei clienti. Non è chiaro se l’email di rifiuto inviata da Discourse sia finita nella cartella spam del mittente o sia stata semplicemente ignorata.
Hanno inviato a un indirizzo che non stai gestendo, come ad esempio support.
Per me, solo la casella “nessuno” dove dici che ce n’è una sembra qualcosa che potrebbe essere un bug. Una possibilità è che sia dovuto all’uso di un client di posta vecchio e non funzionante.
Ho controllato alcuni di questi (Email::Receiver::BadDestinationAddress) e molti sembrano essere risposte legittime da parte dei clienti, con il destinatario in questa forma: replies+longidentifier@discourse.site.com. L’email di avviso inviata da Discourse al mittente suggerisce che l’email è stata inviata da un indirizzo diverso da quello associato all’argomento di riferimento, il che è probabilmente la spiegazione, ma in un caso del genere vorrei comunque che il personale venisse avvisato.
Sembra effettivamente un bug, ma anche se vorrei vederlo risolto, ritengo che ci saranno sempre casi come questo, quindi, oltre a indagare sui possibili bug di analisi delle email, un’email di avviso al personale ci permetterebbe di fornire supporto tempestivo nel frattempo.
È proprio quello che pensavo. La prossima volta che vedo questo, chiederò al cliente quale client di posta stanno utilizzando.
Il punto che vorrei sottolineare è che, quando le email vengono rifiutate, a volte si tratta semplicemente di persone che cercano supporto, non di attività malevole.
Certo, alcune volte le email rifiutate da Discourse devono effettivamente essere scartate, ma non vogliamo rischiare di perdere alcuna email di assistenza, quindi siamo costretti a controllare periodicamente l’elenco dei messaggi rifiutati.
Nel frattempo, i mittenti confusi sono costretti a trovare altri modi per contattarci, come il modulo di contatto sul nostro sito web.
Per i siti più grandi, gli avvisi di rifiuto delle email potrebbero essere troppi da gestire, ma per noi sarebbe molto più semplice occuparsene piuttosto che dover affrontare clienti arrabbiati.
Inoltre, anche se Discourse invia al mittente un’email di rifiuto contenente informazioni potenzialmente utili, ritengo che tali messaggi finiscano talvolta nelle cartelle spam, creando ulteriore confusione tra i clienti interessati.
Non sono sicuro di come risolvere il problema delle risposte provenienti dalla casella di posta sbagliata, però. (E quanto odio i moduli di contatto, indipendentemente da quale lato ci si trovi!)
Se un utente risponde da un indirizzo diverso da quello a cui è stata inviata l’email, questo è previsto.
Se permettessimo risposte a queste email da un altro indirizzo email, esporremmo gli account ad abusi via email, con altri che si spacciano per un altro utente. Ci imbattiamo in questo problema a volte nei nostri stessi messaggi di supporto qui su meta.
Se sono in uso moduli di contatto via email, solitamente inviano da un indirizzo email e impostano l’intestazione Reply-To, il che significa che ci troviamo di fronte allo stesso problema sopra menzionato.
Personalmente non ho una grande soluzione a riguardo—magari qualcun altro del team ha un’idea.
Sì, come ho detto, ha senso rifiutarle. Ma vorrei comunque essere avvisato quando ciò accade.
Ho menzionato i moduli di contatto solo perché, quando i clienti non riescono a contattarci tramite l’indirizzo email di supporto (che Discourse elabora), sono costretti a cercare alternative, il che non è ideale.
Non sono sicuro di come farlo esattamente. Puoi monitorare /admin/email/rejected, ma per ricevere un vero avviso al momento attuale avresti bisogno di un plugin.
Neanche io, ed è per questo che ho pubblicato questa richiesta come nuova funzionalità.
Sì, ho capito. Ma andare su quella pagina e premere aggiornamento ogni pochi minuti sembra piuttosto inefficiente.
Un plugin andrebbe bene, ma non capisco perché questa funzionalità non possa essere semplicemente aggiunta a Discourse. Per me sembra una scelta ovvia. Discourse invia già vari avvisi agli amministratori e allo staff del sito. Imposta l’impostazione (avviso in caso di rifiuto delle email) su disabilitata per impostazione predefinita, il che credo funzionerebbe per molti siti.
Un altro esempio: un cliente ha inviato un’email all’indirizzo di supporto per segnalare un problema riscontrato con il proprio acquisto. Discourse ha respinto l’email: [Email::Receiver::InactiveUserError].
Capisco che abbia perfettamente senso che Discourse respinga le email provenienti da utenti inattivi, ma se il nostro staff di supporto fosse stato avvisato contemporaneamente, avrebbe potuto contattare immediatamente il cliente, spiegando cosa è successo e quali soluzioni sono disponibili.
Invece, a meno che non si interroghi frequentemente l’elenco dei messaggi respinti, il cliente si trova ora a dover affrontare due problemi, entrambi conseguenza di sistemi automatizzati, dei quali il nostro staff di supporto rimarrebbe all’oscuro. L’intervento umano in questa fase è fondamentale, ma possono verificarsi ritardi nei tempi di risposta, poiché, ancora una volta, siamo costretti a controllare manualmente l’elenco dei messaggi respinti.
Esiste qualche motivo tecnico per cui gli amministratori non possono essere avvisati del rifiuto delle email?
