È un po’ ridondante ora, ma a) non si tratta solo dell’indirizzamento con il simbolo +, come ho detto nel mio primo messaggio, b) non si tratta solo di aggiungere l’alias, ma di rendere il campo From inutilizzabile, come ho spiegato nel mio quinto messaggio, c) non stiamo parlando solo di Gmail, come ho sottolineato nel mio secondo e più recente messaggio. Comunque, credo di essere abbastanza veloce nell’interfaccia utente di Gmail, ma faticherei ad aggiungere e confermare un nuovo alias in dieci secondi.
Meno ridondante: ci sono elementi concreti per l’idea del token che ho menzionato più volte, ma che è stata ignorata a favore di lamentele sugli utenti pigri di Gmail?
Quando si tratta di un alias Gmail con punto o con il simbolo +, non è necessario confermare. L’ho appena provato e ci sono voluti solo 12 secondi.
Sì, esistono altre configurazioni di consegna più strane. Gli sviluppatori hanno già dichiarato che, in futuro, renderanno più semplice per gli amministratori (e forse anche per gli utenti) aggiungere indirizzi email secondari per gli utenti. Non credo che debbano fare sforzi ulteriori oltre a questo. Se gli utenti vogliono rispondere alle email ricevute su un indirizzo da cui non possono inviare, dovrebbero farsi carico della propria configurazione email.
Come opzione attivabile dagli amministratori, l’idea del token potrebbe funzionare. Diamo già per scontato che, se gli utenti inoltrano le email del forum ad altri, questi ultimi possano annullare l’iscrizione utilizzando i link presenti al loro interno. Ovviamente, pubblicare contenuti è potenzialmente più distruttivo rispetto all’annullamento dell’iscrizione.
Come richiesta di funzionalità, gli sviluppatori spesso citano la “regola del tre”: una volta che tre persone hanno richiesto una funzione, iniziano a prenderla più seriamente in considerazione. O, se sei un cliente pagante.
Mi scuso. Sono estremamente pigro e non sono un programmatore Rails particolarmente talentuoso; cerco sempre soluzioni che non richiedano modifiche a Discourse. (No, non sto usando sarcasmo. Di recente ho avviato una conversazione per scrivere un plugin da 1000 dollari e ho convinto il potenziale cliente ad adottare una soluzione basata esclusivamente sulle funzionalità esistenti.)
Senza esaminare il codice, penso che potrebbe essere possibile rimuovere o allentare il controllo dell’indirizzo From: del mittente, poiché, come suggerisci, il token è unico. Se non ti importa che qualcuno possa ottenere quel token in altro modo (ad esempio tramite un messaggio inoltrato?), potresti sovrascrivere process_destination in un plugin e consentire la consegna di quelle risposte, consapevole che ciò comporta un certo rischio per la sicurezza. Penso che dovresti semplicemente modificare questo:
in qualcosa che permetta a qualsiasi indirizzo di rispondere, o forse implementare una logica del tipo “è abbastanza simile”, anche se al momento non vedo come si possa arrivare a tale soluzione (non per dire che non sia possibile).
Grazie per questo. Molto interessante. Se, come è stato affermato, esistono già problemi di sicurezza con i link di disiscrizione tokenizzati (e questi sono considerati rischi accettabili), sembra promettente.
Sembra abbastanza ovvio, quindi ho presunto che, se nessuno lo avesse richiesto prima, ci fossero implicazioni che avevo trascurato, ma se non è così, questo sembra un modo molto superiore per accogliere persone come me e placare anche i critici.
Non so chi altro etichettare per avere pareri o critiche, ma cosa ne pensi @codinghorror?
Se gli utenti in staging fossero abilitati, permetterebbe semplicemente risposte da qualsiasi email? Non lo so, non ho mai provato un sistema del genere (ho solo utenti in staging per gestire email di tipo supporto.)