Un poco redundante ahora, pero a) no se trata solo del direccionamiento con +, como mencioné en mi primer mensaje; b) no se trata solo de agregar el alias, sino de hacer que el campo From sea inutilizable, como expliqué en mi quinto mensaje; c) no estamos hablando solo de Gmail, como indiqué en mis segundo y más recientes mensajes. De todos modos, creo que soy bastante rápido con la interfaz de usuario de Gmail, pero tendría dificultades para agregar y confirmar un nuevo alias en diez segundos.
Menos redundante: ¿hay alguna base para la idea del token que he mencionado varias veces pero que ha sido ignorada en favor de quejas sobre usuarios perezosos de Gmail?
Cuando se trata de un alias de Gmail con punto o con más, no es necesario confirmar. Acabo de probarlo y solo tardó 12 segundos.
Sí, existen otros tipos de configuraciones de entrega extrañas. Los desarrolladores ya han dicho que, con el tiempo, facilitarán a los administradores (y quizás a los usuarios) la adición de correos electrónicos secundarios para los usuarios. No creo que deban esforzarse más allá de eso. Los usuarios deben asumir la responsabilidad de sus propias configuraciones de correo si desean responder a mensajes recibidos en una dirección desde la que no pueden enviar.
Como una opción que los administradores podrían habilitar, la idea del token podría funcionar. Ya confiamos en que, si los usuarios reenvían sus correos del foro a otros, podrían darse de baja usando los enlaces incluidos. Por supuesto, publicar es potencialmente más destructivo que darse de baja.
Como solicitud de función, los desarrolladores suelen mencionar una regla de tres: cuando tres personas la solicitan, comienzan a considerarla con más atención. O si eres un cliente de pago.
Lo siento. Soy extremadamente perezoso, no soy un programador de Rails muy talentoso y siempre busco soluciones que no impliquen modificar Discourse. (No, no estoy siendo sarcástico. Recientemente inicié una conversación para escribir un plugin de 1000 dólares y convencí a un no cliente de adoptar una solución utilizando solo las características existentes.)
Sin revisar el código, creo que podría ser posible eliminar o relajar el código que verifica la dirección del remitente en el campo From:, ya que, como sugieres, el token es único. Si no te importa que alguien obtenga ese token por otros medios (por ejemplo, un mensaje reenviado), podrías sobrescribir process_destination en un plugin y permitir que esas respuestas se entreguen, entendiendo que esto conlleva cierto riesgo de seguridad. Creo que solo necesitarías cambiar esto:
por algo que permita que cualquier dirección responda, o quizás implemente alguna lógica de “¿está lo suficientemente cerca?” que ahora no veo cómo podrías desarrollar (aunque no digo que sea imposible).
Gracias por esto. Muy interesante. Si, como se ha dicho, ya existen problemas de seguridad con los enlaces de cancelación de suscripción tokenizados (y que estos se consideran riesgos aceptables), suena prometedor.
Parece bastante obvio, así que asumí que, si nadie lo había solicitado antes, había implicaciones que había pasado por alto. Pero si no es así, esto parece una forma muy superior de acomodar a personas como yo y también de apaciguar a los escépticos.
No sé a quién más etiquetar para que comparta sus opiniones o críticas, pero ¿qué opinas @codinghorror?
Si los usuarios en fase de prueba estuvieran habilitados, ¿permitiría simplemente respuestas desde cualquier correo electrónico? No lo sé, no he probado ese tipo de sistema (solo tengo usuarios en fase de prueba para manejar correos de tipo soporte).