Um pouco redundante agora, mas: a) não se trata apenas de endereçamento com +, conforme meu primeiro post; b) não se trata apenas de adicionar o alias, mas de tornar o campo From inutilizável, conforme meu quinto post; c) não estamos falando apenas do Gmail, conforme meus segundo e mais recentes posts. De qualquer forma, acho que sou bastante rápido na interface do usuário do Gmail, mas teria dificuldade em adicionar e confirmar um novo alias em dez segundos.
Menos redundante: há alguma base para a ideia do token que mencionei várias vezes, mas que foi ignorada em favor de reclamações sobre usuários preguiçosos do Gmail?
Quando se trata de um alias com ponto ou sinal de mais no Gmail, você não precisa confirmar. Acabei de testar e levou apenas 12 segundos.
Sim, existem outros tipos de configurações de entrega estranhas. Os desenvolvedores já disseram que, eventualmente, facilitarão para os administradores (e talvez para os usuários) adicionar e-mails secundários para os usuários. Não acho que devam se esforçar além disso. Os usuários devem assumir a responsabilidade pelas próprias configurações de e-mail se quiserem responder a mensagens recebidas em um endereço do qual não podem enviar.
Como uma opção que os administradores poderiam habilitar, a ideia do token poderia funcionar. Já confiamos no fato de que, se os usuários encaminharem seus e-mails do fórum para outras pessoas, eles podem cancelar a inscrição usando os links contidos neles. Claro, publicar é potencialmente mais destrutivo do que cancelar a inscrição.
Como solicitação de recurso, os desenvolvedores frequentemente mencionam a regra do três: quando três pessoas solicitam algo, eles começam a considerar mais seriamente. Ou se você for um cliente pagante.
Desculpe. Sou extremamente preguiçoso e não sou um programador de Rails muito talentoso, por isso sempre procuro soluções que não envolvam alterações no Discourse. (Não, não estou sendo sarcástico. Recentemente, iniciei uma conversa para desenvolver um plugin de US$ 1.000 e convenci o cliente em potencial a adotar uma solução usando apenas recursos existentes.)
Sem analisar o código, acredito que seria possível remover ou flexibilizar o código que verifica o endereço do remetente no campo “De:”, pois, como você sugere, o token é único. Se você não se importar que alguém possa obter esse token por outros meios (por exemplo, uma mensagem encaminhada), você poderia sobrescrever o método process_destination em um plugin e permitir que essas respostas sejam entregues, entendendo que isso representa um certo risco de segurança. Acredito que você precisaria apenas alterar isto:
para algo que permitisse que qualquer endereço respondesse ou talvez implementasse algum tipo de lógica de “se está próximo o suficiente”, algo que não consigo imaginar agora como você poderia desenvolver (isso não significa que não seja possível).
Obrigado por isso. Muito interessante. Se, como foi dito, já existem problemas de segurança com links de cancelamento de assinatura tokenizados (e que esses são considerados riscos aceitáveis), parece promissor.
Parece bastante óbvio, então assumi que, se ninguém tivesse solicitado antes, havia implicações que eu não havia considerado. Mas, se não for esse o caso, isso parece uma maneira muito superior de acomodar pessoas como eu e também agradar os céticos.
Não sei mais a quem marcar para compartilhar pensamentos ou críticas, mas o que você acha, @codinghorror?
Se usuários em estágio fossem habilitados, isso permitiria apenas respostas de qualquer e-mail? Não sei, nunca testei esse tipo de sistema (eu só uso usuários em estágio para lidar com e-mails de suporte.)